Re: [oc] Re: Merlin Hybrid System

["Jim Dempsey" <dempsey@northnet.net>]

----- Original Message -----
From: "Andreas Bombe" <bombe@informatik.tu-muenchen.de>
To: <cores@opencores.org>
Sent: Saturday, December 08, 2001 7:27 PM
Subject: [oc] Re: Merlin Hybrid System


> > This is not unlike an experienced parallelizing programmer taking
> > someone's code that they know nothing of and parallizing it. If a
> > programmer can do it a program can do it.
>
> Really?  Last time I checked we didn't have AIs yet.  If a program can
> do it, why do companies still employ programmers?
>

Because, to date, for the small number of applications to be converted
onto a small number of specialty platforms it has not been cost effective
to do so.

> > The simplest of the examples I can use for illustration is at the point
of
> > seperation
> > of a single execuition stream into a multiple execution stream. Assume
the
> > instruction
> > sequence
> >
> >     bla
> >     bla
> >     bla
> >     blink
> >     bla
> >     bla
> >     bla
> >
> > Assume at point blink an interrupt occures.
> >
> >     bla
> >     bla
> >     bla
> >     blink------------->
> >             blankity
> >             blankity
> >             blank
> >     <----------------
> >     bla
> >     bla
> >     bla
> >
> >  Depending on the circumstances of the interrupt one processing
> > "strand" could continue execuition of the bla's during the interrupt.
> > The process I've developed would permit this to occure to some
> > degree.
>
> So, what return address is saved in the exception frame created on the
> stack?  What are the contents of the registers upon entry of the
> interrupt handler?  What happens when a scheduler runs in the interrupt
> and replaces the return address in the frame?
>
> What happens to code that rightfully expects no user mode code running
> while in interrupt mode?
>

Well that is part of the "secret recipe". The prior diagram illustrates the
traditional approach. When the code is virtual it doesn't actualy run.
The x86 code converted to run in (on) a different processor. Because
of this your are able to do things that are not expected in the higher
level code (x86). The process which I am reluctant to disclose too
much about exploites this to the extent that there is a seperation
between where the outside perception of where the execution is
(what the observer sees) and where the actual execution is.

If you are familiar with the older FPU chips you will get some hint
of the idea. To a person scoping the instruction fetches of the x86
processor they would observe the instruction pointer not following
the true path of execution. If for a simple example an interrupt
occures immediately after the start of an FDIV instruction that
for simple interrupt processes that the FDIV would continue
to execute asynchronously. In a virtual environment the scope
of this can be extended to the x86 instructions and extended
a much further distance.

Jim Dempsey




--
To unsubscribe from cores mailing list please visit http://www.opencores.org/mailinglists.shtml