[M3devel] 64 bit fixes?

[Jay]

Hm, I don't think that fixes it actually. I'll have to dig in later, if highlighting the problem doesn't make it obvious to others..
What was there didn't look right for 32 bits even, but probably is for some reason..
 
 - Jay


From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Tue, 26 Feb 2008 19:53:24 +0000Subject: [M3devel] 64 bit fixes?


 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.comTo: m3devel at elegosoft.comDate: Tue, 26 Feb 2008 18:53:58 +0000Subject: [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. 
_________________________________________________________________
Helping your favorite cause is as easy as instant messaging. You IM, we give.
http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080226/c6b813a3/attachment-0002.html>