This page (revision-270) was last changed on 26-Mar-2023 02:03 by Administrator 

This page was created on 20-Feb-2010 19:16 by Carsten Strotmann

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note
270 26-Mar-2023 02:03 17 KB Administrator to previous
269 26-Mar-2023 02:02 17 KB Administrator to previous | to last
268 26-Mar-2023 02:01 17 KB Administrator to previous | to last
267 26-Mar-2023 02:00 17 KB Administrator to previous | to last ACTION Source Code ==> Action Source Code
266 26-Mar-2023 01:59 17 KB Administrator to previous | to last
265 26-Mar-2023 01:58 17 KB Administrator to previous | to last
264 26-Mar-2023 01:56 17 KB Administrator to previous | to last Remove links to delete manual pages
263 26-Mar-2023 01:22 17 KB Administrator to previous | to last Fix SF links
262 26-Mar-2023 01:21 17 KB Administrator to previous | to last
261 26-Mar-2023 01:18 17 KB Administrator to previous | to last Move manuals to Sourceforge

Page References

Incoming links Outgoing links
Action

Version management

Difference between version and

At line 15 changed one line
These design notes increased performance, but the primary reason Action! was much faster than other languages of the era was due to its memory management model. In languages like C and Pascal, procedure calls use a stack of records known as "activation records" that record the values of variables when the procedure was called. This allows a procedure to call itself, as each call can have its own values, and it is this feature that allows recursion.
These design notes increased performance, but the primary reason Action! was much faster than other languages of the era was due to its memory management model. In languages like C and Pascal, procedure calls use a stack of records known as "activation records" that record the values of variables when the procedure was called. This allows a procedure to call itself, as each call can have its own values, and it is this feature that allows recursion. This concept requires the manipulation of a stack, which in the 6502 was a non-trivial prospect given the CPU stack was only 256 bytes.
At line 17 changed one line
This concept requires the manipulation of a stack, which in the 6502 was a non-trivial prospect. Action! simply didn't bother implementing this concept, instead, the storage space for variables was allocated at compile time (not dissimilar to Atari BASIC's model). This meant Action! could not support recursion, but also eliminated the necessity to build and manipulate the activation record stack. This dramatically lowers the overhead of procedure calls, and in a language that organizes a program as a series of procedure calls, this represents a significant amount of time.
Action! solved this problem by simply not implementing activation records. Instead, the storage space for variables was allocated at compile time (not dissimilar to Atari BASIC's model). This meant Action! could not support recursion, but also eliminated the necessity to build and manipulate a complex stack. This dramatically lowers the overhead of procedure calls, and in a language that organizes a program as a series of procedure calls, this represents a significant amount of time.