Itanium had appeal
|
From: Michael S on 26 Apr 2010 20:17 On Apr 26, 3:38 pm, n...(a)cam.ac.uk wrote: > In article <a0237522-9f61-449b-b72e-bb7c872d2...(a)u31g2000yqb.googlegroups..com>, > > > Instructions (especially in high-performance cores) could be designed > so that they would always complete. No information need be kept for > backing off. Arbitary pre-execution is allowed. > > Things like floating-point fixups would be handled in-thread, by an > extracode-like mechanism. Say, an instruction that tests a code, > and saves registers and calls a stored location if necessary. All > tried and tested stuff. > Or, better, build FPU that never needs a fixups. I think, power and x86 are already mostly here. > I/O interrupts would be handled by an event loop in separate threads, > which would be woken up when there is something to do. And quite > probably having their own cores to do it. SOP on some systems. > > True errors would stop the thread (i.e. NOT be resumable) and pass > control to a supervising thread. Again, tried and tested. > > Machine-check interrupts might be handled by a separate processor > or like I/O ones. But we know that they will always be a problem. > > Time-slice and attention interrupts would be handled by the ability > of a privileged process to insert a suspend instruction at the end > of the current instruction pipeline of another process. The pipeline > would then simply drain, cleanly, and suspend when it had quiesced. Not sure that it would be much simpler than today's [async] interrupts. Even the details of mechanism, you describe, are very similar to one of the possible ways of implementing [async] interrupts except that in case of interrupt suspend instruction is inserted by internal agent rather than external. In both cases there is no need to interrupt any instruction that had started. > > Single stepping debuggers would be handled by the ability to run a > thread in a suitable mode (say, suspending after each instruction, > before every branch or whatever). But NO interruption of any > instruction that had started. > > Any others? > > Note that any hardware lookahead would either be trivially cancellable > or count as being part of the instruction pipeline. > > Regards, > Nick Maclaren. Somehow you forgot to mention [demand] page fault. That's the most common and the most important [synchronous] exception for which you want the ability to restart the instruction.
From: Paul Wallich on 26 Apr 2010 21:13 nmm1(a)cam.ac.uk wrote: > In article <bb5bef64-00c3-46be-8639-28efc338a8f6(a)k41g2000yqf.googlegroups.com>, > Robert Myers <rbmyersusa(a)gmail.com> wrote: >> On Apr 23, 3:06=A0pm, Rick Jones <rick.jon...(a)hp.com> wrote: >>> Anton Ertl <an...(a)mips.complang.tuwien.ac.at> wrote: >>>> A more frequent situation in practice is probably when the compiler >>>> does not know what will happen at run-time; but that's irrelevant, >>>> because it does not happen with SPEC CPU, because that uses profile >>>> feedback. >>> SPECcpu2006 explicitly disallows PBO in base and only allows it in >>> peak. That was a change from SPECcpu2000, which allowed PBO in both. >>> >> That just forces you to design the compiler around the benchmarks. > > An apocryphal story is that one compiler (back in the days when Linpack > ruled) checked for the code being Linpack, and replaced it with some > hand-tuned assembler. The rules were changed to forbid that! That's different from the apocrypha I heard (probably about the same time) that the compiler in question recognized some of the source in the then version of SPEC and did its substitution. This was of course apocryphal, but the story made it clear that the SPEC code in question was idiosyncratic enough that the optimization only applied to it. (There was also the joke about the optimizing compiler that recognized the same values were being computed again and again, and never used for anything once computed...) paul
From: Rick Jones on 26 Apr 2010 21:09 Various SPECcpu benchmark components have been "broken" by compilers over the years. Three that come to my mind would be: * matrix300 but I do not recall which suite that was * art from CPU2000 and one might argue * libquantum from CPU2006 Looking at some of the charts on the results, with the line for libquantum in the middle and sticking out as far as it does, one might think it was giving the "single-fingered salute." rick jones -- the road to hell is paved with business decisions... these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
From: Rick Jones on 26 Apr 2010 21:12 Robert Myers <rbmyersusa(a)gmail.com> wrote: > Genetic programming is only one possible model. > The current programming model is to tell the computer in detail what > to do. > The proposed paradigm is to shift from explicitly telling the > computer what to do to telling the computer what you want and > letting it figure out the details of how to go about it, with > appropriate environmental feedback, which could include human > intervention. Sounds like child rearing. I could handle a computer behaving like my nine year-old, at least most of the time. I'm not sure I want my computer behaving like my five year-old :) rick jones -- the road to hell is paved with business decisions... these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
From: Quadibloc on 26 Apr 2010 21:25
On Apr 26, 1:40 pm, Roger Ivie <ri...(a)ridgenet.net> wrote: > The Bit3 hardware doesn't support byte accesses to the map. There's your problem. The compiler only supports arrays being in main memory; it considers arithmetic statements are there to perform computations, not I/O. You will need to write the relevant code in assembler, and call it from FORTRAN. If you had an IBM 360, the S-type calling sequence for that purpose would be documented in a convenient form. Also, the instruction set of the computer would be one you could actually code in without going insane: Itanium machine language is not meant for human beings to code in. You wouldn't happen to have some way of making this FORTRAN compiler call routines written in C, by any chance? That might work, since C is intended for writing operating systems, not just numerical analysis type programs, so C compilers usually allow you to turn off as much optimization as you may need to turn off. Also, FORTRAN compilers support separate compilation of subroutines. A compiler can't optimize what it doesn't know. John Savard |