Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.compilers > #1617
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Newsgroups | comp.compilers |
| Subject | Re: 8-bit processor specific techniques |
| Date | 2015-09-27 17:34 -0500 |
| Organization | albasani.net |
| Message-ID | <15-09-022@comp.compilers> (permalink) |
| References | <15-09-019@comp.compilers> |
On 9/27/2015 9:30 AM, lucretia9@lycos.co.uk wrote: > I've been looking around for anything related to compiler development for > 8-bit processors. ... > [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] I am not sure what the best approach is, but yeah, I have doubts how well SSA would apply to this use-case. a lot probably depends on the specific ISA, for example, what makes sense for Z80 or 6502 may be rather different than for MSP430 or AVR8. if I were to make a guess, it might make more sense for a lot of targets to represent the code initially more as a sort of stack machine potentially with a lot of compound operations, and then try to run a variation of LZW over this (to build a dictionary of repeating patterns). the dictionary would retain any sequences longer than a certain minimum length (to offset the call/return overhead). the assumption would be to try to make the stack-machine sufficiently context independent that the same sequence of instructions will have the same behavior independent of caller. this means that if stack-relative addressing is used, the offsets of variables would be resolved in the stack IR (so that they are also constant in the output code). likely, a fairly minimalist register allocator would be used (if one is used at all), and would be mostly for caching the top stack items and maybe a few variables. likely, the main goal is mostly to minimize code size, as IME this tends to be a bigger factor than the execution time when it comes to small (8/16 bit) targets. in a way, this makes it closer to a data-compression problem than a traditional optimization problem. typically there is also a need for handling operations via internal function calls, as things like a hardware multiplication and multi-bit shifts tend to be absent. for example, one may see trickery like implementing multi-bit shifts via computed jumps into a sequence of single-bit shifts (the ISA in question could use PC as a GPR, and arithmetic on PC was done rather often), ... but, granted, I haven't done much personally in this area as of yet, and haven't really looked that much into how the existing compilers do it (at least much beyond their ability to somehow fit around 500 lines of C code into a 2kB ROM).
Back to comp.compilers | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
8-bit processor specific techniques "lucretia9@lycos.co.uk" <laguest9000@googlemail.com> - 2015-09-27 07:30 -0700
Re: 8-bit processor specific techniques for Ada Luke A. Guest <laguest@archeia.com> - 2015-09-27 23:04 +0100
Re: 8-bit processor specific techniques BGB <cr88192@hotmail.com> - 2015-09-27 17:34 -0500
Re: 8-bit processor specific techniques Walter Banks <walter@bytecraft.com> - 2015-09-28 11:04 -0400
Re: 8-bit processor specific techniques "lucretia9@lycos.co.uk" <laguest9000@googlemail.com> - 2015-09-29 10:55 -0700
Re: 8-bit processor specific techniques BGB <cr88192@hotmail.com> - 2015-09-29 20:06 -0500
csiph-web