What happened to computer architecture (and comp.arch?)
|
Prev: VMWare tools killed my Mac OS X ?
Next: Software vs hardware floating-point [was Re: What happened ...]
From: Robert Myers on 30 Sep 2009 13:13 On Sep 30, 10:22 am, "Andy \"Krazy\" Glew" <ag-n...(a)patten-glew.net> wrote: > > This is the ISA designer's equivalent of "First, do no harm." Some of these conversations really confuse me. In your "hardbound/softbound" thread, it was concluded (I thought) that giving up a factor of two in execution speed was no big deal. How much do you have to give up to present almost any ISA you want by way of a virtual machine? Robert.
From: Terje Mathisen on 30 Sep 2009 14:54 On Sep 30, 7:13 pm, Robert Myers <rbmyers...(a)gmail.com> wrote: > On Sep 30, 10:22 am, "Andy \"Krazy\" Glew" <ag-n...(a)patten-glew.net> > wrote: > > > > > This is the ISA designer's equivalent of "First, do no harm." > > Some of these conversations really confuse me. > > In your "hardbound/softbound" thread, it was concluded (I thought) > that giving up a factor of two in execution speed was no big deal. > > How much do you have to give up to present almost any ISA you want by > way of a virtual machine? Synchronization/locking is one of those things which you really cannot virtualize efficiently without having the support of the supporting real hardware. Java (afaik) tries to solve this by limiting synchronization support to a single, relatively high-level, and quite expensive primitive. Terje
From: Robert Myers on 30 Sep 2009 20:12 On Sep 30, 2:54 pm, Terje Mathisen <terje.wiig.mathi...(a)gmail.com> wrote: > Synchronization/locking is one of those things which you really cannot > virtualize efficiently without having the support of the supporting > real hardware. > > Java (afaik) tries to solve this by limiting synchronization support > to a single, relatively high-level, and quite expensive primitive. Now I'm really confused. All of the supposed advantages of virtualized languages disappear for applications requiring non-trivial concurrency? Robert.
From: Gavin Scott on 30 Sep 2009 21:04 nmm1(a)cam.ac.uk wrote: > But, at the higher levels, (i.e. the program-visible functionality), > we have seen very, very little innovation since the 1980s. Perhaps because that was about the last time that "program visible" stuff was also "programmer visible" in that a typical programmer might be expected to actually look at either assembly code or a machine level debugger. Since then all the action has been in trying to move the programmer's view to ever higher levels of abstraction so that they don't have to think about the small stuff and the details of what's more than one turtle down from their level. Though many of us love to muck around with hand-hacking code at the lowest level we can get to, I don't think there are really many people programming these days who have any interest in thinking about such things, so there's just not much glory to be had in "improving" a machine level ISA any more. It's no longer "cool" the way it once was. G.
From: nmm1 on 1 Oct 2009 03:33
In article <-eSdnZFvEpqonVnXnZ2dnUVZ_rKdnZ2d(a)supernews.com>, Gavin Scott <gavin(a)allegro.com> wrote: > >> But, at the higher levels, (i.e. the program-visible functionality), >> we have seen very, very little innovation since the 1980s. > >Perhaps because that was about the last time that "program visible" >stuff was also "programmer visible" in that a typical programmer might >be expected to actually look at either assembly code or a machine >level debugger. Nope. You are thinking at FAR too low a level! >Since then all the action has been in trying to move the programmer's >view to ever higher levels of abstraction so that they don't have to >think about the small stuff and the details of what's more than one >turtle down from their level. I am talking about architectural differences that would impact on all higher levels - not about minor details, like whether you have an accumulator, register or storage operational model. Think about the capability machines, the Tera MTA, dataflow machines etc. Regards, Nick Maclaren. |