On Mon, 8 Dec 2025 22:42:38 +0100 Philipp Klaus Krause <[email protected]> wrote:
(Switching from my ancient email to current one as I've finally updated my mailing list subscription) > Am 08.12.25 um 18:42 schrieb [email protected]: > >> 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. > > Sorry, the 6801 is okay. But far from "extremely nice […] for C" or > "better than pretty much anything". IMO, the STM8 is far better, and > some of the Z80-derivatives with efficient stackpointer-relative > addressing are also quite good, the HCS08 isn't that bad either (though > its sp-relative adressing mode is less efficeint than zero-page > addressing, which makes it worse than STM8 or those Z80-derivatives > mentioned before). I am looking at code density and performance numbers. It certainly beats the Z80 derived stuff I've looked at (Rabbit, Z280) for most cases. STM8 I'm not really familiar with at it's a modern microcontroller not a "real" CPU 8) Pretty much every C operation can be done on n,X and that means you just have D as the working value and never really do much register allocation or cleverness. In theory you can do clever stuff for an 8bit counter working on an 8bit value but that's about it. > > 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. […] > > Thanks. That experience is certainly helpful for me to get a better idea > of the MC6801. The other things I can think of which are probably useful Once you get to 6801/3 the X register becomes doubly useful. The obvious usage is that it is whatever you were pointing at last. The second use case is where you can generate something efficiently into X as an argument you can PSHX faster and one byte shorter than PSHA/B. So for example fcc will generate LDX _global PSHX LDX #1234 PSHX for function calls. PULX is also very handy for taking stuff back off the stack on a return from a function. Classic 6800 this is horrible and fcc 6800 specific ABI has the called function doing the cleanups. Constant loads can be optimized a lot of the time if you know the old A and B values or half is zero as is common, or on raw 6800 if they are the same - also common for -1. Fcc spends a certain amount of effort not just turning LDD #0 into CLRA CLRB but also generating stuff using TAB and TBA when it makes sense, especially on 6800 itself that has no LDD so stuff like LDA #0xFF TAB is shorter. Useful tricks 6800: PULX is TSX (if needed) LDX ,X INS INS All: 16bit negate is NEGA NEGB SBCA #0 There is stuff I didn't really get into with fcc because of space constraints running on a 6803 itself - Using A and B as two independent working values when possible (which is rare, and it's hard to do ops between registers too) - Using direct page values for "registers" other than using a word for the upper half of the 32bit working value, and some scratch registers in helpers. Unlike TMS7000 influenced targets or even 6502 there's not much you can do directly with a direct page or register memory value that helps except byte inc/dec (asm 680x regularly uses a direct page value for dec and branching on loops) I can imagine there are cases where you are pointer chasing in a loop that a direct page "register" would pay off to avoid having to keep reloading things through tsx and ldx n,x but that's beyond what my little compiler can grok. A modern vaguely smart cross compiler for 680x would be nice to have. Alan
_______________________________________________ Sdcc-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sdcc-user
