On Friday, 17 October 2014 at 13:44:24 UTC, ketmar via
Digitalmars-d wrote:
On Fri, 17 Oct 2014 09:46:48 +0000
via Digitalmars-d <[email protected]> wrote:
It is just plain wrong to let integers wrap by default in an
accessible result. That is not integer behaviour.
do you know any widespread hardware with doesn't work this way?
Yes, the carry flag is set if you add with carry. It means you
SHOULD add to another hi-word with carry. :P
You can also add with clamp with SSE, so you clamp to max/min.
Too bad languages don't support it. I've always thought it be
nice to have clamp operators, so you can say x(+)y and have the
result clamped to the max/min values. Useful for stuff like DSP
on integers.
if (x < ((x+1)&0xffffffff)){…}
perfect. nice and straightforward way to do overflow checks.
Uh, so you want slow? If you want this you should also check the
overflow flag so that you can catch overflows and throw an
exception.
But then you have a high level language. All high level languages
should do this.
In D it is even worse since you are forced to use a fixed size
modulo even for int, so you cannot do 32 bit arithmetic in a
64 bit register without getting extra modulo operations.
why should i, as programmer, care? what i *really* care about is
portable code. having size of base types not strictly defined
is not
helping at all.
So you want to have lots of masking on your shiny new 64-bit
register only CPU, because D is stuck on promoting to 32-bits by
spec?
That's not portable, that is "portable".
So, "undefined behaviour" is not so bad
yes, it's not bad, it's terrible. having "undefined behavior" in
language is like saying "hey, we don't know what to do with
this, and
Nah, it is saying: if your code is wrong then you will get wrong
results unless you turn on runtime checks.
What D is saying is: nothing is wrong even if you get something
you never wanted to express, because we specify all operations to
be boundless (circular) so that nothing can be wrong by
definition (but your code will still crash and burn).
That also means that you cannot turn on runtime checks, since it
is by definition valid. No way for the compiler to figure out if
it is intentional or not.
D has locked itself to Pentium-style x86 behaviour.
oops. 2's complement integer arithmetic is "pentium-style x86"
now... i
bet x86_64 does everything in ternary, right? oh, and how about
pre-pentium era?
The overhead for doing 64bit calculations is marginal. Locking
yourself to 32bit is a bad idea.
it is very easy. take current hardware, evaluate it's
popularity, do
what most popular hardware does. that's it. i, for myself,
don't need
a language for "future hardware", i need to work with what i
have now.
My first computer had no division or multiply and 8 bit registers
and was insanely popular. It was inconceivable that I would
afford anything more advanced in the next decade. In the next 5
years I had two 16 bit computers, one with 16x RAM and GPU… and
at a much lower price…
if we'll have some drastic changes in the future... well, we
always can
emulate old HW to work with old code, and rewrite that old code
for new
HW.
The most work on a codebase is done after it ships.
Interesting things may happen on the hardware side in the next
few years:
- You'll find info on the net where Intel has planned buffered
transactional memory for around 2017.
- AMD is interested in CPU/GPU intergration/convergence
- Intel has a many core "co-processor"
- SIMD registers are getting wider and wider… 512 bits is a lot!
etc...
