[M3commit] CVS Update: cm3

[Jay K]

diff attached

 
> Date: Fri, 26 Feb 2010 13:48:34 +0000
> To: m3commit at elegosoft.com
> From: jkrell at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> 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.)
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20100226/cd6605fd/attachment-0002.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 1.txt
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20100226/cd6605fd/attachment-0002.txt>