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

Groups > comp.compilers > #1054

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

Show key headers only | View raw

Joshua Cranmer ? <Pidgeot18@verizon.net> wrote:

(snip, someone wrote)

>> 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:

> Or, you can get extremely inefficient computation on all CPUs. Suppose
> you had a language that required you to trap on arithmetic overflows,
> and that required you to trap at a very specific place in computation.

In some cases, the hardware is designed to satisfy language
requirements.

> This language means you have to prove range analysis on all variables to
> prove that they cannot overflow before you can do any code motion or
> code elimination--effectively negating the most powerful optimizations a
> compiler can do.

I believe that this is at least slightly true for Java. The exception
model restricts some code movements that other compilers might do.

> If you allow a little bit of undefined behavior, if you let compilers
> choose to trap before the value would be observed as overflowed, you
> again allow code elimination and code motion without the range analysis,
> while achieving very nearly the same result.

I suppose you missed the days of imprecise interrupts. The IBM 360/91
does out of order processing, including out of order retire. In the case
of an exception, it has to complete processing of all instructions in
the pipeline, at least those logically before the last retired
instruction.

Even more, there is "multiple imprecise interrupt" when more exceptions
occur while flushing the pipeline. In most cases you don't have the
address of the exception.  But in many cases, people would rather
have the speed.

Most imprecise interrupts went away with virtual storage, as you need to
at least do things right in the case of a page fault.

-- glen

Back to comp.compilers | Previous | Next — Previous in thread | 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