<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Am 03.06.15 um 03:58 schrieb Jay K:<br>
</div>
<blockquote cite="mid:COL130-W544332BBFD51516DEA73F5E6B40@phx.gbl"
type="cite">
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style>
<div dir="ltr">
<div>We cannot cross from 32bit host to 64bit target.</div>
<div><br>
</div>
<div><br>
</div>
<div>Ok to commit this?</div>
<div><br>
</div>
<br>
</div>
</blockquote>
<br>
Compatibility between the 32bit and the 64bit version of the same
program would be the minimum I expected from a pickle.<br>
To me this is just another argument for a language specified value
range of INTEGER.<br>
It makes certain things easier. <br>
<br>
My suggestion was:<br>
TYPE OFFSET = BITS BITSIZE(ADDRESS) FOR INTEGER; (and INTEGER = BITS
32 FOR INTEGER for 32 and 64bit targets)<br>
while also allowing BITS 16 FOR INTEGER (if that works for WIDECHAR
I believe there is no reason to forbid it for INTEGER)<br>
BITS 64 FOR INTEGER would only work on x64 systems.<br>
<br>
The value range - bitsize correlation problem could be solved easily
by automatically extending and reducing the value <br>
range of an integer type to what its binary representation allows as
long as no explicit range has ever been specified for <br>
any of its supertypes (i.e. BITS 16 FOR INTEGER = BITS 16 FOR
[-32768..+32767]).<br>
<br>
Finally it needs to be said that the argument that target size
arithmetics is always the fastest which was often used in <br>
here can be very wrong. It does not hold for the 64bit systems of
today because the CPU is no more the bottleneck. In<br>
a fact now the memory hierarchy has become the new bottleneck (which
means that using more memory for the same <br>
tends to be much slower).<br>
<br>
Regards,<br>
Elmar<br>
<br>
<blockquote cite="mid:556F5594.7070701@lcwb.coop" type="cite">Can't
do this. Non-open arrays must have static constant bounds, <br>
which the above does not. Open arrays have extra dope and are
accessed <br>
through two extra pointers, which we really wouldn't want for text
literals. <br>
<br>
TextLiteral.Ts are unsafe only in UNSAFE code, which is no worse
that anything <br>
else in UNSAFE code. The interface is UNSAFE, which means safe
code can't IMPORT <br>
it, and thus can't see the declaration. Not very likely that
anybody other than <br>
the runtime, compiler-generated code, and debugger (written in C
anyway) would <br>
want to mess with it. <br>
<br>
</blockquote>
<br>
</body>
</html>