<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
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.<BR>
I just added like four functions to TInt.<BR>
<BR>
<BR>
>>> I want compile time arithmetic that does overflow checks to a specified precision. <BR>
I actually suspect precision should be given in bits, or perhaps via a CGType, but that is a smaller matter.<BR>
Currently precision is specified in bytes.<BR>
<BR>
<BR>
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,<BR>
requires "doubling" the function calls. If every single function is always paired with another, or multiple other,<BR>
that seems ripe for wrapping up in their own functions. Doesn't it?<BR>
And then, it turns out, carrying along a precision seems reasonable too, so there is a new type.<BR>
I understand it'd be more efficient to inline in the caller but I don't like that approach, of<BR>
having good abstraction boundaries, and then manually partially inlining across them.<BR>
<BR>
<BR>
At the very least therefore, I'd want to add, say:<BR>
M3x86Rep.Add, Sub, Multiply, Shift<BR>
<BR>
<BR>
that are all one liners over TInt/TWord.<BR>
<BR>
<BR>
Those one liners I have simply put in TIntN/TWordN.<BR>
Which is just perhaps a nicer factoring.<BR>
Very hypothetically, other backends could use them.<BR>
In reality there's only two, without much danger of their being more.<BR>
I think the best we could hope for is I can "extend" m3back, but it'd still just be m3back and<BR>
the code could still go there if you really want.<BR>
<BR>
<BR>
By adding four small functions to TInt I avoid TIntN/TWordN knowing the representation.<BR>
However, by virtue of their living in m3middle, I also made it ok for them to know the representation.<BR>
As well, as you said, it is only partly opaque.<BR>
<BR>
<BR>
All that is to say, there are many almost identical options here.<BR>
The code could go in m3back if you really want.<BR>
Or the functions I added to TInt could go in TIntN/TWordN.<BR>
Or I could even, in a stretch, not have the overflow checking -- it historically wasn't there.<BR>
But I think having it is an improvement.<BR>
<BR>
<BR>
I still do blatantly violate the abstraction boundary here:<BR>
<BR>
<BR>
PROCEDURE init_int (u: U; o: ByteOffset; READONLY value: Target.Int; t: Type) =<BR> BEGIN<BR>...<BR>
u.obj.appendBytes(u.init_varstore.seg, SUBARRAY(value, 0, CG_Bytes[t]));<BR><BR>
appendBytes (s: Seg; READONLY bytes: ARRAY OF UINT8);<BR><BR>
<BR>
That is really imho the main outstanding problem in this area.<BR>
I should try using ToBytes.<BR>
And if I just ignore its return value, should work.<BR>
<BR>
<BR>
- Jay<BR><BR>
<BR>> From: hosking@cs.purdue.edu<BR>> Date: Fri, 26 Feb 2010 10:14:34 -0500<BR>> To: jkrell@elego.de<BR>> CC: m3commit@elegosoft.com<BR>> Subject: Re: [M3commit] CVS Update: cm3<BR>> <BR>> These don't belong here!<BR>> <BR>> 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.<BR>> <BR>> On 26 Feb 2010, at 12:14, Jay Krell wrote:<BR>> <BR>> > CVSROOT: /usr/cvs<BR>> > Changes by: jkrell@birch. 10/02/26 12:14:58<BR>> > <BR>> > Added files:<BR>> > cm3/m3-sys/m3middle/src/: TIntN.i3 TWordN.i3 TWordN.m3 <BR>> > <BR>> > Log message:<BR>> > initial copies from m3back/M3BackInt, M3BackWord<BR>> <BR> </body>
</html>