Emulating a processor

Hi all,

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.

So i wud require some documents which explains on how to emulate any processor or devices. ( Apart from the Intel Architecture documents available). How to emulate a 386 processor. I want to kno how usually this is done. I wonder how bochs has been developed so elegantly...the resource they've used.

It wud be appreciable if someone can guide me on any documents or reference books avaliable on Emulating processors and devices.

. Wht are the resources I should have in hand to start up up this project.

Thanks, Gromer

Reply to
Gromer
Loading thread data ...

why not take a look at the Bochs source code? Of course, it emulates an entire PC system, not just the processor...

Reply to
Michael Quinlivan

basically you have two choices:

full emulation: you read a byte from (emulated) ram and interpret/execute it (use a huge switch-statement). then advance to the next byte and interpret/execute it, ...

the virtualpc/qemu-with-accelerator/vmware/...-way: run the code as ring3-process. catch every exception and emulate the thing that caused the exception (i/o ports, mmu-stuff, ...)

but i suggest starting with something similar to dosbox

formatting link
create a real-mode-only-emulator first. messing around with page-tables and exceptions makes emulation quite difficult to get right...

regards, simon

Gromer wrote:

Reply to
Simon Felix

I really wonder by what strange criteria the 386 could possibly come out as "the best". Actually, the x86 is almost certainly the single worst possible CPU line to do any theoretical work on. It's just too plagued with silly exceptions due to its long history of compatibility kept at almost any cost.

If you really want to learn something about CPU emulation, I'd recommend Professor Knuth's work on the MIX and MMIX platforms --- those are CPUs designed purely for educational purpose, and they only ever existed as emulators, the original ones written by his Knuth-ness in person.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

Hi Gromer

Why not to take an approach to vhdl. Instead of emulating you can simulate and even synthesize. If your aim is to better understand how a processor work this may give you a deeper understanding. Also there are numerous processor cores available as open source in vhdl, mainly microcontrollers.

"Gromer" ha scritto nel messaggio news: snipped-for-privacy@o13g2000cwo.googlegroups.com...

Reply to
Damiano
["Followup-To:" nach comp.arch.embedded gesetzt.]

Simon Felix schrieb:

VMWare does not work this way.

Markus

Reply to
Markus Becker

Yikes. Since you've never written an emulator, I would have recommended starting with a decent architecture. Something like a PDP-11 or 6809 or Z80. The '386 is a really nasty bit of work. It's 3 or 4 badly designed processors rolled into one.

Well, if you want to know how bochs as done, then look at the bochs source code and documentation.

--
Grant Edwards                   grante             Yow!  Yow! Are we in the
                                  at               perfect mood?
 Click to see the full signature
Reply to
Grant Edwards

no? how does it work?

Reply to
Simon Felix

Simon Felix schrieb:

It does not emulate the processor, it just uses it.

Markus

Reply to
Markus Becker

Which is what he said. It does emulate the IO (or a lot of it, anyway) though, and provides emulated hardware like video cards, network cards and the like. Which is also what he said.

--
Nobby
Reply to
Nobody Here

Agreed.

