[M3devel] 64 bit fixes?

[Tony Hosking]

The constants MOne, etc are used explicitly with specific precision by  
the compiler front-end.   These constants indicate that they have a  
certain number of significant bytes in their representation.  If you  
truncate the 8 bytes to 4 bytes for 32-bit then we know that the value  
will still be correct.  Making it length 1 breaks the use of the  
contants in both 32-bit and 64-bit representations.  These changes  
were made when I put in the LONGINT support -- that's why they are  
different from PM3.


On Feb 26, 2008, at 2:53 PM, Jay wrote:

>  I haven't tested this but it looks very suspicious..
>  When targeting 64 bit targets, the compiler thinks [-1 .. 1] is  
> empty.
>  When compiling things like "compare" functions.
>  I didn't debug it but just looked at the code.
>
>  ===================================================================
>  RCS file: /usr/cvs/cm3/m3-sys/m3middle/src/TInt.i3,v
>  retrieving revision 1.4
>  diff -r1.4 TInt.i3
>  26c26
>  <   MOne = Int{NUMBER (IBytes), IBytes{16_ff,16_ff,..}};
>  ---
>  >   MOne = Int{NUMBER (IBytes), IBytes{16_ff,16_ff,16_ff,16_ff, 
> 16_ff,16_ff,16_ff,16_ff}};
>
>
>  another fix might be:
>
>
>  >   MOne = Int{1, IBytes{16_ff}};
>
>  IBytes used to be 16 bit integers but now is 8 bit integers.
>  PM3 has:
>
>   Zero = Int { IChunks {16_0000, 16_0000, 16_0000, 16_0000}};
>   One  = Int { IChunks {16_0001, 16_0000, 16_0000, 16_0000}};
>   MOne = Int { IChunks {16_ffff, 16_ffff, 16_ffff, 16_ffff}};
>
>  which seems adequate for what is likely going on in these parts.
>
>  I believe ".." fills with zeros, not the previous value.
>
>   Also, is this objectionable?
>
>  RCS file: /usr/cvs/cm3/m3-libs/m3core/src/text/TextLiteral.i3,v
>  retrieving revision 1.2
>  diff -r1.2 TextLiteral.i3
>  15c15
>   <   MaxBytes = LAST (INTEGER) DIV BITSIZE (Byte) - 32;
>   ---
>   >   MaxBytes = 16_FFFFFCD; (* LAST (INTEGER) DIV BITSIZE (Byte) -  
> 32; *)
>
>  Maybe. The 32 bit compiler doesn't like such large types (that  
> follow from the use of this).
>  Maybe preferable to allow 32 bit hosted compiler to allow 64 bit  
> sized types?
>
>  - Jay
>
> From: jayk123 at hotmail.com
> To: m3devel at elegosoft.com
> Date: Tue, 26 Feb 2008 18:53:58 +0000
> Subject: [M3devel] tangential 64 bit...
>
> alpha/osf doesn't work because basictypes/ctypes has a problem with  
> the 32bit or 64bit types.
> specifically "unsigned long" is "empty" for some reason and many  
> errors cascade from that.
>
> if you change:
>   unsigned_int       = [16_0 .. 16_ffffffff];
> to
>   unsigned_int       = [16_0 .. 16_fffffffe];
>
> you get:
>
>
> ***
> *** runtime error:
> ***    An array subscript was out of range.
> ***    file "../src/TWord.m3", line 199
> ***
>
> Presumably fixing this first problem is the first step in any "real"  
> 64 bit target (SPARC64, PPC64, AMD64, IA64), and the second problem  
> should just be fixed as a matter of course.
>
> I know this is the least of anyone's concerns..
>
>  - Jay
>
>
> Connect and share in new ways with Windows Live. Get it now!
>
> Helping your favorite cause is as easy as instant messaging. You IM,  
> we give. Learn more.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080226/57fa09cf/attachment-0002.html>