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

[Jay K]

I think it isn't just TextLiteral.MaxBytes.


How do I declare an unbouned-ly sized array?
At the end of a record?
Doesn't matter?


For TextLiteral.MaxBytes, are you ok then with a 512MB limit, even for 64bit?


 - Jay


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

Yes, I want to avoid use of LONGINT in the compiler proper.If you want to talk about target sized integer values in the front-end then yes, Target.Int is what you want, I suppose.But I still don’t understand the precise use-case that you are proposing.In the case of TextLiteral.MaxBytes why would 512 Mb ever be too small?I cannot imaging a text literal that big, ever.

On Sep 3, 2013, at 12:55 PM, Jay K <jay.krell at cornell.edu> wrote: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



Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAMobile +1 765 427 5484


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