<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>Do you want 64bit targets to be "better" or "the same"?<div>What if I say the Modula-3 equivalent of, three programs:</div><div> 1 printf("%d", (int)sizeof(void*)); <br><div> 2 <span style="font-size: 12pt; ">printf("%d", (int)sizeof(size_t));</span></div><div><span style="font-size: 12pt; "> 3 </span><span style="font-size: 12pt; ">printf("%d", (int)sizeof(int)); </span></div><div><span style="font-size: 12pt; "><br></span></div><div><span style="font-size: 12pt; ">One could argue in your favor here.</span></div><div><span style="font-size: 12pt; ">The user of void* and size_t is expecting "better".</span></div><div><span style="font-size: 12pt; ">The user of int is expecting "same".</span></div><div><span style="font-size: 12pt; "><br></span></div><div><span style="font-size: 12pt; ">Modula-3 could have two integer types, builtin, short names.</span></div><div><span style="font-size: 12pt; ">Or, today, it offers all 4 sizes, you just have to go slightly out of your way.</span></div><div><span style="font-size: 12pt; "><br></span></div><div><span style="font-size: 12pt; ">You can say:</span></div><div><span style="font-size: 12pt; "> TYPE int = Ctypes.int; or maybe BasicCtypes.int.</span></div><div><span style="font-size: 12pt; "><br></span></div><div><span style="font-size: 12pt; ">and go about your business using int instead of INTEGER and</span></div><div><span style="font-size: 12pt; ">get the compability you desire.</span></div><div><span style="font-size: 12pt; "><br></span></div><div><span style="font-size: 12pt; ">Perhaps this should be:</span></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><div><span style="font-size: 12pt; "> int = IntegerTypes.INT32?</span></div></div></blockquote><div><div><span style="font-size: 12pt; "><br></span></div><div>to not be be C-related?</div><div><br></div><div> - Jay<br><br><br><br><div><hr id="stopSpelling">Date: Thu, 4 Jun 2015 16:01:37 +0200<br>From: estellnb@elstel.org<br>To: jay.krell@cornell.edu; m3devel@elegosoft.com<br>Subject: Re: [M3devel] 32bit host 64bit target TextLiteral recurring problem<br><br>
<div class="ecxmoz-cite-prefix">Am 03.06.15 um 03:58 schrieb Jay K:<br>
</div>
<blockquote cite="mid:COL130-W544332BBFD51516DEA73F5E6B40@phx.gbl">
<style><!--
.ExternalClass .ecxhmmessage P {
padding:0px;
}
.ExternalClass body.ecxhmmessage {
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">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></div></div></div> </div></body>
</html>