Re: 8-bit processor specific techniques

"lucretia9@lycos.co.uk" <laguest9000@googlemail.com>
Tue, 29 Sep 2015 10:55:28 -0700 (PDT)

          From comp.compilers

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)
| List of all articles for this month |
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]


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.