> Having had a quick look at the architecture, I think SDCC is a good > choice for a compiler targeting it. The instruction set, and adressing > modes look ok, the 16-bit stack pointer and index register will be quite > helpful. It is kind of a typical architecture for an SDCC target - not a > great target for C, but not too bad either.
It's an extremely nice machine for most C code generation as far as 8bit processors go. It's probably better than pretty much anything except 6809 - certain beats the Z80 flat. You do need to do good register tracking on the X register and also know how to dynamically calculate offsets from the current X register versus S at any point to make it work well. So for example you end up doing stuff like TSX LDB #8 ABX PSHX ; push &x LDD 4,X ; tracking live X so we don't keep reloading with TSX > The main difficulty will likely be the lack of an efficient > stackpointer-relative addressing mode, so stack accesses would have to > use the index register - and there is only one index register, which > also needs to be used for pointer accesses. Thus, you'll probably want > local variables to not be on the stack by default (like for mos6502, > pdk, mcs51, hc08). Having written two 6801/3 compilers that isn't the case at all. You want everything on the stack most of the time because indexed is faster and more compact than extended. See https://github.com/EtchedPixels/Fuzix-Compiler-Kit and the older https://github.com/EtchedPixels/CC6303 which has then been built out for 6800 a lot more by Zu2 https://github.com/zu2/CC6303 As the Fuzix compiler actually runs on a 6801 you should be able to do a lot better with SDCC as you've got room for a lot more higher level optimisations but hopefully the fcc code will give you some ideas on how to tackle it perhaps. It's also being used on the Tandy MC10, which is about the only classic style 6803 home computer in existence. > IMO, the MC6800 and MC6801 are so similar, that it would make sense to > create ports for both, which would then share register allocation and They are *totally* different beasts for a compiler. 6800 has no 16bit bit operations of note and cannot stack and unstack the X register. That dramatically changes how you need to do code generation if you want even vaguely reasonable size. Some other stuff like stack adjustment ends up really different too. Most 6800 compilers are bytecode engines but it is possible to do C on a straight 6800 if you pull a few tricks (in particular knowing that whilst you can't PULX you can TSX LDX ,X INS INS) 6801/3/6303 are fairly similar because the big difference for a compiler is XGDX and that mostly translates to being able to do constant adjustments of X better. 6801/3 is limited to ABX which destroys B on a constant load whereas 6303 can do XGDX ADDD #nnnn XGDX. So XGDX totally changes doing maths on X (and thus S) but it's a very localised change in most compilers. 68HC11 adds Y but it's prefixed and slower so harder to use effectively. It's really important for stuff like asm memcpy() functions but in C I ended up using it as the upper half of the 32bit working value mostly as you can then ADDD n+2,X XGDY ADCB n+1,X ADCA n,X XGDY and so on. HC08 is a totally different beastie and involves some fun managing whether your working 16bit value upper is in X or H according to what you are doing. 6809 is very different in several ways. You have operations on ,S, you have LEA both for things like address of stack objects and for doing pointer maths on pointers in registers using U and Y without going via D. The end result is a very very different code generator. 6309 is a whole further layer of fun with some 32bit ops and W etc. > most of code generation (like e.g. the z80 port and the z180 port share > code generation). This would also mean that we need assemblers and > simulators for both. In principle, this could later even be extended to > M68HC11 and M68HC12 support, but is probably not be worth the effort, > since GCC already supports that one. EmulatorKit has 6800/6801/6303/68HC11 emulation and is GPL, feel free to borrow from it if useful. The Fuzix C compiler also uses that library for its own self tests on 680x processors except 6809 (which is way different as a target and uses a different emulator) Alan _______________________________________________ Sdcc-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sdcc-user
