[M3devel] 32bit host 64bit target TextLiteral recurring problem

[Jay]

> I don’t know what the static limit is on an array literal.


I suspect all sizes and offsets are limited to bit counts stored INTEGER.
So any field or type can be 512mb-1 max on 32bit hosted compiler and 2^56-1 for 64bit hosted compiler.


How about a syntax that omits the end of the range?
Type t = array [0..] of char?


 - Jay

On Jun 3, 2015, at 5:03 PM, Antony Hosking <hosking at purdue.edu> wrote:

> It would not make sense to store an entire blueray movie as a literal…better to structure it.
> I don’t know what the static limit is on an array literal.
> 
>> On Jun 3, 2015, at 7:14 PM, Jay K <jay.krell at cornell.edu> wrote:
>> 
>> sorry, I missed that it is literals...so I can convert a blueray movie into a source file containing the data all in a text? Far fetched.
>> An array of chars? Probably has same problem.
>> 
>> 
>> Can I/we please LONGINT-ize the compiler now, for all type sizes and field offsets?
>> 
>>  - Jay
>> 
>> 
>> 
>> Subject: Re: [M3devel] 32bit host 64bit target TextLiteral recurring problem
>> From: hosking at purdue.edu
>> Date: Wed, 3 Jun 2015 14:07:02 -0400
>> CC: m3devel at elegosoft.com
>> To: jay.krell at cornell.edu
>> 
>> It’s only TEXT literals that are limited here.  As in, what appears in a source program.
>> 
>> On Jun 3, 2015, at 1:49 PM, Jay K <jay.krell at cornell.edu> wrote:
>> 
>> I don't have any, but should we have such artificial limits?
>> I'm always nervous about "640k is plenty", "2gig is plenty", "4gb is plenty".
>> Thus -- size_t: "4gb is plenty for a 32bit host, but 64bit is unlimited."
>> And even that isn't right -- 4bg is often not lenty for a 32bit host.
>> File sizes exceed that long ago.
>> But "4gb is plenty for 32bit, 64bit is limited" is generally easy to code and I rest there.
>> 
>> 
>> Given that a blueray movie is an array of bytes, is a text inappropriate?
>> 
>> 
>> The actual diff presented just adjusts the limit by 8 bytes.
>> Ok?
>> Or must preserve pickles and can't do this w/o some other change?
>> This isn't a more general problem? Or usually pickles
>> are 32/64-compatible, but this is a most unusual case?
>> 
>> 
>> Thanks,
>>  - Jay
>> 
>> 
>> 
>> 
>> Subject: Re: [M3devel] 32bit host 64bit target TextLiteral recurring problem
>> From: hosking at purdue.edu
>> Date: Wed, 3 Jun 2015 13:24:36 -0400
>> CC: m3devel at elegosoft.com
>> To: jay.krell at cornell.edu
>> 
>> Why would you ever want a TEXT literal that is so large?
>> By the way, yes TextLiteral is an unsafe interface because of the need to index up to the MaxBytes bound, but the unsafe code is confined to the implementation of the interface.
>> A type can be neither unsafe nor safe.  It is code that is unsafe or safe.  Any code that can see the revealed definition of TextLiteral.T must be unsafe since the interface is unsafe.
>> 
>> On Jun 3, 2015, at 12:36 PM, Jay <jay.krell at cornell.edu> wrote:
>> 
>> I do this. I shouldn't have to make local edits each time. It isn't meant to only be once. I should be able to long-term use a 32bit toolset to target 32bit & 64bit.
>> 
>>  - Jay
>> 
>> On Jun 3, 2015, at 5:16 AM, Antony Hosking <hosking at purdue.edu> wrote:
>> 
>> Other than cross-compile from 32 to 64 bit what purpose does this serve?
>> 
>> Sent from my iPad
>> 
>> On Jun 2, 2015, at 9:58 PM, Jay K <jay.krell at cornell.edu> wrote:
>> 
>> We cannot cross from 32bit host to 64bit target.
>> 
>> 
>> Ok to commit this?
>> 
>> diff --git a/m3-libs/m3core/src/text/TextLiteral.i3 b/m3-libs/m3core/src/text/TextLiteral.i3
>> index fa72589..37bf238 100644
>> --- a/m3-libs/m3core/src/text/TextLiteral.i3
>> +++ b/m3-libs/m3core/src/text/TextLiteral.i3
>> @@ -12,9 +12,16 @@ UNSAFE INTERFACE TextLiteral;
>>  IMPORT RTHooks, TextClass;
>>  
>>  CONST
>> - (* DIV BITSIZE should not be here! *)
>> +(* When cm3 uses TInt and when pickle special cases this, it should be approx:
>> +    MaxBytes = LAST (INTEGER) - BITSIZE (INTEGER) * 2 *)
>> +(* This fails for 32bit host and 64bit target:
>> +    MaxBytes = 16_7FFFFFFF DIV BITSIZE (Byte) - 7; *)
>> +(* Until/unless unpickling special cases this, it must not be sizeof(INTEGER)
>> +   dependent. *)
>> + (* DIV BITSIZE should not be here -- compiler limitation due to
>> +    non-use of TInt. *)
>>   (* MaxBytes = LAST (INTEGER) DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); *)
>> - MaxBytes = 16_7FFFFFFF DIV BITSIZE (Byte) - 7; 
>> + MaxBytes = 16_7FFFFFFF DIV BITSIZE (Byte) - 15;
>>      (* - 8 * ORD(BITSIZE(INTEGER) = 64) *) 
>>      (* Do not adjust this for INTEGER size.  It makes T have different 
>>         fingerprints on 32- and 64-bit machines, which undermines pickling/
>> 
>> 
>> Yes I know TEXT pickles will be broken.
>> I propose that unpickle should special case a few values here.
>> Or, isn't the brand supposed to help?
>> Or, can we encode this in a better way, w/o an upper bound?
>> I know if you put in 0..0 or 0..-1 you incur range violations at runtime.
>> Which makes me wonder -- are TEXTs unsafe?
>> 
>> Should we support a syntax something like:
>> 
>>     cnt : INTEGER;
>>     buf : ARRAY [0..cnt - 1] OF Byte;
>> ?
>> 
>> Thanks,
>>  - Jay
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150604/b754bd0b/attachment-0002.html>