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

[Tony Hosking]

Yes, I will make bootstrapped compilers available in the usual  
place.  Note that as soon as I check in the updates to CVS then old  
bootstrap compilers will no longer be able to compile m3core, since  
it mentions the type LONGINT in the Long.i3 interface.  Building with  
a compiler that supports LONGINT will involve the following bootstrap  
process:

1. Build and ship the old versions of m3core and libm3.
2. Build and ship m3middle, m3linker, m3front, m3quake, cm3
3. Build and ship the new version of the sources via do-cm3-std.sh
    using the compiler from step 2 (in INSTALL_ROOT/pkg/cm3/TARGET/cm3).
    Easiest way to do this is to "export CM3=INSTALL_ROOT/pkg/cm3/ 
TARGET/cm3"
    (where INSTALL_ROOT and TARGET match your system) and then execute:
	do-cm3-std.sh realclean
	do-cm3-std.sh buildship
    from the scripts sub-directory of a clean CVS checkout

I'll send a message once I have compilers available on my ftp site.


On Jul 19, 2007, at 2:41 PM, Darko wrote:

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