Implementation dependent behaviour (WAS: Re: Programming language and IDE design)

On Tuesday 19 Nov 2013 at 00:02, George Neuner <gneuner2@comcast.net> wrote:
> I simply said that your assertion:
>
> (2) Absolutely no behaviour should be "implementation dependent"
> or "undefined". Every syntactically valid program should have
> a single semantically valid meaning (even if that meaning
> is "halt with an error message").
>
> is not plausible. I did not offer an alternative.


Your only counter-example is "execution time": but programming
language specification documents have never included execution time as
part of the specification of a language (whether defined as
"implementation dependent" or otherwise). Execution time is not part
of the specification of the language. Neither have they specified the
power consumption or temperature of the CPU: although these properties
can be just as important as execution time for certain applications!
They are also not considered to be part of the definition of the
language.


Apart from these cases: do you still disagree with the assertion?
Is there any (semantic) behaviour which should be left as
"implementation dependent"?


The usual reason for "implementation dependent" behaviour is that code
compiles to one behaviour more efficiently one one CPU, and to some
other behaviour more efficiently on some other CPU. So, rather than
"penalise" one CPU, the language designers give way to lobbying from
the CPU manufacturers and allow either behaviour (or any behaviour).
The result:


(1) If you want to be sure of the behaviour of your program,
you have to avoid the "implementation dependent" features:
so now your program executes inefficiently on *all* CPUs; OR


(2) If you happen to know that your program will run on a certain CPU,
and efficiency is important to you, then you may just go ahead
and rely on the actual behaviour of your program when it is technically
"undefined". (Unless you are a language semantics expert who
spends your spare time reading language specification documents,
you may well be doing this already without realising it!)
Now, your program is not portable: it may break as soon as you move
it to another CPU. Even worse: it may break with the next update
of the compiler! The compiler writers have no compulsion
to preserve the old behaviour when the language definition states
that it is "undefined".


On the other hand: suppose the language designers pick on a certain
behaviour and define *that* as the exact semantics of the programming
construct in question. The result:


(1) Compilers for CPUs on which the selected choice is the "native" behaviour
can generate more efficient code. Compilers for other CPUs may have
to generate extra code to implement this feature. So certain programs
will run faster on some CPUs than on others. But the programs
will at least produce identical outputs on *all* CPUs.
(Note: if you don't care what output your program produces,
as long as it produces it quickly: well, incorrect output can be generated
in no time at all!)


(2) CPU designers may choose to implement that behaviour in hardware
on the next iteration of the CPU. Now the programs run fast on *all* CPUs.


Everybody wins.


--
Martin


Dr Martin Ward STRL Principal Lecturer and Reader in Software Engineering
martin@gkc.org.uk http://www.cse.dmu.ac.uk/~mward/ Erdos number: 4
G.K.Chesterton web site: http://www.cse.dmu.ac.uk/~mward/gkc/
Mirrors: http://www.gkc.org.uk and http://www.gkc.org.uk/gkc
[In my experience, if you overspecify the semantics of a language, you end up
simulating the warts of whatever CPU happened to be familiar to the language's
designer on every other CPU. You also lose most optimizations if you try to
specify the contents of storage as seen from a routine that handles arithmetic
exceptions. -John]

Return to the comp.compilers page.
Search the comp.compilers archives again.