[M3devel] TInt/TWord/N

[Tony Hosking]

The solution is not to push upstream into m3middle.
I'll try to find some time to push through what is needed in m3back.  I can't promise anything soon.  Let's leave things lie for a while.  As I understand it your stuff in m3back is mostly working.  I took a look at the code there and I see a number of issues.  Hopefully I can get a look sometime.

-- T

On 26 Feb 2010, at 23:48, Jay K wrote:

> 
> Tony, I just don't understand what is wrong with TIntN, TWordN.
>  They are what TInt/TWord did for a long time after all. ?
> Sometimes we have 4 byte integers, sometimes 8. When 4, we want overflow checking in 4, for every single operation, not just a chop when they end up in a register or such. Right? It seems natural to bundle that up conveniently. And putting them in m3middle didn't seem so contaminating to me, since they layer thinly over Target.Int. Nor do I know what the fix is, short of inlining the repitious conversions and checks.
> 
> 
> - Jay
> 
> 
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Fri, 26 Feb 2010 19:51:15 -0500
>> To: jkrell at elego.de
>> CC: m3commit at elegosoft.com
>> Subject: Re: [M3commit] CVS Update: cm3
>> 
>> I've just spent most of the day decontaminating m3middle and putting TIntN and TWordN back into m3back as deprecated modules. m3back needs to be fixed to get rid of these. I don't have time to mess with this stuff and I am peeved that I wasted a whole day on this.
>> 
>> On 26 Feb 2010, at 13:48, Jay Krell wrote:
>> 
>>> 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.)
>>