I'm wondering about what choices we might have on the 6502 for compiling code on the machine itself... (so, not thinking of cc65 or WDC's C compiler or others which run on a modern machine to produce 6502 code.)

By compiler, I mean something which makes an effort to predigest a high level language for better runtime performance than a simple interpreter. By high level language, I mean something which offers more control than just branches or calls to labels, offers named functions or procedures with parameters, offers data types more interesting than just bytes.

So, I include compilers which compile down to an intermediate code which is interpreted.

In the land of Acorn's BBC Micro, there were several offerings from Acorn's own Acornsoft, usually on ROM (or multiple 16k ROMs) and needing the ROM for both compile-time and run-time: see the catalogue here (PDF)

ISO-Pascal - compiles to intermediate code; standalone generator also available
BCPL - compiles to intermediate code; standalone generator also available
FORTH (an indirect threaded implementation [ref])

(capitalisation from the price list there. Also offered are Logo, LISP, micro-PROLOG, and COMAL, all interpreters, I believe.)

There was also an offering from Superior Software - Accelerator - which compiled BBC Basic to machine code via an intermediate G code. It hooked directly into routines from the Basic ROM at runtime and so was only compatible with one version of Basic.

According to this file there were also several C compilers:


The same document also mentions an APL (which might be an interpreter, although that tends not to hurt APL performance much) from I-APL Ltd ("the I-APL organization was at one time working on porting their free version of APL to the Apple II (and Commodore 64)."[ref]), a FORTRAN from AJS Soft (which turns out to be an interpreter) and HALCIEN which I would guess was an interpreter too.

Were you just looking at the BBC Micro? Or other 6502 platforms?

I'm sure there were several for the Apple. The Atari had both a C compiler (this, too, was a Small C) but it also had Action!, which was quite fast. It was a cartridge based Algol-esque language.

At one time, the Power C compiler (not to be confused with this product), which was paired with the Buddy assembler, was available for the Commodore 64 and 128 computers. The Power C compiler predated the 1989 ANSI C standard, which means it follows the K&R syntax for things like function prototypes. I briefly looked at the C-128 version during the latter 1980s, but never did any substantial programming with it.

Similarly, Abacus Software produced a C compiler for the C-64. I don't recall if they ever produced a C-128 version.

In the realm of BASIC, Skyles Electric Works offered a very good BASIC compiler for the C-128 that produced fast-executing code, especially in the realm of number processing. I developed a graphics program with it, using BASIC to perform the floating point calculations needed to produce geometric shapes, and assembly language to do the integer math and low-level grunt work involved in driving the 8568 video display controller (VDC). BASIC's prompts and status messages were written on the 40 column display, and the graphic images appeared on the 80 column display in bitmap mode—I used two video monitors so I could see both displays at the same time. Due to the speedup experienced by the compiled BASIC code, one had the impression that the entire mess was written in assembly language.

Speaking of C, that language has never been a good fit with any of the eight bit 6502 family, mainly due to the lack of native support for managing stack frames. I have tried out the C compiler shipped in the WDC package and can report that it produces fast and efficient code on the 65C816, no doubt because the latter does support stack frames.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I'm interested in the general question, but I happened to have some familiarity with the Beeb.

I suppose in principle any offering for a 6502 machine could be ported to another... but in practice that would be rather involved.

Both the Apple and C64 had a serious RAM advantage on the Beeb, but if the Beeb can run 32k of software from ROM that might help even the balance. If the Beeb has a 64k second processor, it certainly makes a difference!

Thanks for the pointers though:

- https://atariwiki.org/wiki/Wiki.jsp?page=C


Thanks for those pointers too!

There's something of an advantage in a Basic compiler, if there's a large user base cranking out Basic programs, or wanting to, and needing some more performance. Especially if it has some knowledge of some particular features of the machine, like graphics or sound.

