[M3devel] A "radical" proposal: drop LONGINT

[Tony Hosking]

PS  Any type that *requires* 64-bit could be represented as:

ARRAY [0..1] OF BITS 32 FOR [0..16_FFFFFFFF]

or

RECORD x, y: BITS 32 FOR [0..16_FFFFFFFF] END

Is there ever a need to treat these as 64-bit integers?

On 6 Jan 2010, at 02:06, Tony Hosking wrote:

> What do you need those 64-bit types for on 32-bit machines?  On 32-bit machines INTEGER would still be 32-bit.
> 
> On 6 Jan 2010, at 01:12, Jay K wrote:
> 
>> 
>> Can I still have:
>> TYPE INT64 = BITS 64 FOR [16_8000000000000000..16_7FFFFFFFFFFFFFFF];
>> or
>> TYPE INT64 = [16_8000000000000000..16_7FFFFFFFFFFFFFFF];
>> ? defined in an interface, not in the language?
>> 
>> 
>> If so, probably ok.
>> 
>> 
>> (And can I also somehow get:
>> TYPE UINT32 = BITS 32 FOR [0..16_FFFFFFFF];
>> TYPE UINT64 = BITS 64 FOR [0..16_FFFFFFFFFFFFFFFF];
>> or
>> TYPE UINT32 = [0..16_FFFFFFFF];
>> TYPE UINT64 = [0..16_FFFFFFFFFFFFFFFF];
>> ?
>> )
>> 
>> 
>> Even on 32 bit machines?
>> 
>> 
>> I know there is interface Word.
>> 
>> 
>> And then, what is the difference between:
>> 
>> 
>> on 32bit:
>>   INTEGER vs. [16_80000000..16_7FFFFFFF] 
>>   CARDINAL vs. [0..16_7FFFFFFF] 
>> 
>> 
>> on 64bit:
>>   INTEGER vs. [16_8000000000000000..16_7FFFFFFFFFFFFFFF] 
>>   CARDINAL vs. [0..16_7FFFFFFFFFFFFFFF] 
>> 
>> 
>> Any at all?
>> Just that array sizes are cardinal?
>> 
>> 
>> I don't know much about the language issues, but dealing with 64bit integers in 32bit Modula-3 ought to be about as easy and efficient as dealing with them in C and C++ I think. Hm..and why? Well..file sizes should be represented as 64bit integers, though they aren't yet..it seems to be a significant interface breaking change..though maybe range types aren't where LONGINT would be? I'll have to try that..
>> 
>> 
>> - Jay
>> 
>> 
>> ________________________________
>>> From: hosking at cs.purdue.edu
>>> Date: Tue, 5 Jan 2010 21:59:42 -0500
>>> To: m3devel at elegosoft.com
>>> Subject: [M3devel] A "radical" proposal: drop LONGINT
>>> 
>>> 
>>> 
>>> Now that Jay has carefully refactored all the C-dependent code, I'd like to pose the following question. What say we clean things up, revert to the original clean language definition, and eliminate LONGINT? It was only ever there for compatibility with C headers anyway, and these have all now been nicely abstracted away. The only remaining uses of LONGINT are in defining Modula-3 alternatives for C structs. These can be rewritten to something other than LONGINT.
>>> 
>>> 
>>> 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 		 	   		  
> 

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