Nicholas Clark wrote:
On Tue, Oct 29, 2002 at 08:26:00AM +0100, Leopold Toetsch wrote:
But then you end up with a messier two level register spillage problem at
compile time, don't you?
Yes.
...Which values to spill from fast to slow registers,
and which values to spill further from slow to stack?
imcc does already spilling if more then 32 registers per type are used. Adding another step to optimize for 3 * 4 usage wouldn't be much different IMHO. It could probably done in one step, when we define I0-I3, S0-S2 ... as the "fast" registers.
Though I didn't thin much of this until now.
... And is there much literature on this sort of thing?
Dunno.
And the fast registers are going to be called ax, bx, cx and dx? :-)
How did you know that ;-) No actually I'm always thinking of 3*4 registers.
I was also thinking of the various fixed sized integer ops for JVM or C#. The load/store ops would prepare integers of needed size and do sign extension when necessary.
I've had 3 drafts at responding to this, and I conclude "my brain hurts" I don't see an "obvious" clean solution to this, specifically 64 bit ops that run correctly on 32 bit native systems, but take advantage of 64 bit native systems.
2 separate core.ops files e.g. core32.ops emulating 64bit ints, and core64.ops with native 64bit ints, generated from core.ops?
Nicholas Clark
leo