It seems that the main improvement in performance with compiled BASIC was in floating point math, most likely in the ASCII <—> FP conversion functions, which tended to be quite slow on most eight bit machines. Variable handling was improved as well. I found out some time after I had discontinued C-128 programming that the Skyles BASIC compiler used a sorted table of names, along with a binary search, to handle access to variables. Compare that to a sequential search of variable space used by Microsoft BASIC. This technique mimicked what is done in Business BASIC interpreters running on Linux and UNIX, and would have explained the substantial speedup seen in processing strings.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Indeed. The source code for Action is actually available: https://sourceforge.net/projects/atari-action/

Since it included an editor (among other things), there's clearly a bunch of Atari specific code in there. But, yanking the compiler out my not be too arduous. Outside of perhaps some CIO routines to read/write from disk, the bulk of it should be pretty generic. It also included a run time library, this was bundled on the ROM cartridge. There would certainly be some Atari bits in there as well. Action ran in a 48K Atari out of a ROM. I think it was a 16K ROM, which would suggest there was perhaps some bank switching shenanigans involved somewhere.

These are good points BDD. Now, Atari BASIC didn't do ASCII (Well, ATASCII) -> FP, save during entry. Once entered, numbers were stored internally in binary. However, the Atari didn't have the notion of integers. All numbers were in the floating point.

Variable lookup, and line number lookup were both expensive, as they were simply linear searches through their respective tables (variable table for variables, and the tokenize BASIC code for line numbers). A BASIC compiler could readily improve program performance by removing those lookups, and converting them in to absolute addresses. After that, you're effectively in a tokenized interpreter, which can be quite fast (reference all the Forth discussion). On BASIC XL, for the Atari, the FAST command would run through the program and resolve the line numbers, and that alone provided a pretty dramatic speedup to the program.

It's easy to see a solid improvement to a BASIC that, indeed, stored their numbers (within the source code) in ASCII. Having those constants precomputed would certainly speed things up.

Converting the BASIC code to actual machine code likely wasn't worth the trouble.

David Schmenk has done some nice work in PLASMA, which is 8-bit Apple-specific, but has had some porting activity:

search.php?keywords=plasma+schmenk&terms=all&author=&sc=1&sf=all&sk=t&sd=d&sr=posts&st=0&ch=300&t=0&submit=Search

Mike B.

Good point!

What's more, there's an effort underway to port it to the Beeb. Which might result in something which is in turn easier to port to other machines.

I had no idea they were doing this. Just made my day. The PLASMA VM isn't tied too directly to the Apple II. I've built versions for the Apple I and the Apple /// without much effort. The IDE is a bit of a hack job, though. It doesn't use relocatable modules and is just a big, ugly, monolithic blob that contains the editor, compiler, and runtime all together. It was written early on, before all the relocatable module stuff was solidified to prove it could be done (it only uses the main 64K, none of the banked memory). It still gives you about 16K of code space and about 8K of compiled code space to play with. Someday I should rewrite it as modules it which will get the banked memory support involved.

Kudos to the Beeb team.

Dave...

I think the non existing "common platform" (like CP/M for example) is the main cause for the lack of such compilers.
If one would "define" a minimal platform - say 32KiB RAM from 0..$7FFF, a set of vectors to system dependent subroutines like outchar, inchar, checkbreak, save and load - it could be possible to write some (limited) compilers for such a platform. But who wants to use such a primitive solution, having an Apple/Atari/Acorn/etc. ? All their capabilities weren´t used - that doesn´t look appealing.

Looks like a doom-loop to me

I've had a C-style language optimized for the 6502 on the back burner for years. In the last month I've started making serious progress on it. I hope to make it public in the next month or so.

I'm trying to design the standard libraries to allow cross-platform compatibility.

It's currently written in standard C, but I have written the code in such a way that it can be easily converted with the goal of compiling the compiler into 6502 code.

I first started learning C using "Super-C" on the C64 (by Abacus), with one of Herb Schildt's books in-hand. It had a nice text editor, assembler, linker etc. The biggest drawback was disk-swapping, but in the end I was very pleased to render Mandelbrots a little faster, and learn a new language in the process.