Itanium had appeal
|
From: MitchAlsup on 27 Apr 2010 00:21 On Apr 26, 8:25 pm, Quadibloc <jsav...(a)ecn.ab.ca> wrote: > Also, FORTRAN compilers support separate compilation of subroutines. A > compiler can't optimize what it doesn't know. I have worked with several systems in the past that did not generate machine (linkable) machine code until the reentrant library got loaded. In these cases, the library finsihed compilation as it was being loaded and linkages formed. The intent was to automagically inline the codes that fit the inlining model. Mitch
From: nmm1 on 27 Apr 2010 03:27 In article <fab2929e-a53c-48a6-9bde-8ec2313d2829(a)i40g2000yqd.googlegroups.com>, MitchAlsup <MitchAlsup(a)aol.com> wrote: >On Apr 26, 12:22=A0pm, Robert Myers <rbmyers...(a)gmail.com> wrote: >> >> One of these days, we'll recognize a Turing machine as an interesting >> first step, but ultimately a dead end. =A0Along with it, we'll >> eventually grasp that the entire notion of "programming" is a very >> limiting concept. =A0Eventually, the idea of a "programmer", as we now >> conceive it, will seem preposterously dated and strange. > >I, personally, blame the vonNeumann programming model. But it is so >intemately intertwined with the Turing Machine fundamentals that >little distinction is bought by making such a distinction. > >But person of blame apart, I entirely agree with you. Well, actually, I blame the second-raters who turned some seminal results into dogma. None of Turing, Von Neumann or the best mathematicians and computer people would ever say that the model is the last word, still less that hardware architecture and programming languages must be forced into it. A model I sometimes use is strictly more powerful than the Turing/ Von Neumann one - and predates both of those two people - but it doesn't seem to help a lot with this issue. Basically, include a true random number generator and permit termination in probability. The God-awful trick that computer scientists call non-determinism isn't the same at all, and has diverted a lot of attention down a blind alley. Regards, Nick Maclaren.
From: nmm1 on 27 Apr 2010 03:36 In article <3e63d742-6909-4170-811f-a648227bd6d5(a)h27g2000yqm.googlegroups.com>, Michael S <already5chosen(a)yahoo.com> wrote: > >Or, better, build FPU that never needs a fixups. I think, power and >x86 are already mostly here. That was just an example - my comment referred to ANY form of instruction emulation. >> 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. =A0The 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. I never said that it was a new invention. However, while what you say is certainly possible in theory, I don't know of any architecture that supports it. Oh, yes, some computers may do it - but I am talking about an architected design. And that's where you get the simplification. No fiendishly complicated FLIH, horrible and inadequate run-time system support, and so on. >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. Oh, yes, thanks. Simply abolish demand paging - that was an important technique in the 1970s, but is a disaster in all sorts of respects. Once a system starts paging, bye, bye any hope of performance. And using it to implement sparse address spaces is a dirty trick that can be done far better in other ways. Replace it by application-controlled segment (Unix, not x86) swapping. Regards, Nick Maclaren.
From: Michael S on 27 Apr 2010 04:38 On Apr 27, 9:36 am, n...(a)cam.ac.uk wrote: > In article <3e63d742-6909-4170-811f-a648227bd...(a)h27g2000yqm.googlegroups..com>, > Michael S <already5cho...(a)yahoo.com> wrote: > > > > >Or, better, build FPU that never needs a fixups. I think, power and > >x86 are already mostly here. > > That was just an example - my comment referred to ANY form of > instruction emulation. > > >> 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. =A0The 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. > > I never said that it was a new invention. However, while what you > say is certainly possible in theory, I don't know of any architecture > that supports it. Oh, yes, some computers may do it - but I am talking > about an architected design. > > And that's where you get the simplification. No fiendishly complicated > FLIH, horrible and inadequate run-time system support, and so on. > I think, you are wrong. This behavior for [async] interrupts (i.e. all instructions before return address are fully completed; all instructions at and above return address are not started) is architected on all current ISAs that could be considered general-purpose. > >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. > > Oh, yes, thanks. Simply abolish demand paging - that was an important > technique in the 1970s, but is a disaster in all sorts of respects. > Once a system starts paging, bye, bye any hope of performance. And > using it to implement sparse address spaces is a dirty trick that > can be done far better in other ways. > > Replace it by application-controlled segment (Unix, not x86) swapping. > > Regards, > Nick Maclaren. I, at least, am not aware about better ways of for OS-level fragmentation-free memory allocation. Esp, when upfront the app is not sure about the real size of continuous buffer that it allocates and there is a big difference between max size and typical size. It (demand paging) also works very well for application stack(s).
From: Piotr Wyderski on 27 Apr 2010 04:47
Andy "Krazy" Glew wrote: > Oracle with Sun. The UltraSparc family in all our tests proves to be by far the slowest architecture still in operation, so what kind of innovation do you expect from Sun? Best regards Piotr Wyderski |