The COMFY 6502 Compiler

[BigEd]

For light relief, here's Henry G Baker's paper presenting a compiler for 6502, with source! (In LISP, as it happens)

Quote:

the COMFY language ... is intended to be a replacement for assembly languages when programming on ‘bare’ machines.

Quote:

We will wager that the text of this compiler is perhaps 1/10 to 1/100 the size of a standard macro assembler and far more capable. With the power of the entire Lisp language available for use within COMFY-65 macros, the amount of intelligence one can embed in these macros is limitless

This was a practical effort, too:

Quote:

our analogous COMFY-Z80 compiler was used to develop the code for an intelligent ASCII terminal with a 512x512x1 bitmapped display in 1979.

[Rick Cortese]

Mostly guessing but Clinton Parker worked with Baker in some capacity. Around 1983 Mr. Parker released the Action! programming language for the Atari 8 bit. I Googled to find some of his early work and found
http://home.pipeline.com/~hbaker1/Micro-SPL.txt

This was clearly the what spawned the Action! language. When the copyright holder for the language closed their doors I made an unsuccessful bid to buy the rights to it. Unfortunately computers like the ST, Amiga, AT, Mac, started coming out ~1985 a lot of talent moved on to the newer platforms and Action! never got a big market. Action! carts typically sell for $70-$120 now<I have two grin>. I can only guess that people are using them for cross development. It is still my favorite development environment. The only programming I have done since getting back into it is for an NES. I'm thinking of setting up an Atari 8 bit with Action! to be cross development platform for the NES and Darryl's SBC when I get my hands on it.

Rick

[BigEd]

From that page ("High Level Language Programs Run Ten Times Faster in Microstore"):

Quote:

However, due to the existence of a parser for the SPL language (a derivative of Algol-60) and the non-existence of a parser for BCPL, we built a Micro-SPL compiler [to target microcode in a writeable control store].

I think I remember hearing that Plessey's inhouse circuit simulator (CLASSIC?) made use of the VAX's writeable control store, to good effect.

I'm not familiar with Action! as a language, but I found some pointers onDavid Wheeler's page, where he says

Quote:

SPL is a Forth-like language that is implemented in plain Python and generates 6502 assembly code.

and sends us to Ron's page where there's a download.

Also from David's page I found pointers to Pymite (tiny python, now found on google code and to 65CM which describes itself as "structured semi-low level language" which is hosted on Windows to target 6502.

[kc5tja]

40K for PyMite? YIKES! I suppose it's smaller than a bare-bones JVM, but still, it rules the 6502 right out of the picture unless you port it with some really funky bank-switching logic. It'd probably run a lot slower than any BASIC environment on the same hardware because of that.

However, PyMite looks like a good solution for a high-level language for the 65816.

However, I still lament that folks just don't feel comfortable with either s-expressions or stack notation. Either of these enable a high-level language environment that is a quarter the size of PyMite.

Note that NONE of these figures assume a supporting standard library, which adds to memory footprint of both PyMite and competing language implementations.

[BigEd]

I was thinking PyMite is a good target for 65816 - but as you say, any bank-switching story, or story which distinguishes code accesses from data accessing, will do it.

[Rick Cortese]

I haven't put to much thought into it but most of my dream list for a high level 6502 language would be

1: Worlds greatest editor of course. Things like multiple windows that you could compile and run independantly with cut and paste between windows.

2 Syntax checking w/o generating code for when you make a mistake that would overwrite your OS.

3 Code blocks and in line code. For those times you just want to do things by hand or have a routine that is fully debugged and just need to [$EA] or two for timing or space.

4 Both in memory and compile to and from disk.

5 Output asm files so you can have a look at the code.

6 Built in ability to run and debug programs. Maybe a trace facility and register display. Full debugger anyway with standard commands like change and move memory.

7 Abiltiy to redefine keywords. For example you could have MoveBlock(source, target, length) that uses standard 6502 instruction set and a MoveBlock that is coded for a 65816.

8 Small runtime. You shouldn't have to load a 4k runtime for 'Hello world'. Compiler should be smart enough or provision should be made for easy editiing of the runtime.

It will never happen for the 65xx series at this stage. May never happen for anything the way processors are developing.

Rick

[BigEd]

I see there's a modernisation of SPL, by Carsten Strotmann, at
https://github.com/cstrotm/spl-6502
"SPL-6502 is a Forth-style concatenative stack language. The compiler is (currently) written in Python and emits 6502 assembly code."