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

[Tony Hosking]

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 University
305 N. University Street | West Lafayette | IN 47907 | USA
Mobile +1 765 427 5484





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