|8-bit processor specific techniques firstname.lastname@example.org (email@example.com) (2015-09-27)|
|Re: 8-bit processor specific techniques firstname.lastname@example.org (BGB) (2015-09-27)|
|Re: 8-bit processor specific techniques email@example.com (Walter Banks) (2015-09-28)|
|Re: 8-bit processor specific techniques firstname.lastname@example.org (email@example.com) (2015-09-29)|
|Re: 8-bit processor specific techniques firstname.lastname@example.org (BGB) (2015-09-29)|
|Date:||Tue, 29 Sep 2015 10:55:28 -0700 (PDT)|
|Keywords:||code, optimize, comment|
|Posted-Date:||29 Sep 2015 17:19:49 EDT|
On Monday, 28 September 2015 20:26:51 UTC+1, Walter Banks wrote:
> > [There are plenty of compilers for 8 bit machines, particulary at
> > retrocomputing sites, but I don't recall a lot of interesting code
> > generation stuff. They tend to have so few registers and be so
> > irregular that little of the optimization stuff intended for code
> > generation applies. -John]
> John, you actually have identified the source for a lot of code
> generation technology used in 8 bit compilers. There is a wealth of
> material in some of the compilers that is used to map processors with
> unusual instruction sets on to C.
I'll have to take a look at these compilers.
> Unfortunately most of this material has never been published and
> hasn't been the focus of research projects. The techniques used mostly
> show up in application specific ISA's. This is the type of processor
> whose applications tend not to be hosted and are small enough that
> compilers can be exhaustive and often have tight execution
All the documented stuff is targetting 32+ bit arches.
> A couple starting places for this type of compiler. Once parsed
> implement a strategy pass to map out application implementation
> approachs this time. Seriously consider dispensing with linkers for
> this type of compiler, their original purpose was to allow separately
> compiled modules and combine them later, in this type of compiler
> cross compiling a whole application is both possible and appropriate.
> [Agreed about the linker bit. These days, in the tool sets for
> embedded processors the object files that the compilers create are
> really just an intermediate code, and the linker does a global
> optimization pass over the whole program and only then generates
> the machine code. -John]
I intend for the project to have multiple back-ends, using LLVM as one (to
start and for access to Apple OSes) and a full Ada one. I'm not sure about
just producing a final binary for 8-bit targets as there will be a system rts
library for each target and that needs to be linked. Yes, it could be just
built straight in memory. I'd have to look at it.
[Re linker, the library is just a library of intermediate code. Pull in
the parts you need, optimize and generate the code for the whole program.
A little googlage suggests that there is or was an 8-bit back end for
Gnu GNAT, although it's hard to tell in what state it is. -John]
Return to the
Search the comp.compilers archives again.