Gromer said:
I'm interested to understand the processor architecture in depth. So i
decided on emulating the processor itself (as my project). The best one
to start would be 386.
As many have already pointed out, there're a few ways of achieving that:
- emulating the software model (what you get access from programming
standpoint)
- emulating the hardware model (how the chip appears to the circuitry it's
connected with: there were references to VHDL
- both
Now, emulating the software model can be done natively, semi-natively or
entirely, which means you emulate it on the same kind of CPU executing all
instructions w/o emulating them or doing that transparently (this could be
done on AMD64 and intel EM64T), semi-natively (by modifying the code prior
to execution (possibly recompiling it) or by parsing the code, finding
offending instructions and emulating them or replacing by the instructions
that would have the same effect but not cause any undesired side effects
(e.g. exceptions)), entirely when the CPU on which you emulate the other CPU
you can't benefit from the exactness of the both CPUs since there's no such
thing (if the emulator can be considered as a superset of the emulatee, you
could probably translate many instructions on the fly and execute them).
The problem with everything from i80286 and up is that you can't do native
emulation on another x86 CPU because you can't do that transparently and
that's because you can't intercept every protection-related instruction.
That's a design problem, you can't do much with that.
So, if I were you, I'd start with i8086 and i80186 emulation (if I'm not
mistaken, i80186 = i80286 - protected mode).
Now, as far as the hardware goes... Can you build a real hardware system
like a simple PC and instead of real x86 CPU put there say an FPGA
(supposedly a huge one or even many or add some other logic to minimize use
of FPGA gates)? Really, how good are you at this sort of engineering? If you
want it to be a software model of hardware chip, well, the work would amount
to from as little as emulating the pieces that in the real world have pins
on the chip to as much as doing that and doing the software model emulation
too...
So, where would you like to draw a line between what you want/can do and
what you don't/can't?
Alex
P.S. I had made an i8051 8-bit microcontroller software emulator, which is
more of a debugger that includes disassembly and source code browsing (if
available, otherwise falls back to disasm). It does not emulate any standard
on-chip devices, just the ALU and memory. While it's not anything really big
or impressive, quite some good work had to be done to make it. The i80386 is
an order of magnitude more (or even more) complicated than the i8051. And
always remember about the bugs. I started in 1994. The last
emulation-related bug was fixed in 2002, even though the thing was thought
finished around 1996. Windows related problem was fixed in 2003 (the
emulator was starving due to BIOS int 10h keyboard input polling -- quite
normal thing to do in DOS applications
.
