[M3commit] CVS Update: cm3

Wed Feb 10 19:03:04 CET 2010

One might imagine that:

VAR a,b:Target.Int;

TInt.EQ(a, b) implies TWord.Extract(a, 10, 8) = TWord.Extract(b, 10, 8) (for various values of 10 and 8).

but it doesn't. a could be a one byte zero, b a two byte zero, they are EQ, but Extract offset 10 will fail on a.

I believe the right way to say this is "referential integrity is broken".

EQ should imply equivalent in all observable ways, but it doesn't.

Because two numbers with different size can be EQ, but different size leads to other varying behavior.

I'm not 100% certain of any of this, but at least 50%.

And then, I realize, given a Long.T and a Word.T, you can't directly compare them.

You have to go through VAL, which makes them the same size.

So there's a missing analog sort of. Target.Int is more loosely typed than its analogs Long.T and Word.T.

Target.Int allows mixing arithmetic on different sized operands, for better and worse.

In one hand TWord.Extract should just act like the value is infinitely zero extended.

On the other, as you point out, that's not what its callers really expect.

It's probably a useful semantic, but in some other context.

And in that imaginary context, TWord.Insert might grow the data to fit.

And likewise TInt.Add/Subtract would grow the value, not overflow..

I realize, this is not the context we care about, we just need something for the compiler.

  (Though I'm not even sure what for, esp. why all the operations, other than for the constant folding in the NT386 backend, which makes good use of it all.)

 - Jay

From: hosking at cs.purdue.edu
Date: Wed, 10 Feb 2010 12:47:13 -0500
To: jay.krell at cornell.edu
CC: m3commit at elegosoft.com
Subject: Re: [M3commit] CVS Update: cm3

On 10 Feb 2010, at 11:35, Jay K wrote:

I was just trying to get longint initialization to work.
It seemed some of its problems might have been related to the fact that you Extract more high order zeros from TInt.Zero than Target.Int{Target.Integer.bytes}. But in the end (just now) I left TWord.Extract alone.
It remains true that EQ(TInt.Zero) has multiple representations and they don't act alike.

I don't understand what you mean by this statement.

 Maybe that is desirable.

 - Jay

From: hosking at cs.purdue.edu
Date: Wed, 10 Feb 2010 10:13:31 -0500
To: jay.krell at cornell.edu
CC: m3commit at elegosoft.com
Subject: Re: [M3commit] CVS Update: cm3

I'm not sure what you are trying to do or why.  Can you provide further explanation?

On 10 Feb 2010, at 04:47, Jay K wrote:

Shall I go ahead and let Extract act as if the data is infinitely zero extended?
That seems easy to do. I don't know if it will fix the problems, or cause other problems.
It is easy to try. The danger is if it causes subtle undetected-at-first-and-for-a-while problems.

 - Jay

From: hosking at cs.purdue.edu
Date: Mon, 8 Feb 2010 11:36:31 -0500
To: jay.krell at cornell.edu
CC: m3commit at elegosoft.com
Subject: Re: [M3commit] CVS Update: cm3

Yes, that is what I am now trying to clean up.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484

On 8 Feb 2010, at 11:18, Jay K wrote:

Rodney I *think* generally mixed sizes are supported in TWord, TInt.
  Though I don't necessarily understand all of the code.
There was a problem recently fixed, granted.
One problem here though is that you can't TWord.Extract beyond the size.
So the varying sizes of "zero" behave differently.
You might imagine it's zeros as far out as needed, but it doesn't work that way currently.

 - Jay

> Date: Mon, 8 Feb 2010 10:02:58 -0600
> From: rodney_bates at lcwb.coop
> To: m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
> 
> 
> 
> Jay K wrote:
> > I wonder if we need
> > TInt8, TInt16, TInt32, TInt64, TInt, TLong
> > TWord8, TWord16, TWord32, TWord64, TWord, TLongWord
> > 
> > that accurately implement ints/words of the exact specified size,
> > with TInt/TWord/TLong/TLongWord depending on the target.
> > I wouldn't mind trying to remove this word "Word".
> > And replace it with UInt or such.
> > TInt, TUInt, TLong, TULong?
> > TSignedInt, TUnsignedInt, TSignedLong, TUnsignedLong?
> > TInt, TUnsignedInt, TLong, TUnsignedLong?
> > 
> > TInt.Zero is just always 8 bytes.
> > The size is I believe meant to be fairly opaque to the user.
> > This is the first I've noticed it being visible, such that TInt.EQ is 
> > true for values with "quite different" behavior. I would have "thunk" 
> > (thought without much thought) that anything TInt.EQ is more equivalent 
> > than they actually are.
> > 
> 
> Hmm. I recall in a discussion a while back that the arithmetic on
> target ints was not coded to handle operands with mixed values of
> n. Could this have something to do with this?
> 
> > 
> > - Jay
> > 
> > 
> >

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20100210/807b4ab0/attachment-0002.html>