[M3commit] CVS Update: cm3

[Jay K]

Tony, I don't think this complicated TInt/TWord. Whatever I did add to them, we could move. I didn't change their existing code.

I just added like four functions to TInt.

 

 

 >>> I want compile time arithmetic that does overflow checks to a specified precision. 

  I actually suspect precision should be given in bits, or perhaps via a CGType, but that is a smaller matter.

  Currently precision is specified in bytes.

 

 

It is a small layering over TInt/TWord, but one I'd rather not foist on their clients, since it, as far as I can tell,

requires "doubling" the function calls. If every single function is always paired with another, or multiple other,

that seems ripe for wrapping up in their own functions. Doesn't it?

  And then, it turns out, carrying along a precision seems reasonable too, so there is a new type.

  I understand it'd be more efficient to inline in the caller but I don't like that approach, of

    having good abstraction boundaries, and then manually partially inlining across them.

 

 

At the very least therefore, I'd want to add, say:

  M3x86Rep.Add, Sub, Multiply, Shift

 

 

that are all one liners over TInt/TWord.

 

 

Those one liners I have simply put in TIntN/TWordN.

Which is just perhaps a nicer factoring.

Very hypothetically, other backends could use them.

  In reality there's only two, without much danger of their being more.

  I think the best we could hope for is I can "extend" m3back, but it'd still just be m3back and

   the code could still go there if you really want.

 

 

By adding four small functions to TInt I avoid TIntN/TWordN knowing the representation.

However, by virtue of their living in m3middle, I also made it ok for them to know the representation.

As well, as you said, it is only partly opaque.

 

 

All that is to say, there are many almost identical options here.

  The code could go in m3back if you really want.

  Or the functions I added to TInt could go in TIntN/TWordN.

  Or I could even, in a stretch, not have the overflow checking -- it historically wasn't there.

   But I think having it is an improvement.

 

 

I still do blatantly violate the abstraction boundary here:

 

 

PROCEDURE init_int (u: U; o: ByteOffset; READONLY value: Target.Int; t: Type) =
  BEGIN
...

    u.obj.appendBytes(u.init_varstore.seg, SUBARRAY(value, 0, CG_Bytes[t]));


    appendBytes (s: Seg;  READONLY bytes: ARRAY OF UINT8);


 

That is really imho the main outstanding problem in this area.

I should try using ToBytes.

And if I just ignore its return value, should work.

 

 

  - Jay


 
> From: hosking at cs.purdue.edu
> Date: Fri, 26 Feb 2010 10:14:34 -0500
> To: jkrell at elego.de
> CC: m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
> 
> These don't belong here!
> 
> Jay, can you please provide a coherent description of what your requirements are for backend compile-time arithmetic? I still don't understand what is causing all this churn. The TInt and TWord interfaces are well-defined, and have intuitive behaviour. If they are not suited to your purposes let's come up with something that is, without complicating the existing support.
> 
> On 26 Feb 2010, at 12:14, Jay Krell wrote:
> 
> > CVSROOT: /usr/cvs
> > Changes by: jkrell at birch. 10/02/26 12:14:58
> > 
> > Added files:
> > cm3/m3-sys/m3middle/src/: TIntN.i3 TWordN.i3 TWordN.m3 
> > 
> > Log message:
> > initial copies from m3back/M3BackInt, M3BackWord
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20100226/3c50d755/attachment-0002.html>