[M3devel] 32bit host 64bit target TextLiteral recurring problem
Jay K
jay.krell at cornell.edu
Thu Jun 4 01:14:49 CEST 2015
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.i3index 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/20150603/457859bb/attachment-0002.html>
More information about the M3devel
mailing list