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

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

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