Action!: an Algol-like programming language for Atari 800

Today I learned that Clinton Parker has released the Action! programming language, used to build HomeText and HomeTerm for Atari 800, under the GNU GPL. It's reportedly similar enough to C to make line-by-line translation of programs practical, yet optimized to target 6502. (See thread on AtariAge.)

Has anyone tried using it to target a more ROM-oriented 6502 platform? And if so, is the generated code any more efficient than that produced by cc65?

I used ACTION! to write a number of programs for the Atari 8-bit systems in the mid-1980s. It was, bar-none, the closest that the Atari 8-bits ever got to something resembling C, for a _very_ long time, as the C compilers for the system at the time generated really bad p-code with a ridiculous library overhead...Completely impractical, and it gave credence to the stupid anecdotal wisdom that "A 6502 can't handle C."

The power of ACTION! was in the fact that it really was an integrated development environment, with an excellent text editor, monitor/compiler, and debugger crammed into a nice little cartridge...and ACTION! had a very liberal license with their embeddable runtime that made it very attractive for those who came from big computing environments like myself, and wanted to program in something a bit more abstract than 6502 assembler, while still allowing direct access to the hardware, and it was easy enough to drop down into assembler if you needed to...

The downside was that ACTION! was based on a language (Micro-SPL) that did a number of things that vastly simplified the design of the language and its tooling, the biggest was the deliberate non-use of stack-frames, which ultimately meant things like you can't call functions recursively, and that all variables are essentially static and global.

but once you understood these things, you could work around it well enough, and the output of the assembler code was quite excellent (for the time)

There is an open-source implementation of ACTION! called Effectus, you can get it here:
http://gury.atari8.info/effectus/download.php

You might be able to massage it into something the NES could run really well.
-Thom

I wonder why I've not seen any compilers for the 6502, 68HC11, or Z80 handle local variables the way compilers for the PIC and 8051 do: build a list of function calls and figure out the highest or lowest possible address for a function's local variables that won't collide with any of its callers. This doesn't allow recursion, but the memory usage would be less than or equal to that of a stack-based compiler if the worst-case combination of nested function calls actually occurs. Given how inefficiently the aforementioned platforms use stack variables, it seems senseless to me to have compilers store things that way when processing programs that don't need recursion.

I too have long endorsed this model. I imagine it's not used in compilers targeting 6502, 68HC11, Z80, or SM83 because there's a lot less money invested in them than in compilers targeting PIC and 8051.

The approach used on the 8051 and PIC isn't difficult. Given a list of all the function calls and the size of each function's automatic variables, one could fairly easily write a utility that would produce a .ASM file containing all of the necessary allocations. The most expensive part would be parsing the list of function calls. All the other logic is really easy. Start by putting all functions at address zero. Then visit each function and check to see if it collides with any of its callers. If so, move its local variables above those of the highest caller and re-tag any functions it calls for re-inspection. Keep on doing until one runs out of memory or no more functions need inspection.

Write one then

Is doing the function based overlap enough though for a NES? For MLA I thinking of adding a "declare shared variables" and then have a dependency system work out the overlap on a per "variable" level. If Soci will come up with a way I can instance a variable in a namespace.

ACTION! looks interesting, kinda like COMAL, I don't really see it having any issues with ROM though, it already comes on a cart. You might need to say put its KERNEL into the common bank if it fits, and they your code into the banks.

Function-based overlap is much better than treating everything as static. Approaches using graph coloring may save somewhat more space, but will be much more complicated to implement. There is another detail I forgot to mention, which is that every function whose address is taken must be treated as being called by a "invoke function with pointer type X", function, and every call to a function of type X must be treated as a call to the "invoke function with pointer type X" function. If there's only one function-pointer type, then no function which is directly or indirectly called via function pointer may directly or indirectly invoke any other function via function pointer. That could be a bit of a nuisance, which might require adding some means of partitioning functions into groups.

Still, build-time overlays are generally a much more practical approach than trying to emulate a parameter stack on the 6502.

First requirement is having the compiler generate information sufficient to build a call graph. After that, the most time-consuming bits are the code to parse that information and the code to generate the output. The actual logic to place objects is trivial by comparison.

If anyone is interested, this is an overview of the design of what became the ACTION! compiler, the language was originally called Micro-SPL:
http://www.bitsavers.org/pdf/xerox/alto ... _Sep79.pdf

-Thom