[M3devel] [Fwd: Re: A nonnative 64-bit language proposal]

[Tony Hosking]

My LONGINT implementation addresses many of your concerns.  The  
LONGINT space is segregated from the INT space.  I want to come up  
with an implementation that also permits ordinals based on LONGINT in  
addition to the current system of ordinals based on INTEGER.  This  
requires revisiting the language spec and pushing through the  
implications.  I'm going to look at that briefly before moving on to  
fixing user-level threading for all targets.

On Oct 26, 2006, at 2:05 AM, Mika Nystrom wrote:

> Hello everyone,
>
> I have read the various proposals for supporting integers of different
> bit sizes and am getting a little worried that they are running
> away from the traditional Modula-3 simplicity.  As far as I know,
> there is very little in Modula-3 that depends on the actual size
> in bits of INTEGERs and CARDINALs.  It doesn't seem to me to make
> much sense to introduce types like Int32.T and Int64.T and then
> make the definition Int32.T = INTEGER (on one platform) and Int64.T
> = INTEGER (on another platform).  I'm wondering if it would instead
> be possible to introduce a new group of types in the sense that
> Modula-3 now has integer types and floating-point types, and call
> these types "fixed width" or "specified width" types.  Conversions
> between these types and INTEGER or CARDINAL would have to be done
> using functions (operators) that are the analogs of FLOAT, ROUND,
> etc.  Standard arithmetic operators would be overloaded just like
> they are today for integers and floating-point numbers.  Am I just
> duplicating someone else's proposal here?  Perhaps this proposal
> doesn't address everything one might want to do with these extended-
> size types?
>
> Maybe I am just dreaming about getting Modula-3 running on a
> DECsystem-20 with 36-bit integers...with pickles that are  
> interchangeable
> with i386 pickles, of course.
>
> What do people want to do with these extended-size types anyhow?
> It seems good to me that INTEGER is the largest type that I can
> expect my processor to calculate efficiently with.  I would use
> BYTESIZE or BITSIZE to pack my data into as few INTEGERs as possible
> and write my code to be flexible about the BYTE/BITSIZE... but OK,
> I can see the rationale for hiding all this in the compiler (and
> inlining everything) in the few cases where I might want four-function
> arithmetic on (specifically) 64- or 128-bit integers.
>
>     Mika
>
> Darko writes:
>> Actually I stated the wrong reason for that one, it's really an
>> argument against mixed integer assignment.
>>
>> And saying that it looks right from the C/C++ point of view is pretty
>> damning...
>>
>> On 25/10/2006, at 9:46 PM, Olaf Wagner wrote:
>>
>>> Mail from unsubscribed address forwarded to the list...
>>> ---------------------------- Original Message
>>> ----------------------------
>>> Subject: Re: A nonnative 64-bit language proposal
>>> From:    hendrik at topoi.pooq.com
>>> Date:    Wed, October 25, 2006 14:22
>>> To:      m3devel at elegosoft.com
>>> -------------------------------------------------------------------- 
>>> --
>>> ----
>>>
>>> On Wed, Oct 25, 2006 at 04:15:07AM -0700, Jay wrote:
>>>>
>>>> For your example to compute as an integer even if that overflows  
>>>> and
>>>> it wouldn't as a longint seems right from my C/C++ point of view.
>>>
>>> I've always thought C/C++ were badly wrong on this one, even
>>> from their own archaic low-level machine-oriented viewpoint.
>>> Most computers have integer multiply instructions that return a
>>> double-length product.
>>>
>>> -- hendrik
>>>
>>>