[M3devel] TextLiteral.MaxBytes -- use LONGINT or Target.Int more?

[Jay K]

How do you suggest 32bit code deal with file sizes? And record/array offsets/sizes for 64bit targets?
double? That offers I think 53 bits, which is pretty good, but pesky floating point..
A library without infix notation?
C and C++ have been using __int64 and long long for this for going on 20 years.
And C++ has infix notation for arbitrary types.


I guess I will plumb Target.Int through?
I've started this before but it got tedious.


 - Jay

CC: m3devel at elegosoft.com
From: antony.hosking at gmail.com
Subject: Re: [M3devel] TextLiteral.MaxBytes -- use LONGINT or Target.Int more?
Date: Tue, 3 Sep 2013 08:11:32 -0400
To: jay.krell at cornell.edu

Don't plumb LONGINT throughout.  I still consider it an abomination.

Sent from my iPad
On Sep 3, 2013, at 1:53 AM, Jay K <jay.krell at cornell.edu> wrote:




I've complained about this before.


The frontend keeps track of things in bits in INTEGER.
Therefore TextLiteral.MaxBytes is around 512MB.


We could raise it for 64bit targets, but the 32bit cross compile to 64bits would fail.


Fixing this mostly but not entirely would be to plumb through LONGINT
"everywhere" instead of INTEGER.
We would still lose the sign bit and bits vs. bytes would lose us another 3 bits.
So we'd have a 60 bit limit instead of a 64bit limit.


Fixing it even more would require Target.Int.


Thoughts?


Is LONGINT safe to use now throughout cm3/m3front/m3middle/m3back?
Do we still require bootstrapping from LONGINT-less compilers?


Any lingering doubts as to its syntax and meaning?
I still think it should be named INT64.
Because in the future I want INT128 and I don't want LONGINT to grow in size.


Would it be considered adequate as a replacement for Target.Int?


If instead I plumb through Target.Int, any complaints?
Target.Int has the following advantages:
  When we need INT128 in the future, it is a very very very simple and small change.
   I already extended Target.Int from 64 bits to 72 bits.
  It works with old frontends.


Target.Int has the following disadvantages:
  no operator overloading so usage is cumbersome  
  slower 
  I still don't fully understand it, e.g. division 



 - Jay
 		 	   		  
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130903/51d644b2/attachment-0002.html>