[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[oc] Re: Merlin Hybrid System
On Sun, Dec 09, 2001 at 04:42:09PM -0600, Jim Dempsey wrote:
>
> ----- 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.
Doesn't matter. x86 code isn't actually "run" anyway without
conversion.
> 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).
Sure, you can do many things, but you can't do any _correct_ things with
interrupts without fully halting user mode at an instruction boundary.
Not unless the software supports it and then it isn't standard x86
anymore.
There are simpler optimizations to make code run faster, like reordering
and combining reads and writes to non-cacheable areas (I/O space). x86
doesn't, code relies on that, so you can't simply implement that however
much you think it would increase performance.
> 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.
These FPUs were however synchronized explicitly whenever the operating
system wanted to switch context, i.e. software knows and supports that.
The integer part is expected to be frozen. In order to let OS code work
correctly this assumption has to be supported. Which in turn means that
you have to synchronize the strands before they can even diverge.
What happens at an interrupt is that the exception frame with the
address of the interrupted instruction gets pushed on the stack.
Registers stay (unless you have different register banks, which the x86
has not). The interrupt handler pushes all registers on stack. If the
user mode would still run, saved values (address, register contents)
would not match changing reality.
How would you synchronize that, what would happen when the interrupt
handler wants to restore user context? Hunt down the values in memory
and change them? Where would you find them?
--
Andreas Bombe <bombe@informatik.tu-muenchen.de> DSA key 0x04880A44
--
To unsubscribe from cores mailing list please visit http://www.opencores.org/mailinglists.shtml