[M3commit] CVS Update: cm3
Jay Krell
jkrell at elego.de
Fri Feb 26 13:48:34 CET 2010
CVSROOT: /usr/cvs
Changes by: jkrell at birch. 10/02/26 13:48:34
Modified files:
cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3
M3x86Rep.i3 Stackx86.i3 Stackx86.m3
Wrx86.i3 Wrx86.m3 m3makefile
cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 TIntN.i3 TIntN.m3
TWordN.i3 TWordN.m3 Target.i3
Target.m3 m3makefile
Removed files:
cm3/m3-sys/m3back/src/: M3BackInt.i3 M3BackInt.m3 M3BackWord.i3
M3BackWord.m3
Log message:
introduce type Target.IntN which is Int plus a precision
just like the old Target.Int
(previously M3BackInt.Int)
make TIntN and TWordN support it
they are just thin wrappers over TInt, TWord
previously named M3BackInt, M3BackWord
add small amount of support to TInt:
SignExtend, SignedTruncate, ZeroExtend, UnsignedTruncate
These could, if desired, go into their only users: TIntN, TWordN.
(with the understanding that that Target.Int is "revealed" to them.)
add maxN, minN fields to Target.Int_type, that are equal to max and min but have a precision
NOTE: Don't worry Tony, the vast majority of m3middle, m3front, TInt, Tword are unchanged
This is "just" additions.
(Moving maintenance cost from m3back to m3middle, if that isn't a no-op.)
(Coming up with alternate names for M3BackInt, M3BackWord => TIntN, TWordN)
(A little unsatisfactory that N is bytes instead of bits.)
(What a fun little exercise that might be, changing Int to be array [0..63] of [0..1] :) )
While at it, in TIntN, rename things slightly:
FromInt => FromHostInteger
ToInt => ToHostInteger
"Int" is "Target.Int"
"HostInteger" is "INTEGER"
again, TInt/TWord/m3front/m3middle not much affected.
One fishy/uncertain thing in all of this, something to test out, is cross builds
that target NT386 from 64bit host. Is TIntN.ToHostInteger correct? Or do we
really need INTEGER to be 4 bytes throughout m3back?
(I know that mklib has little endian dependency.)
More information about the M3commit
mailing list