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

[Elmar Stellnberger]

Am 03.06.15 um 03:58 schrieb Jay K:
> We cannot cross from 32bit host to 64bit target.
>
>
> Ok to commit this?
>
>

Compatibility between the 32bit and the 64bit version of the same 
program would be the minimum I expected from a pickle.
To me this is just another argument for a language specified value range 
of INTEGER.
It makes certain things easier.

My suggestion was:
TYPE OFFSET = BITS BITSIZE(ADDRESS) FOR INTEGER; (and INTEGER = BITS 32 
FOR INTEGER for 32 and 64bit targets)
while also allowing BITS 16 FOR INTEGER (if that works for WIDECHAR I 
believe there is no reason to forbid it for INTEGER)
BITS 64 FOR INTEGER would only work on x64 systems.

The value range - bitsize correlation problem could be solved easily by 
automatically extending and reducing the value
range of an integer type to what its binary representation allows as 
long as no explicit range has ever been specified for
any of its supertypes (i.e. BITS 16 FOR INTEGER = BITS 16 FOR 
[-32768..+32767]).

Finally it needs to be said that the argument that target size 
arithmetics is always the fastest which was often used in
here can be very wrong. It does not hold for the 64bit systems of today 
because the CPU is no more the bottleneck. In
a fact now the memory hierarchy has become the new bottleneck (which 
means that using more memory for the same
tends to be much slower).

Regards,
Elmar

> Can't do this.  Non-open arrays must have static constant bounds,
> which the above does not.  Open arrays have extra dope and are accessed
> through two extra pointers, which we really wouldn't want for text 
> literals.
>
> TextLiteral.Ts are unsafe only in UNSAFE code, which is no worse that 
> anything
> else in UNSAFE code.  The interface is UNSAFE, which means safe code 
> can't IMPORT
> it, and thus can't see the declaration.  Not very likely that anybody 
> other than
> the runtime, compiler-generated code, and debugger (written in C 
> anyway) would
> want to mess with it.
>

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