Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.compilers > #1049

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

Show all headers | View raw

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]

Back to comp.compilers | Previous | Next — Next in thread | Find similar | Unroll thread

Thread

Implementation dependent behaviour (WAS: Re: Programming language and IDE design) Martin Ward <martin@gkc.org.uk> - 2013-11-20 10:29 +0000
  Re: Implementation dependent behaviour (WAS: Re: Programming language and IDE design) Joshua Cranmer 🐧 <Pidgeot18@verizon.net> - 2013-11-23 01:06 -0600
    Re: Implementation dependent behaviour (WAS: Re: Programming language and IDE design) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-11-24 21:51 +0000
    Re: Implementation dependent behaviour (WAS: Re: Programming language and IDE design) Martin Ward <martin@gkc.org.uk> - 2014-01-06 19:23 +0000
  Re: Implementation dependent behaviour (WAS: Re: Programming language and IDE design) Kaz Kylheku <kaz@kylheku.com> - 2013-12-17 23:07 +0000
    Re: Implementation dependent behaviour (WAS: Re: Programming language and IDE design) Martin Ward <martin@gkc.org.uk> - 2014-01-06 19:32 +0000
  Re: Implementation dependent behaviour (WAS: Re: Programming language and IDE design) Ivan Godard <ivan@ootbcomp.com> - 2014-01-08 09:02 -0800
    Re: Implementation dependent behaviour (WAS: Re: Programming language and IDE design) Kaz Kylheku <kaz@kylheku.com> - 2014-01-08 18:21 +0000
      Re: Implementation dependent behaviour (WAS: Re: Programming language and IDE design) Ivan Godard <ivan@ootbcomp.com> - 2014-01-10 09:11 -0800
      Re: Implementation dependent behaviour (WAS: Re: Programming language and IDE design) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-01-10 23:08 +0000
        Re: Implementation dependent behaviour (WAS: Re: Programming language and IDE design) Ivan Godard <ivan@ootbcomp.com> - 2014-01-13 12:47 -0800
        Re: Implementation dependent behaviour (WAS: Re: Programming language and IDE design) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-14 14:16 +0000

csiph-web