Re: [oc] Thanks For Your Support Of Merlin

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

> 
> Since this is Open Cores, why don't you make your own CPU and just 
> arrange to license their patents under some reasonable terms? They 
> might actually find this idea more acceptable.
> 
Two problems with this.
1) Posting quiries to them results in no feedback. (Black Hole?)
2) Why re-do all the coding that has been done and tested with
    the current Crusoe product.

It would be a much better starting position to begin with where
the Transmeta processors are now.

I think part of the confusion is that whomever is reading (discarding)
my email is under the assumption that I am suggesting an SMP capable
processor chip. This is not the case. Although this design can be used
in an SMP system too.

The initial first part produced would be a chip that is pin compatible
and externaly equivilent to a socket 7 processor (e.g. Intel Celeron).
Inside this would be (whatever fits) perhaps 4 strand execution
processors. One/some of which can do the Code Morphing and
strandification and the others execuiting the strand code. Perhaps
you would observe a 4x or more improvement. (Because one
processor isn't doing both morphing and execution of morphed
code.)

MOVE looks interesting although the concept I am proposing is
neither TTA nor OTA. MOVE works at a finer granularity than
what strands do.

An author of a program, where the program audience is running
a single processor system, will not put much effort into breaking
the program into multiple threads.They might consider doing
disk (buffer) I/O as a seperate thread but not much else. i.e.
recover some application time while waiting for writes or pre-read
in preperation for next read from application. Not much else
will be addressed by this programmer.

Much of the reason for this is that on a single processor system
and more so a single processor O/S only one thread executes at
a time and therefor, excepting for program isolation there is not
much to be gained. In fact you loose some due to context switch
overhead for the additional threads.

If, however, you conceptualize a program as a strand of DNA and
if you had an enzyme that would make snips here and there then
you could concievably run each snippet concurrently.

If you look at the native code of the Crusoe there are multiple
execution units. The Code Morphing code re-orders the instruction
sequence to try to make use of as many execution units as
possible. i.e do more instructions per clock. 

The process I am promoting looks at the application code from
a bit more of a distance. Actualy it would look at the post
morphed code and construct and distribute the strands at that level.

Unlike MOVE there is no data transport. Instead it is a context
transport. Somewhat similar to the context switching of a thread
however with an absolute minimum of data necessary for the
context switch perhaps as little as one word (64 bits, 128 bits
whatever the memory data width is).

Jim Dempsey



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