[M3devel] Unbounded but finite LONGINT (was: Re: Integers

[hendrik at topoi.pooq.com]

On Fri, Jan 08, 2010 at 01:50:28PM -0800, Mika Nystrom wrote:
> 
> Hendrik, do you mean:
> 
> "INTEGER is that subrange of LONGINT that happens to be efficiently 
> implementable on the target architecture"?
> 
> Why choose a specific size (e.g., 64 bits) for LONGINT, then?  Can I
> choose it as I please when I configure/compile the compiler?
> 
>     Mika

I've just been thinking of that.  Why even have a size for LONGINT?  Why 
not allow the programmer to use only subranges of LONGINT?  The 
arithmetic operations all have the property that you can compute 
subranges for the reults given subranges for the operands.  So 
intermediate results are all bounded in size, you can compute without 
overflow happening ... until you get to narrow the final result for 
assignment to whatever variable you want to 
assign it to.

I suspect there are compiler optimisations (well, let's ne honest, 
call them ameliorations) that could be performed to move the final 
range-truncate-check backward through the series of operations and limit 
the number of unnecessary bits that have been computed.  These 
ameliorations are likely to be more effective if no range check need be 
performed on final assignment (but there's always a conflict between 
amelioration and run-time checks, isn't there?)

We could do this for LONGINT completely independent of whatever we do 
with INTEGER.  INTEGER doesn't need to be a subrange of LONGINT.  
INTEGER is what you use when you particularly want to use 
machine-efficient data and operations.  LONGINT is what you use when 
that's not enough, and you want to statically specify the size of 
integer you need, and pay the price.  What with machines having carry 
and overflow flags, add-with-carry instructions, it chould be possible 
to generate reasonably efficient code anyway, without the full overhead 
of run-time-determined number sizes.

Most machines already have integer multiply instructions that return a 
double-length product.  It's such a pity to waste them.

-- hendrik