[M3devel] codegen error (from Mika, new test p250)

Tue Jan 11 21:19:32 CET 2011

The point is that we want to have an opaque type.  One that can only meaningfully be manipulated by predefined library routines.  What the bits look like would be immaterial.

On Jan 11, 2011, at 2:33 AM, Jay K wrote:

> 
> Quibbling with the details:
> 
> Is this legal, on a 32bit system?
> 
> Longint.T = Longword.T = BITS 64 FOR ARRAY [0..1] OF [16_00000000..16_FFFFFFFF]
> 
> And even if it is legal, it is of dubious correctness, eh?
> For implementation of this in Modula-3, you want the low word to be unsigned and the high word to be signed.
> Granted, you want full range unsigned, so, like, Word.T, but you want 32 bits.
> 
> There should therefore be, like, interfaces Word32 and Word64 (ok, you already have Long). 
> 
> As well, the implementation on 64bit targets will perhaps suffer.
> 
> As well, does it work for 64bit targets? Isn't [00000...FFFFFFFF] 64 bits?
> Maybe you'd say:
> Longint.T = Longword.T = BITS 64 FOR ARRAY [0..1] OF BITS 32 FOR [16_00000000..16_FFFFFFFF]
> 
> 
> And then, *really*, you want the order/significance of the words to be endian-specific.
> 
> So, you'd want perhaps 3 implementations:
> 
> 64bit: Longint.T = INTEGER
> 32bit big endian: Longint.T = RECORD high: INTEGER; low: Word.T; END;
> 32bit little endian: Longint.T = RECORD low: Word.T; high: INTEGER; END;
> 
> 
> 
> or maybe just two:
> 
>  big endian: Longint.T = RECORD high: some-32bit-signed-type; low: some-32bit-psuedo-unsigned-type; END;
>  little endian: Longint.T = RECORD low some-32bit-psuedo-unsigned-type; low: some-32bit-signed-type; END;
> 
> 
> 
> Ultimately, the very very very general true point is:
>   extension via library is probably generally easier
>   BUT only makes for good results in an adequate language, e.g. one with operator overloading!
> 
> 
> Surely surely the compiler isn't so unmalleable?
> ie. we aren't stuck with the language asis because the compiler is too hard to change?
> 
> 
> I can't argue too strongly in favor of LONGINT.
> 
> 
> But..definitely there should be some reasonable convenient efficient way for dealing with 64bit integers.
>   32bit C implementations have had very good mechanisms for 25+ years.
>   It does seem a shame we seemingly can't/won't compete.
> 
> 
> And still. interface Rd/Wr I believe still need work..
> Probably to add a parallel set of functions ending in "L".
> 
>  - Jay
> 
> 
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Tue, 11 Jan 2011 00:58:35 -0500
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] codegen error (from Mika, new test p250)
>> 
>> I know what the problem is. The fix is not particularly pretty, and will entail tracking the stack types for integers (Int32 or Int64) throughout code generation.
>> 
>> This all leads me to wonder why we don't simply back LONGINT out of the language.
>> [I had mentioned my increasing unease with LONGINT in a prior e-mail a long time ago.]
>> 
>> We can replace LONGINT with Longint and Longword:
>> 
>> Longint.T = Longword.T = BITS 64 FOR ARRAY [0..1] OF [16_00000000..16_FFFFFFFF]
>> 
>> and define signed operations in Longint and unsigned operations in Longword.
>> These can be implemented efficiently as wrappers to appropriate C routines operating on "long long" or inlined if performance is a particular concern. We can provide conversion routines to/from INTEGER as needs.
>> 
>> Other than handling 64-bit file offsets, etc., does anyone really make use of LONGINT that argues convincingly for it to be retained?
>> 
>> On Jan 8, 2011, at 6:55 PM, Jay K wrote:
>> 
>>> 
>>> Thank you much. Please notice there are 2 or 3 similar problems. This shows only 1.
>>> See test p250.
>>> 
>>> 
>>> MODULE Main;
>>> 
>>> PROCEDURE F1(<*UNUSED*>x: LONGINT) = BEGIN END F1;
>>> 
>>> PROCEDURE F2() =
>>> <*UNUSED*>VAR x: [0L..0L];
>>> BEGIN
>>> END F2;
>>> 
>>> PROCEDURE F3() =
>>> VAR x: [0L..0L];
>>> BEGIN
>>> F1(x);
>>> END F3;
>>> 
>>> BEGIN
>>> F1(0L);
>>> F2();
>>> F3();
>>> END Main.
>>> 
>>> i.e. initializing local 0L..0L.
>>> Passing 0L..0L parameter.
>>> 
>>> - Jay
>>> 
>>> 
>>> ----------------------------------------
>>>> From: hosking at cs.purdue.edu
>>>> Date: Sat, 8 Jan 2011 16:59:33 -0500
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] codegen error (from Mika, new test p250)
>>>> 
>>>> I'll look into this one.
>>>> 
>>>> 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 Jan 8, 2011, at 12:17 AM, Jay K wrote:
>>>> 
>>>>> 
>>>>> fyi, small repro:
>>>>> 
>>>>> 
>>>>> MODULE Main;
>>>>> 
>>>>> VAR x: [0L..0L];
>>>>> 
>>>>> PROCEDURE F2(<*UNUSED*>x: LONGINT) = BEGIN END F2;
>>>>> 
>>>>> BEGIN
>>>>> F2(x);
>>>>> END Main.
>>>>> 
>>>>> (32) start_call_direct procedure:0x4 level:0
>>>>> (33) load var:0x2 offset:0x1A0(416) src_t:word_8 dst_t:int_32
>>>>> (34) comment comment:********* M3CG_Check ERROR *********** bad stack: expected [ Int64 ] got [ Int32 ]
>>>>> (35) pop_param type:int_64
>>>>> 
>>>>> 
>>>>> - Jay
>>>>> 
>>>>> 
>>>>> ________________________________
>>>>>> From: jay.krell at cornell.edu
>>>>>> To: m3devel at elegosoft.com; mika at async.caltech.edu
>>>>>> Subject: RE: codegen error (from Mika, new test p250)
>>>>>> Date: Thu, 6 Jan 2011 01:21:00 +0000
>>>>>> 
>>>>>> fyi:
>>>>>> 
>>>>>> jbook2:p250 jay$ rm -rf I386_DARWIN/
>>>>>> jbook2:p250 jay$ cm3 -keep
>>>>>> --- building in I386_DARWIN ---
>>>>>> 
>>>>>> new source -> compiling Main.m3
>>>>>> "../Main.m3", line 1: 1 code generation error
>>>>>> 1 error encountered
>>>>>> compilation failed => not building program "pgm"
>>>>>> Fatal Error: package build failed
>>>>>> jbook2:p250 jay$ cm3cg -y I386_DARWIN/Main.mc 2>&1 | grep -i comment
>>>>>> (4) comment comment:module global constants
>>>>>> (6) comment comment:module global data
>>>>>> (27) comment comment:F1
>>>>>> (34) comment comment:********* M3CG_Check ERROR
>>>>>> *********** bad stack: expected [ Int64 ] got [ Int32 ]
>>>>>> (43) comment comment:F2
>>>>>> (73) comment comment:Main_M3
>>>>>> (74) comment comment:module main body Main_M3
>>>>>> (83) comment comment:global constant type descriptor
>>>>>> (85) comment comment:global data type descriptor
>>>>>> (87) comment comment:module global constants
>>>>>> (90) comment comment:procedure names
>>>>>> (94) comment comment:procedure table
>>>>>> (101) comment comment:file name
>>>>>> (103) comment comment:type map for _t0174bdf4
>>>>>> (106) comment comment:type description for _t0174bdf4
>>>>>> (110) comment comment:module global data
>>>>>> (120) comment comment:typecell for _t0174bdf4
>>>>>> (141) comment comment:load map
>>>>>> (4) comment comment:module global constants
>>>>>> (6) comment comment:module global data
>>>>>> (27) comment comment:F1
>>>>>> (34) comment comment:********* M3CG_Check ERROR
>>>>>> *********** bad stack: expected [ Int64 ] got [ Int32 ]
>>>>>> (43) comment comment:F2
>>>>>> (73) comment comment:Main_M3
>>>>>> (74) comment comment:module main body Main_M3
>>>>>> (83) comment comment:global constant type descriptor
>>>>>> (85) comment comment:global data type descriptor
>>>>>> (87) comment comment:module global constants
>>>>>> (90) comment comment:procedure names
>>>>>> (94) comment comment:procedure table
>>>>>> (101) comment comment:file name
>>>>>> (103) comment comment:type map for _t0174bdf4
>>>>>> (106) comment comment:type description for _t0174bdf4
>>>>>> (110) comment comment:module global data
>>>>>> (120) comment comment:typecell for _t0174bdf4
>>>>>> (141) comment comment:load map
>>>>>> 
>>>>>> 
>>>>>> - Jay
>>>>>> 
>>>>>> 
>>>>>>> Date: Thu, 6 Jan 2011 01:26:15 +0000
>>>>>>> To: m3commit at elegosoft.com
>>>>>>> From: jkrell at elego.de
>>>>>>> Subject: [M3commit] CVS Update: cm3
>>>>>>> 
>>>>>>> CVSROOT: /usr/cvs
>>>>>>> Changes by: jkrell at birch. 11/01/06 01:26:15
>>>>>>> 
>>>>>>> Modified files:
>>>>>>> cm3/m3-sys/m3tests/src/p2/p250/: Main.m3
>>>>>>> 
>>>>>>> Log message:
>>>>>>> slightly simpler, same error
>>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 		 	   		  