Re: [Tack-devel] back-end tables, assemblers, and front-ends

[Gregory T. (t. K. <gt...@di...>]

At 11:13 AM -0400 7/19/06, David Given wrote:
>Yup. The whole system is done in multiple stages:
>
>   source file
>-> preprocessor
>-> front end compiler (emits em assembly)
>-> global optimiser (type 1)
>-> global optimiser (type 2)
>-> ...etc...
>-> back-end (emits native assembly)
>-> peep-hole optimiser
>-> assembler (emits ack.out object file)
>-> linker (emits ack.out binary)
>-> converter (emits native binary)
>
>For speed, the system tends to use a binary encoding of the em assembly
>rather than actual text. Every stage is a separate executable; look in
>lib.bin for all the bits.

Ok, "A Practical Toolkit For Making Portable Compilers" has the following:

1. The preprocessor.
2. The front ends.
3. The peephole optimizer.
4. The global optimizer.
5. The back end.
6. The target machine optimizer.
7. The universal assembler/linker.
8. The utility package.

This has peephole optimization before the global optimizer and isn't=
 platform dependent.  Which version is correct?  :-)

I've been reading about the optimizers and been wondering about their impact=
 on the object code and instruction scheduling.  While once upon a time RISC=
 was supposed to be a one instruction, one cycle design, pipelining killed=
 that dream.  PowerPC is prone to performance nose-dives when instructions=
 are not scheduled well and bubbles or instruction dependencies occur (in=
 particular operations that set the conditional registers for branching). =
 While the actual number of cycles each instruction takes is not easily=
 determined without the NDA documentation (Book IV), it is possible to=
 minimize bubbles and waits by scheduling operations well in advance of when=
 the conditional branch needs to be evaluated.  On the surface, this appears=
 to be counter to the peep-hole optimization as described by the overview. =
=20

Can the target machine optimizer reverse some/most/all of the effects of=
 peephole optimization? (I'm trying to figure out all of the parts that need=
 to be written.)

On the plus side, I like how the global optimizer appears to be able=
 (according to the ngc doc) to give hints regarding register usage.  This=
 should help a lot in the stack->register translations for the backend.

thanks,
tim


Gregory T. (tim) Kelly
Owner
Dialectronics.com

P.O. Box 606
Newberry, SC 29108

"Anything war can do, peace can do better."  -- Bishop Desmond Tutu