[Oberon] Oberon performance (long)
reali at acm.org
Tue Apr 15 23:01:47 CEST 2003
> And here folows part of [Decoder.Decode Simple.Obx ~] output, where
> I have marked (and kind of commented) those instructions which
> an agressively optimizing compiler would have been "optimized away",
> or changed with better ones.
This is correct. A few instructions could be removed.
There are basically two approaches: finding a small local optimization
which achieves this (e.g. the register allocator could remember the
last value loaded in a register and propose the same register instead
of loading it again), or implementing CSE (common subexpression
elimination) in the compiler.
The compiler first emits the code in an intermediate representation (LIR)
in PCLIR). Then the installed backend (PCG386 + PCO for i386) will
translate the LIR to i386 after a small optimization step to reconstruct the
complex addressing modes instead (and at the same time remove a few
My proposal would be to go for the first solution: this is a rather local
which could give some good results (in the case you presented), without
requiring a major attack to the compiler.
Steps (in PCG386):
note: the allocated registers (reg32, reg8) contain the pc address that
1. keep a copy of reg32/reg8 (or update the copy when the register is freed)
2. when loading a register (GenLoad), first check if a released register
contains the value
> I have no idea, how hard will it be to change this.I did take a look at
> the code in PC*.Mod (for an hour or so) and I have run into these lines
Sorry, this is just out of context.... but looks like the generation of the
code in PCC.
> ELSIF x.mode = Reg THEN
> (* O.K. already loaded *)
More information about the Oberon