<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
This is a great comment. Let me start by saying that if you're looking
for <i>any</i> rule about the design of D applied 100% consistency,
you won't find one. It's an illustration of D not being a religion. D's
rules of design are not orthogonal, and they often conflict with each
other. We have to pick when and where to use the rules based on our
best judgment of the individual circumstances.<br>
<br>
Examples of the error of the primacy of absolute rules are the "3
strikes laws" where people have been sent to prison for life for
stealing a handbag; "zero tolerance" rules in schools where kids have
been suspended for bringing in 1" long plastic toy guns, etc. Car
makers often say that safety trumps all else, but if they really
followed that principle then cars couldn't move an inch.<br>
<br>
Addressing the other design choices in D vs C: a lot of the <i>implementation-defined
</i>aspects of C are to support CPU designs that were obsolete in the
1970's. Like ones-complement arithmetic. My best guess is that
ones-complement arithmetic is dead and not coming back. The same with 9
bit bytes, non-IEEE floating point, etc. Other implementation-defined
aspects are efficiency related, such as signed-ness of chars, and order
of evaluation. These no longer make any significant difference, and so
can be eliminated. 4, 8 and 16 bit processors are dead, dead, dead, and
so language support for them is not justifiable.<br>
<br>
For decades I've seen people read the portability guidelines for C, and
attempt to make their source code portable to 9 bit bytes, non-IEEE
floats, even varying int sizes. They get it wrong essentially <i>every
single time</i>. The only way to make C code portable from one
architecture to another is to actually develop for both architectures,
not read a book about them. The C language is of no help, as it won't
diagnose portability issues (and cannot).<br>
<br>
With D, there is a significant effort to improve actual portability
(rather than C's theoretical portability) by nailing down some abstract
CPU characteristics as being required by the language. This is based on
what CPUs in use are like and what we expect future designs to be like.
(Of course, we could guess wrong about the future, and hopefully D will
be able to adapt.)<br>
<br>
Does this mean that D code can never work on a non-IEEE machine? That's
right in an absolutist way, but quite wrong in a practical way. There
is nothing preventing a custom <i>variant</i> of D for that platform.
The only practical difference between C and D for such machines is D
won't provide (as C does) the <i>fiction</i> of code being portable to
it.<br>
<br>
But there are a couple ways that current CPU designs vary, and we
expect them to vary. The first is, of course, the transition to 64
bits. We expect that when running on a 64 bit machine we can have
arrays larger than 32 bits. We expect that such won't work on a 32 bit
machine. There is some inherent non-portability between 32 and 64 bit D
programs. I don't think that cripples D or sends the wrong message in
any way. I do think, however, that D should eliminate <i>gratuitous</i>
incompatibility between them. For example, a gratuitous incompatibility
would be to say that ints are 32 bits on 32 bit machines and 64 on 64.
Seeing all the agony this causes in C source code, I don't believe it
is worthwhile.<br>
<br>
In contrast, supporting longs as 64 bits even on 32 bit machines is at
only a very small cost, and so is worthwhile.<br>
<br>
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>
<br>
Andrei Alexandrescu wrote:
<blockquote cite="mid:4B61EC7F.3000606@erdani.com" type="cite">I don't
understand. This view is in stark contrast with everything D has been
so far, and also embodies everything you told me many times you dislike
about C.
<br>
<br>
For one thing there's no precedent of what you say in D. Data types
from char to long and also float and double are guaranteed to be in the
language. If a processor does not support IEEE754, you insert routines
do to things for you. Same with 64-bit integers, vector operations, and
probably in a number of other places. But the point is that you do
offer a platform for writing portable programs, not a balkanized
federation of sublanguages. Why the sudden change?
<br>
<br>
I'm ok with leaving real assignment atomicity to the compiler, but I
think attempting to take that any further will kill babies.
<br>
<br>
<br>
Andrei
<br>
<br>
Walter Bright wrote:
<br>
<blockquote type="cite"><br>
<br>
Andrei Alexandrescu wrote:
<br>
<blockquote type="cite">It's a slippery slope. If we leave real's
compilation to the installation, we should also allow atomic shared
array assignment for machines that support 128-bit atomic assign. I
just don't think this is a tenable approach to designing a language.
<br>
<br>
</blockquote>
<br>
I don't think the message D should send is: "Yes, I know you're using a
machine that can do atomic 128 bits, but because some machines you
don't have and don't care about don't, you have to go the long way
around the block and use a clumsy, awkward, inefficient workaround."
<br>
<br>
The choices are:
<br>
<br>
1. allow atomic access for basic types where the CPU supports it, issue
error when it does not. The compiler makes it clear where the
programmer needs to pay attention on machines that need it, and so the
programmer can select whether to use a (slow) mutex or to redesign the
algorithm.
<br>
<br>
2. allow atomic access only for basic types supported by the lowest
common denominator CPU. This requires the user to use workarounds even
on machines that support native operations. It's like the old days
where programmers were forced to suffer with emulated floating point
even if they'd spent the $$$ for a floating point coprocessor.
<br>
<br>
3. allow atomic access for all basic types, emit mutexes for those
types where the CPU does not allow atomic access. Keep in mind that
mutexes can make access 100 times slower or more. Bartosz suggested to
me that silently inserting such mutexes is a bad idea because the
programmer would likely prefer to redesign the code than accept such a
tremendous slowdown, except that the compiler hides such and makes it
hard for him to find.
<br>
<br>
<br>
As I've said before, I prefer (1) because D is a systems programming
language. It's mission is not the Java "compile once, run everywhere."
D should cater to the people who want to get the most out of their
machines, not the least. For example, someone writing a device driver
/needs/ to get all the performance possible. Having some operations be
100x slower just because of portability is not acceptable.
<br>
<br>
<br>
------------------------------------------------------------------------
<br>
<br>
_______________________________________________
<br>
dmd-concurrency mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:dmd-concurrency@puremagic.com">dmd-concurrency@puremagic.com</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.puremagic.com/mailman/listinfo/dmd-concurrency">http://lists.puremagic.com/mailman/listinfo/dmd-concurrency</a>
<br>
</blockquote>
_______________________________________________
<br>
dmd-concurrency mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:dmd-concurrency@puremagic.com">dmd-concurrency@puremagic.com</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.puremagic.com/mailman/listinfo/dmd-concurrency">http://lists.puremagic.com/mailman/listinfo/dmd-concurrency</a>
<br>
<br>
<br>
</blockquote>
</body>
</html>