Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!news.iecc.com!.POSTED!nerds-end From: glen herrmannsfeldt Newsgroups: comp.compilers Subject: Re: Implementation dependent behaviour (WAS: Re: Programming language and IDE design) Date: Sun, 24 Nov 2013 21:51:07 +0000 (UTC) Organization: Aioe.org NNTP Server Lines: 43 Sender: johnl@iecc.com Approved: comp.compilers@iecc.com Message-ID: <13-11-030@comp.compilers> References: <13-11-025@comp.compilers> <13-11-028@comp.compilers> NNTP-Posting-Host: news.iecc.com X-Trace: leila.iecc.com 1385568860 4719 64.57.183.58 (27 Nov 2013 16:14:20 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Wed, 27 Nov 2013 16:14:20 +0000 (UTC) Keywords: optimize, design Posted-Date: 27 Nov 2013 11:14:20 EST X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:1054 Joshua Cranmer ? 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