[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