[M3devel] A "radical" proposal: drop LONGINT

[Jay K]

Well..to be sure to get good codegen, given that the gcc backend and every C compiler these days supports 64bit integers "directly" (to the best of their ability, sometimes function calls are involved).
 
 
As well, you know, to get those nice operators +, -, *, /, :=, =, <>.
 
 
I realize it largely comes down to a matter of "convenient builtin special syntax" vs. "user defined types and inconvenient function calls".
 
 
Here does lie the argument that I should be able define operators for user defined types, instead just TEXT and INTEGER and sets getting the special powers..
 
 
Not to mention inlining via special support in the frontend.
(I realize a good backend could do the same).
 
 
interface int64;
 
T = ARRAY[0..1] OF INTEGER.
 
PROCEDURE +(a,b:T):T;
PROCEDURE *(a,b:T):T;
PROCEDURE /(a,b:T):T;
 
 
?
 
 
etc...
 
 
Basically the "builtin" types are always more "convenient" than any user defined types. Only C++ as far as I know really attemps to solve that problem..
 
 
 
 - Jay


________________________________
> From: hosking at cs.purdue.edu
> Date: Wed, 6 Jan 2010 02:11:53 -0500
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com; jay.krell at cornell.edu
> Subject: Re: [M3devel] A "radical" proposal: drop LONGINT
>
>
>
> 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
>
>