Related articles |
---|
8-bit processor specific techniques laguest9000@googlemail.com (lucretia9@lycos.co.uk) (2015-09-27) |
Re: 8-bit processor specific techniques cr88192@hotmail.com (BGB) (2015-09-27) |
Re: 8-bit processor specific techniques walter@bytecraft.com (Walter Banks) (2015-09-28) |
Re: 8-bit processor specific techniques laguest9000@googlemail.com (lucretia9@lycos.co.uk) (2015-09-29) |
Re: 8-bit processor specific techniques cr88192@hotmail.com (BGB) (2015-09-29) |
From: | "lucretia9@lycos.co.uk" <laguest9000@googlemail.com> |
Newsgroups: | comp.compilers |
Date: | Tue, 29 Sep 2015 10:55:28 -0700 (PDT) |
Organization: | Compilers Central |
References: | 15-09-019 15-09-023 |
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
> requirements.
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.
>
> w..
> [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
comp.compilers page.
Search the
comp.compilers archives again.