Universal Processor (was Re: [oc] x86 IP Core)

[John Dalton <john.dalton@bigfoot.com>]

I'm not aware of one (I'll keep an eye out), but your
request has given me an idea for a core.  I don't
think I will have time to work on this idea, but if anyone
thinks it is a good idea, they are free to develop
it.

Basically, the idea can be described as a hardware
version of 'code morphing' technology.  Code morphing
processors on the fly translate processor instructions
(such as x86, 68000, etc) into a 'native' format which
is then executed.  The 'translation' step is invisible
to the outside world, so a program runs just as is it
were running on an 'x86', 68000 or whatever.

What if we had a processor that executed a versatile
'native' instruction set.  Prossibly this processor
would be based on the OpenRisc?

In conjunction with this proessor, we design a bunch
of 'translators' which sit between the processor and
program memory, x86 instructions might go into
this block and OpenRisc instruction come out.  These
OpenRisc instructions would then be executed.  In this way,
the OpenRisc would act like an x86.  Translators could also
be designed for the 68000, Z80, ..., name your processor.

What if we generalised this concept and wrote a 'translator
compiler'?  This would be a program that abstracts the
methods used to write a translator.  Its input is a specification
of the instruction set to be 'traslated' (maybe use the same
language which is used to describe s processor to gcc?).
Its output is the VHDL, verilog or RTL for a translator to
translate instruction set 'X' to OpenRisc.

Steps to design/build an arbitrary processor would now
become:
1) Write a gcc machine description (.md) file for a processor.
2) Automatically generate HDL for a translator/OpenRisc combination
    (using the generator described above)
3) Synthesise the resulting HDL files.

Perhaps this idea has already been done, but if not, any takers
to do it?

This project would 'leverage' the opencores process as existing
processor descriptions could be reused each time a 'new'
processor is to be designed.

Regards
John Dalton



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