GCC for 8051 based architectures

[Dave Hudson]

Hi,

Julia Nilsson wrote:
> The problem with accumulator based architecture or
> harvard architecture where data memory and program
> memory are seperately addressed by different buses, is
> that memory operations are heavy also generating
> memory offset takes lots of instructions.
> 
> load Dptr
> add offset
> store Dptr
> << access memory from Dptr >>
> sub offset
> store Dptr

One possible solution here is to employ the same sort of solution used 
by many commercial 8051 compilers and replace these direct instructions 
with calls to a number of stub routines.  The stub calls require fewer 
instructions to simulate the access, albeit at an increased cost 
elsewhere (the call and return overhead for the stub functions).

If this approach is taken throughout the port then the generated code 
ends up looking a little like that for a threaded interpretter but will 
be quite dense.  Obviously it depends on the what sort of applications 
you wish to support, but it's surprising just how well this works in 
many embedded applications.

If you keep the rtl pretty conventional - i.e. don't prematurely split 
things and you let the normal optimization passes run you'll end up with 
pretty reasonable code and good overall structure.  Once you're at this 
level then you can always consider processor-specific RTL optimizations. 
  I have used this sort of approach very successfully while developing 
the IP2022 port (I'm trying to sort out how to merge our latest in-house 
changes back to the version currently in the FSF CVS repository) and 
it's possible to take advantage of gcc's structural optimization and 
still get very good low-level code.

FWIW in the case of the IP2022 we have only a 3 pointer regs and a 
single 8-bit accumulator reg for general operations.  Everything else is 
emulated via directly addressable memory locations (e.g. we have 32 
general purpose 8-bit regs emulated this way to allow 64-bit integer 
support).


Regards,
Dave