It is currently Wed Oct 16, 2019 7:49 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 10 posts ] 
Author Message
PostPosted: Wed May 29, 2019 8:01 am 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21634
Location: NE Indiana, USA (NTSC)
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?

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Fri May 31, 2019 12:03 pm 
Offline

Joined: Mon Jul 03, 2017 4:37 pm
Posts: 138
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


Top
 Profile  
 
PostPosted: Fri May 31, 2019 1:01 pm 
Offline

Joined: Thu Apr 18, 2019 9:13 am
Posts: 161
tschak909 wrote:
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.


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.


Top
 Profile  
 
PostPosted: Fri May 31, 2019 2:43 pm 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21634
Location: NE Indiana, USA (NTSC)
supercat wrote:
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.

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.

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Fri May 31, 2019 10:04 pm 
Offline

Joined: Thu Apr 18, 2019 9:13 am
Posts: 161
tepples wrote:
supercat wrote:
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.

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.


Top
 Profile  
 
PostPosted: Sat Jun 01, 2019 1:26 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 974
Write one then ;)


Top
 Profile  
 
PostPosted: Sun Jun 02, 2019 12:38 am 
Offline

Joined: Tue Feb 07, 2017 2:03 am
Posts: 764
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.


Top
 Profile  
 
PostPosted: Mon Jun 03, 2019 6:40 am 
Offline

Joined: Thu Apr 18, 2019 9:13 am
Posts: 161
Oziphantom wrote:
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.


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.


Top
 Profile  
 
PostPosted: Tue Jun 04, 2019 9:15 am 
Offline

Joined: Thu Apr 18, 2019 9:13 am
Posts: 161
calima wrote:
Write one then ;)


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.


Top
 Profile  
 
PostPosted: Tue Jun 04, 2019 8:14 pm 
Offline

Joined: Mon Jul 03, 2017 4:37 pm
Posts: 138
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


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 10 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group