6502.org

Also worth noting, the very recent COWGOL from David Given: - http://stardot.org.uk/forums/viewtopic.php?f=53&t=13871

Wow -- that's really exciting.

PLASMA currently targets the VM, but it didn't always. The first version:
(http://vm02.cvs.sourceforge.net/viewvc/ ... 02/plasma/)
could generate three different outputs: byte code, threaded code, and in-line native. The in-line code was quite fast, but as noted earlier, the 6502 isn't the most efficient compiler target, so it was a great deal larger. So later versions targeted just the byte code with an eye towards an efficient interpreter and the ability to execute byte code out of auxiliary/extended memory.

As for high speed, that can be subjective. PLASMA is certainly faster than BASIC, and is roughly equivalent to Forth (I used many concepts from Forth's interpreter when designing PLASMA's VM). The cc65 C compiler implements much of its functionality through library calls to keep the code size reasonable. Each call takes 12 cycles just for JSR/RTS and I have the inner loop for the VM down to 16 cycles. Not insignificant, but the code density and ability to have byte code in auxiliary memory was a good tradeoff, IMHO.

My eventual goal is to create a JIT to target 6502/65C02 which may or may not happen in my lifetime. However, whichever HLL compiler to implement on a 6502, it seems to me that an intermediate representation that satisfies the requirements of implementing the HLL constructs while still fitting into the constraints of the 6502 is crucial. I just went through a re-write of the compiler to extract out the optimizer into an optional back-end operation. This greatly simplified the main code generator and allowed for much better optimizations to occur (with great help from SteveF: http://stardot.org.uk/forums/viewtopic. ... 88#p163288)

Although I've programmed professionally in C for 33 years, I find PLASMA to be much more productive on the 6502 than any other language (Ok, so I'm a little biased). I will still write a number of performance critical routines in 6502 assembly (easy to write assembly routines inside PLASMA) but quite honestly, 100% of the code I write doesn't have to be the fastest possible.


Dave...

One thing strikes me: the most efficient data type on 6502 is the byte - especially for counters. So a language which defaults to byte-size data, or at least makes it easy (and tidy) to declare data to be byte size, would be a win. Perhaps the best possible situation is where the compiler can infer that a byte-size operation is sufficient, without annotations.

(I say this without checking how PLASMA or any other language tackles the problem...)

PLASMA has two basic data types: byte (unsigned 8 bits) and word (signed 16 bits). That's all you could ever need!

Sounds good!

I just came across this page about benchmarking the various C compilers for the 6502. CC65 produced much slower, more bloated code than the other C options, although it was more solid.

I saw that page as well. It succeeds in pointing out the gorilla in the room, which is the 65(c)02 is not a compiler-friendly MPU. The 65C816 is much better suited to C, although still hampered by its paucity of general purpose registers.

EDIT: Fixed some phrasing that evidently was misunderstood by several readers.

Complete nonsense, BDD. I hope you never behave like this in person.

It's a comparison of various aspects of various compilers, shows a lot of care and attention, and is worth a read: title is "Technical highlight: C compilers for 6502 benchmark: A new hope!"

Some images from within:

What is complete nonsense?

Accidentally or otherwise, BDD, in your post you imply the article has little or no value. I'm guessing that's what Ed considers nonsense.

(Just sayin'. I don't have an opinion, myself -- about the article, I mean. But the excerpts posted do seem comprehensive.)

-- Jeff

That wasn't at all what I intended. The article was interesting. I was referring to the 6502 not being a good compiler target.

Thanks for that.

Though I have no interest in programming the 6502 family in C or writing a C compiler, the manual is interesting reading as to ideas for generating good code for the 6502.