[M3devel] INTEGER

[Jay K]

Thank you Rodney. Good, interesting points.

 

 

 > and 32 bits is still capable of a lot

 

 

Agreed. There is an interesting construct that seems common -- 64bit kernels that can run 32bit or 64bit usermode code. That is what NT looks like, and Solaris, and Linux on sparc, and Irix (obsolete thought it may be..), and AIX, and HP-UX, and at least some configurations of Mac. In particular I read that sparc32 is quite obsolete from the Linux kernel point of view, there is no 32bit sparc Linux kernel, but 32bit usermode code is still fine. There is probably some correlation to like "systems that moved to 64bit processors earlier provide better support for 32bit usermode", and "systems that moved to 64bit processors later see 32bit support as more temporary". ie. commercial Unix moved to 64bit first, NT and free Unix later. OpenBSD is "pure", they only ever support one "architecture".

 

 

The seeming "problem" (not a problem in this context) is managing multiple GB of cheap physical RAM across an entire physical system. The overall system these days can have so much memory, but individual processes don't necessarily need it. As well, people often speak of 64bit being slower due to larger pointers, larger data. As well as larger code to load 64bit values. x86 is a bit of anomaly here in that the widening to 64bits also "cleaned up" a lot -- added many more registers not just wider registers, established a baseline for a different floating point instruction set (SSE), easier to generate position independent code via RIP-relative addressing, and at least on NT a better model for exception handling. So x86 switching to 64bit is a better sell than others. But still has the larger pointers/data.

 

 

So you know, what size buffer do I need to hold the concatenation of two strings whose maximum length is 100? Or what size integer do I need to hold the result of multiplying two n bit integers?

The kernel overarches all pieces/processes and needs perhaps larger capacity to handle it all than the pieces themselves need.

 

 

 > proliferation of embedded and hand-held devices, which as I am

 > hearing, are already well out ahead of server and desktop computers in raw processor count


 

I heard this over 10 years ago, that embedded systems ship far more processors than "computers", though it was lower end devices -- cars, microwaves, digital watches.
This world lingered in programming in assembly and using cheaper 8 and 16bit CPUs and MMU-less hardware longer. Manufacturing in such large volume, it was worth saving money. Nowadays we hear about them all being 32bit and having MMUs (e.g. phones).

 

 

 > Not everybody buys the newest every three years

 

 

We are closer to 7 years into AMD64 though. :) 

Except then 32bit came back -- Atom. :)


 

 - Jay


 
> Date: Tue, 20 Apr 2010 10:29:42 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] INTEGER
> 
> The designers of Modula-3 gave use not one but three floating point types.
> They explicitly justified this as matching the range of hardware arithmetic
> provided by set of common processors of the day.
> 
> They didn't say this (to my knowledge), but one integer type also matched
> the hardware of the day. But the period when practically all processors
> had the same word size was a historical anomaly. It was a nice halcyon
> time in that respect, and it allowed us to avoid some messy problems.
> 
> But it never was true prior to that era, and it is no longer true.
> I doubt it will be again. Despite the proliferation of 64-bit
> machines, there will be useful 32-bit ones around for a years.
> Not everybody buys the newest every three years, and 32 bits is
> still capable of a lot. I don't see them being retired at anything
> like the rate 16-bit machines were, because they don't suffer the
> limitations. And then we have the proliferation of embedded and
> hand-held devices, which as I am hearing, are already well out ahead
> of server and desktop computers in raw processor count.
> 
> So I think keeping two integer sizes in the language removes what
> many people would consider a serious obstacle. Moreover, the way
> the two integer sizes is are now defined is cleaner than I have
> seen in any other language. It also somewhat follows the way the
> three floating types were done in the original language in that
> it preserves the type-uniqueness of every expression. It further
> makes the static legality and semantics of code as close to
> implementation-independent as it was in the unmodified language.
> And it does not change the legality or static semantics of any
> old code.
> 
> Mika Nystrom wrote:
> > 
> > I actually do like Hendrik's idea of providing some sort of bignum
> > support. The reason I don't like LONGINT as much is that it seems it's
> > just a waste if we're all going to be using 64-bit machines anyhow.
> > It's arbitrary to have two fixed-width types. Why not three or four?
> > And why not 128 bits or 16 bits or 36 bits? If on the other hand
> > you got something substantial out of it that might be another story.
> > In that case, I would say LONGINT would be a reference type (much like
> > TEXT) with its associated Longint interface, and infix operators (the
> > way TEXT has &) per Jay's fondest dreams. Come to think of it, 
> > TEXT and such a LONGINT would have a lot in common. 
> > 
> > Mika
> > 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100420/49f955a7/attachment-0002.html>