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

[Tony Hosking]

I think what you are advocating is Rodney's proposal + assignability of INTEGER and LONGINT + mixed arithmetic.

On 8 Jan 2010, at 18:05, hendrik at topoi.pooq.com wrote:

> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/7661b06f/attachment-0002.html>