3 ms·
I've always felt the the 6502 architecture wasn't really amenable to C (mainly due to the limited stack). A quick glance at the site with an eye toward accommod
by EvanAnderson 5y ago
I've always felt the the 6502 architecture wasn't really amenable to C (mainly due to the limited stack). A quick glance at the site with an eye toward accommodations made for the platform turned up the interesting hybrid architecture of the compiler suite. You can see it detailed in the section "1.6 C65 and CCI, The Speed Versus Size Dilemma"[0].
Basically, there's an optional compiler that emits a p-code (rather than 6502 machine code) that's interpreted by a VM to make 16 and 32-bit operations more space efficient. This is highly reminiscent of SWEET16[1]. Also makes me think of the Apollo Guidance Computer and the "Interpreter"[2].
This looks like a lot of fun. I'd like to get this running on my Apple IIgs!
[0] http://aztecmuseum.ca/docs/AztecC_minimanual.txt http://aztecmuseum.ca/docs/AztecC_minimanual.txt
[1] https://en.wikipedia.org/wiki/SWEET16 https://en.wikipedia.org/wiki/SWEET16
[2] https://en.wikipedia.org/wiki/Apollo_Guidance_Computer#Software https://en.wikipedia.org/wiki/Apollo_Guidance_Computer#Softw...
- rbanffy 5y ago> This looks like a lot of fun. Used it on a //e. It's not. It's painfully slow - slower than the BASIC in ROM. It also messes with page zero, which makes it impossible to use the ROM routines (which could have made character output not ludicrously slow - it feels like a 1200 bps terminal)
- EvanAnderson 5y agoInteresting. I didn't get the feeling that they were targeting embedded 6502 but, rather, the Apple II platform. To that end I'd think being "friendly" to the ROM routines would have made good sense (since they get all that functionality "for free"). I guess I'll fire it up in an emulator first to see if it's worth hitting the real hardware with it. Thanks for the heads up!
- rbanffy 5y agoI did a PoC with it and we gave up on C for an Apple II port of an educational Mac game (which was written in C). We went with @plutus' GraFORTH. It was easier (and more pleasant) to reimplement everything in Forth than to persuade Aztec C to create minimally reasonable 6502 binaries.