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

[Jay]

How about in unsafe code? Just untraced ref T?
TextLiteral: ok I guess not. Can always break them up and concat them...compiler could do that.


I'd like to have m3-sys/mklib just keep everything in memory. Less code & maybe faster.

Thanks,
 - Jay

On Sep 3, 2013, at 1:12 PM, Tony Hosking <hosking at cs.purdue.edu> wrote:

> On Sep 3, 2013, at 1:50 PM, Jay K <jay.krell at cornell.edu> wrote:
> 
>> I think it isn't just TextLiteral.MaxBytes.
>> 
>> 
>> How do I declare an unbouned-ly sized array?
> 
> Can’t do in M3.  It’s not type safe.
> 
>> At the end of a record?
>> Doesn't matter?
>> 
>> 
>> For TextLiteral.MaxBytes, are you ok then with a 512MB limit, even for 64bit?
> 
> Can you really imagine typing a literal that is 512MB in length?
> 
>> 
>> 
>>  - 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 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/61ba75de/attachment-0002.html>