> I briefly used Manx's Aztec C; it was awful. It generated bad code, and was a pain to use.
But it came wit a Unix-like shell, make and vi. And probably ed.
6502 Language Implementation Approaches
21–27 of 27 posts
Re: 6502 Language Implementation Approaches
#22...so I wrote this self-hosting compiler for the 6502 and Z80: http://cowlark.com/cowgol/ I say self-hosting, but on a 64kB BBC Micro second processor with floppy disk it takes about seven minutes to compile Hello World, so I haven't bothered to actually recompile the whole toolchain. (The overwhelming majority of of that time is spent doing disk I/O, as there's way too much state to keep in RAM. The compiler is an e…
> The Z80 drove me nuts
I can't respect any CPU that takes FOUR clock cycles to do a NOP. Not sure if it takes longer if the PC points to a page boundary.
Re: 6502 Language Implementation Approaches
#23Earlier quoted context omitted.
I used a Pascal on a BBC Micro which consisted of 2 16KB ROMS: one for the editor and one for the compiler. It would have maybe 32KB of RAM minus the screen memory (1KB to 20KB).
32K for an editor?! That's insane! If I'm not clear, that's insanely huge for an 8-bit computer.
I think the editor was just one of the 16KB ROMS. But you are right. Wordwise was an incredible text editor and it also fitted in a 16KB ROM.
32KB was the total RAM you had on a BBC Micro B.
Re: 6502 Language Implementation Approaches
#24Earlier quoted context omitted.
I used a Pascal on a BBC Micro which consisted of 2 16KB ROMS: one for the editor and one for the compiler. It would have maybe 32KB of RAM minus the screen memory (1KB to 20KB).
32K for an editor?! That's insane! If I'm not clear, that's insanely huge for an 8-bit computer.
Actually...
I was co-author of Acorn ISO Pascal.
The system fit in two 16KB EPROMS for a total of 32KB, but only one of the 16KB ROMS could be mapped into the address space at a time.
The way this worked was that the compiler was self-hosted (i.e. written in ISO Pascal and compiled itself) and generated our own stack-based virtual machine code which we referred to as BL-code based on our own initials.
One of the 16K ROMS contained the BL-code of the self-compiled compiler... which only fit after a considerable amount of effort, including a few "macro" BL-codes designed for the purpose. Remember this was full BSI-certified ISO-Pascal, plus Acorn extensions for graphics etc, not some toy subset.
The other 16K ROM contained everything else, meaning the BL-code interpreter, screen editor, run-time libraries (floating point - which we copied from BBC basic, Pascal I/O, heap, etc), and command line interpreter. The editor, which I wrote, was around 4KB and fairly sophisticated for the time, including full regex global replace.
One interesting tidbit is how the system actually ran given that the compiler was in one ROM, and the interpreter needed to run it in the other ROM, with only one ROM able to be mapped into the address space at a time... The way we handled this was to relocate the interpreter into RAM in order to run the compiler (but run from ROM when running user programs), so the interpreter was organized into pure code, pure data and relocatable address tables to make this possible.
Getting the whole system to fit into those two 16K ROMS was a heck of a challenge!
Re: 6502 Language Implementation Approaches
#25Earlier quoted context omitted.
32K for an editor?! That's insane! If I'm not clear, that's insanely huge for an 8-bit computer.
Actually... I was co-author of Acorn ISO Pascal. The system fit in two 16KB EPROMS for a total of 32KB, but only one of the 16KB ROMS could be mapped into the address space at a time. The way this worked was that the compiler was self-hosted (i.e. written in ISO Pascal and compiled itself) and generated our own stack-based virtual machine code which we referred to as BL-code based on our own initials. One of the 16K…
Having grown up in Brazil, I never had contact with the BBC micros until I became interested in retro computing. What you folks accomplished is not appreciated enough on the other side of the Atlantic.
Re: 6502 Language Implementation Approaches
#26The next version of PLASMA has a JIT compiler that will compile PLASMA byte code routines into native machine code based on call frequency. Currently supports 6502 and 65802/65816 backends into a 4K code buffer. It doubles the speed of the PLASMA compiler, itself written in PLASMA.
Re: 6502 Language Implementation Approaches
#27For a native 6502 compiler (to a VM similar to the PLASMA one), see FastBasic: https://github.com/dmsc/fastbasic