I wrote a Z80 simulator (I believe that the correct term for this thread's topic is "simulator" rather than "emulator".) 20 years ao in 8088 assembler on an 8 MHz AT&T 6300 that, at the time, had two 5.25" floppies and no hard disk!

I used a rather straight forward (brute force?) method of allocating data structures for the internal registers and look up tables for the op-codes. The tables where used to jump to functions that "executed" the op-codes. An Intel hex file decoder read program files into the simulated Z80 memory space.

As usual, the hardest part was the user interface, especially the displays of registers, and memory and I/O spaces. Interrupt generation was the program's weak point and the thing I most planned to improve but never got around to.

The greatest benefit of writing this program was the education concerning the Z80's internals. I was writing embedded Z80 systems so this was a good thing!

I had long thought that I had lost the source to this program but, in a office renovation, I recently came across a disk that appears to contain it. The trouble is that I no longer have a machine with a 5.25" floppy drive. I might have to buy such a drive on eBay soon and see if the disk is still readable!

--
========================================================================
          Michael Kesti            |  "And like, one and one don't make
 Click to see the full signature
Reply to
Michael R. Kesti

I did the same thing for the 68K processor. I also simulated a simple serial port and a few interrupts. As you say, the most difficult part was the user interface. My simulator was done on a Macintosh and worked well enough that I used it when I taught an introductory course on computer architecture. It turned out to be most useful in illustrating what happens in memory when you use stack-based parameters for subroutines. It beat the heck out of keeping track of the stack with paper and pencil!

My simulator would interpret M68K assembly language in a text file-- stepping through the source code and showing effects on registers and memory. It was cool at the time (mid 80's), but now you can get a better simulator with just about every IDE designed to do cross-compilation and debugging with an embedded processor.

Mark Borgerson

Reply to
Mark Borgerson

When I showed my simulator to the division engineering manager he asked me if I could do a 68K version because we were about to embark on a 68K project. I told him that I probably wouldn't finish it before the project's final testing phase and that it probably wouldn't be all that useful even if it was available sooner than that.

Yes, I can see that a classroom environment may be the best place for serious use of such programs.

It didn't occur to me to have my simulator also be an assembler, but I can see that this would be cool. How did you deal with forward references?

I've used plenty of IDE-based cross compilers and debuggers but don't recall any of them being equipped with simlators. Can you provide some examples of such?

--
========================================================================
          Michael Kesti            |  "And like, one and one don't make
 Click to see the full signature
Reply to
Michael R. Kesti

Check for SimCore, which emulate an alpha processor, as far as I remember it is a relatively small and easy to read set of c++ file.

-----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS/O d--(---) s: a C++ UL++++ P+ L+++ E--- W++ N+ o-- K--- w-- O- M- V- PS++ PE Y+ PGP- t 5 X++ R* tv++ b++ DI++ D G+ e++ h-- r+++ y+++

------END GEEK CODE BLOCK------

Reply to
Laurent D.A.M. Menten

The whole source file was in memory, so it was straightforward to do multiple passes to make up the symbol table, count the code bytes, and resolve the forward references.

Perhaps they're not as common as I thought. But I think that MPLab for the PIC chips has a simulator. Codewarrior PALMOS has a palm device emulator. I think that the Keil 8051 system that I used about

10 years ago had a simulator as part of the system. I think the C-Spy debugger for the IAR ARM development system also has a simulator option--although I've not used it.

Mark Borgerson

Reply to
Mark Borgerson

"Gromer" ???????/???????? ? ???????? ?????????: news: snipped-for-privacy@o13g2000cwo.googlegroups.com...

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:).

Reply to
Alexei A. Frounze

I wouldn't have chosen the 386 as the best place to start. I would've chosen something like an 8-bit micro such as Z80 or 6502.

You also don't say what your background is, and what sort of emulation/simulation you're looking at. ie. software? hardware (FPGA?). I'm guessing software from your comments about bochs.

Another place to look would be MAME/MESS. They emulate a whole host of processors. The architecture of the project is quite mature, and the processors should be quite nicely done, but the implementation could be clouded somewhat by the abstraction layers built around the memory and interrupt interfaces. None-the-less, a rich source of reference material.

If you're interested in FPGA implementations - and to some degree they're actually 'closer to the metal' and more likely to represent the true implementation of a microprocessor - see

formatting link
for the

6502 and Z80 cores.

Regards, Mark

Reply to
Mark McDougall

Another use is testing code from a cross-compiler for a processor that doesn't exist yet. With this application, you also get to deal with the vagaries of the documentation. It teaches you that some people have unusual ideas as to what constitutes a good processor design ["you don't need no steenkin' signed arithmetic"].

Reply to
Everett M. Greene

"Everett M. Greene" ???????/???????? ? ???????? ?????????: news: snipped-for-privacy@mojaveg.iwvisp.com... ...

I beg your pardon, what's so bad about signed arithmetics?

Alex

Reply to
Alexei A. Frounze

IIRC, it does a kind of JIT rewrite. Before first execution it scans the code for privileged or problem instruction sequences and patches in an equivalent code sequence or a trap to a handler.

The result is that most of the application runs without interference.

George

-- for email reply remove "/" from address

Reply to
George Neuner

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.