<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
Andrei Alexandrescu wrote:
<blockquote cite="mid:4B6203D9.10008@erdani.com" type="cite">Walter
Bright wrote:
<br>
[snip]
<br>
<blockquote type="cite">I've already made the argument for supporting
64 bit atomics where allowed by the architecture, and the tradeoffs, so
I won't repeat it.
<br>
</blockquote>
<br>
I'm a bit lost. Are you saying that we should allow this:
<br>
<br>
shared int[] a, b;
<br>
...
<br>
a = b[2 .. 3];
<br>
<br>
on some machines but not others?</blockquote>
<br>
Yes.<br>
<br>
<blockquote cite="mid:4B6203D9.10008@erdani.com" type="cite"> How is
then anyone expected to write reasonably portable code?
<br>
</blockquote>
<br>
How do you propose one write such code portably on a 32 bit machine?<br>
<br>
<blockquote cite="mid:4B6203D9.10008@erdani.com" type="cite"><br>
One great thing about Linux distros is that you are able to compile
code on your machine. You get the source code, you run configure, you
run make, you run make install, and you're good to go. How would it be
to see messages like "On this machine this entire feature and
consequently design doesn't work"?
<br>
</blockquote>
<br>
This is deja vu all over again <g>. I remember the 16 <=>
32 bit transition. Lots of people tried to take 32 bit code and make it
work on 16 bit machines. While C is presumably portable, in practice
you had to <i>redesign</i> the code to make it work well on 16 bit
machines, not just mess around with a few details. I can't remember one
port from 32 to 16 bits that was a significant success on 16 bit
machines compared with ones that were <i>designed</i> for 16 bits from
the ground up.<br>
<br>
One example was Stroustrup's cfront. It reigned supreme on 32 bit
machines in the 80's. It was ported to 16 bits and sold (Glockenspiel
C++). It got its butt kicked on 16 bit machines by every C++ compiler
that was designed for 16 bits.<br>
<br>
On the other hand, major apps in the 16 bit world were able to migrate
to 32 bits without too much difficulty, though they still benefited
from a redesign.<br>
<br>
All the C apps you see that you can make for 32 or 64 bits in Linux
have already been ported, tested, and verified to work. I've never seen
any non-trivial C application built for 32 bits that survived
unmodified when compiled for 64. Not one. Not even mine, and I'm
experienced at doing such ports.<br>
<br>
I suspect that we'll see that (for C, C++ and D) apps developed
natively for 64 bits will not port very well to 32 bits for many
reasons. Remember when we talked about the large address space on 64
bits meaning that different algorithmic strategies can be used (even if
there isn't more physical memory)? How about on 64 bits we can at last
get rid of thread stack size problems? Won't that change the strategic
tradeoffs one applies when multithreading?<br>
<br>
64 bit machines are going to support multithreading better than 32 bit
ones. I don't see that as a reason to deliberately cripple those
advantages.<br>
<br>
Back to your question:<br>
<blockquote type="cite">Are you saying that we should allow this:
<br>
<br>
shared int[] a, b;
<br>
...
<br>
a = b[2 .. 3];
<br>
<br>
on some machines but not others?</blockquote>
<br>
Consider the analogy:<br>
<br>
<tt>char *p = new char[100000];</tt><br>
<br>
which works fine on 32 bits, but doesn't on 16 bits. Yes, there were
LOTS of attempts to transparently make this work in 16 bit languages.
Every one of them worked on paper (so-called "huge" pointers), but were
unacceptably slow in practice. Having the compiler kludge it to make it
appear to work was not acceptable, and neither was disabling such code
in 32 bit compilers.<br>
<br>
Should we disable reading 8 Gb files using memory mapped I/O in 64 bit
D because the same code will not work in 32 bits? Or do we accept that
yes, the programmer will have to use a different strategy to read 8 Gb
files in 32 bit code?<br>
<br>
<blockquote cite="mid:4B6203D9.10008@erdani.com" type="cite"><br>
I agree with disabling some feature on an odd machine, but not with
conditioning entire areas of the language on the machine they work on.
What is this, assembly language?
<br>
</blockquote>
<br>
If we disable 64 bit atomic support on 64 bit machines, all we will be
doing is leaving a wide open door for other languages without such
compunctions. We will not be benefiting 64 bit D programmers.<br>
<br>
<br>
</body>
</html>