From: Robert Myers on
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
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
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
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
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.