Re: [oc] x86 IP Core

["Andras Tantos" <andras_tantos@tantos.homelinux.org>]

> 1) cycle accurate clone (real headache)
> 2) classical microcode engine (boring)
> 3) microcode engine that can reload on the fly - you could achieve
> even full pentium 6 support because new microcodes are loadable
> (well speed penalty)
> 4) custom VLIW machine emulating x86
> 5) some C programmable RISC emulating x86 - this is free option.
> but I looked at bochs, trying to compile them for fpga core, I would
> rather write an emulator in pure assembler, if I have time I could
> try to compile bochs with GCC-MB or GCC-PPC but I guess it will
> be a disaster :(
> 6) x86 Kernel-1 approuch - a x86 core that has minimal functionality to
> be an x86 emulator, it has some instructions implemented, all non
> implemented will fall through below highest 386 kenrel ring, Kernel(-1)
> /is now my definition/, in Kernel(-1) mode all the instruction the core
> does not support are emulated. This is faster than emulating with non
> x86 based machine. Again this approuch also allows full pentium support
> (speed penalty applies). And it allows the configurable core, for either
> speed or size. In all configurations Pentium class instruction could be
> supported.

I would consider using a JIT compiler-type approach instead of a simple
instruction-level emulator. Something, that Transmeta uses I suppose. Also,
you should cache the 'compiled' code and not the 'source' x86 but with
large-enough caches this approach can be pretty efficient. Of course you
would need an underlying CPU architecture that lends itslef easily to such
an approach. An off-the-selves RISC probably wouldn't do.

Regrads,
Andras Tantos

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