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

[Darko]

This really is great stuff Tony, thanks for doing the hard yards.  
Will you be making a build of this available in your usual spot?

I'd like to try this out for a while and look for creative ways to  
make it break (no offence intended) and get a feel for where it needs  
to be extended. In the spirit of the M3 founding fathers, I think we  
need some experience with this and then look at the simplest and  
smallest change we can do to support what is missing.

Cheers,
Darko.


On 19/07/2007, at 5:31 PM, Tony Hosking wrote:

> 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
>>>>
>>>>
>