[Oberon] Oberon performance (long)

Patrik Reali reali at acm.org
Mon Apr 21 15:24:03 CEST 2003


Hi Vasile!

> Well, it was the first thing I was thinking about, and may be I'll go this
way (or both woys). But just now
> a small modification in PCC.Field has compiled my toy example rather well,
and I'm interested to see if
> it could be done at the level of intermediate code generation. Here are
the relevant bits.
>
> PROCEDURE Field*(code: Code;  VAR x: Item;  fld: PCT.Field);
> BEGIN
> (* new code *)
> IF (lastLoad.level = x.level) & (lastLoad.offs = x.offs) THEN
> x := lastLoad;
> ELSE
> LoadAdr(code, x);
> lastLoad := x;
> END; (* if *)
>
> (* old code
> LoadAdr(code, x);
> *)
>
> x.mode := RegRel;  x.offs := fld.adr(PCBT.Variable).offset;  x.type :=
fld.type;
> x.deref := FALSE
> END Field;
>
>   Of course, ``lastLoad'' is new variable of type ``Item'', and it is
initialazed like this
>   lastLoad.level := -1;
>

This looks good, but keep in mind that:
* lastLoad should be cleared when a basic block is entered/left
* changes to the variable may invalidate it
* the compiler is concurrent, thus a global variable is not appropriate

>
>   (Of course it fails, on any real-world programs.)
>   I have tried to generalize this scheme, but I didn't succeed very much.
In fact at all.
>
>   There is one more question. Is the code generation done concurrently?

Yes. Every scope (i.e. module, method, and record/object) is parsed and
emitted concurrently. Thus, if you use a global variable for this, it will
be shared among all parsers!

> And how can I know which data belongs to which process? Using
AosActive.ActiveObject() ?

You can bind you process-related data to the scope, the current object, or
the code. In some cases this may require to pass an additional parameter,
and thus quite a bit of rewriting.....

> May this be a problem if I choose to modify the register allocator in x86
backend?

No, because the last part (LIR to i386 code translation) is done by only one
process.
I think the change in the back-end is the best solution: maybe not as simple
your proposal, but a little bit more generic, without being too much
complicated.

>
>   Any way, I will have to look deeply into the code. But this is a nice
intelectual challenge and I like it.
>
Good! I hope you can contribute some code, which I'll be more than glad to
add to the release.

-Patrik




More information about the Oberon mailing list