Motherboard Forums


Reply
Thread Tools Display Modes

Emulating a processor

 
 
Laurent D.A.M. Menten
Guest
Posts: n/a
 
      11-22-2005, 11:19 PM
Gromer wrote:
> 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
>


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 With Quote
 
 
 
 
Mark Borgerson
Guest
Posts: n/a
 
      11-23-2005, 01:21 AM
In article <(E-Mail Removed)>, (E-Mail Removed) says...
> Mark Borgerson wrote:
>
> >I did the same thing for the 68K processor.

>
> 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.
>
> > 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!

>
> Yes, I can see that a classroom environment may be the best place for
> serious use of such programs.
>
> >My simulator would interpret M68K assembly language in a text file--
> >stepping through the source code and showing effects on registers
> >and memory.

>
> 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?


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.

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

>
> 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?



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 With Quote
 
 
 
 
Alexei A. Frounze
Guest
Posts: n/a
 
      11-23-2005, 05:20 AM
"Gromer" <(E-Mail Removed)> ???????/???????? ? ???????? ?????????:
news:(E-Mail Removed) ups.com...
> 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.


 
Reply With Quote
 
Mark McDougall
Guest
Posts: n/a
 
      11-24-2005, 01:08 AM
Gromer wrote:

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


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 www.opencores.org for the
6502 and Z80 cores.

Regards,
Mark
 
Reply With Quote
 
Everett M. Greene
Guest
Posts: n/a
 
      11-24-2005, 05:00 AM
"Michael R. Kesti" <(E-Mail Removed)> writes:
> Mark Borgerson wrote:
>
> >I did the same thing for the 68K processor.

>
> 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.
>
> > 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!

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


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"].

> >My simulator would interpret M68K assembly language in a text file--
> >stepping through the source code and showing effects on registers
> >and memory.

>
> 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?
>
> > 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.

>
> 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?

 
Reply With Quote
 
Alexei A. Frounze
Guest
Posts: n/a
 
      11-24-2005, 09:39 AM
"Everett M. Greene" <(E-Mail Removed)> ???????/???????? ? ????????
?????????: news:(E-Mail Removed)...
....
> 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"].


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

Alex


 
Reply With Quote
 
Florian Boelstler
Guest
Posts: n/a
 
      11-24-2005, 10:43 AM
Michael R. Kesti wrote:
> 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?


Xilinx SDK (slightly modified Eclipse CDT) for PowerPC distributed with
Xilinx EDK came with a PPC simulator.

Eclipse CDT debugger works quite good in conjunction with the PPC simulator.

Florian

 
Reply With Quote
 
Gromer
Guest
Posts: n/a
 
      11-24-2005, 12:14 PM
Hi all,

Thanks for all your suggestions... Now i've just started goin thru some
documents....

I have one basic doubt on how MEM WR/RD# cycles are emulated.. (i.e
memory read & write cycles emulated in software).. i mean how are the
rd/wr (ASSERT/DE-ASSERT) signals sychronised for a memory access in
software...( eg: var = *(someMEM))..

Thanks

Alexei A. Frounze wrote:
> "Gromer" <(E-Mail Removed)> ???????/???????? ? ???????? ?????????:
> news:(E-Mail Removed) ups.com...
> > 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.


 
Reply With Quote
 
Didi
Guest
Posts: n/a
 
      11-24-2005, 01:03 PM
I guess we also have to mention source level emulation (well,
not on a 386...I doubt anyone would like to do this).
The earliest example I remember was the 6809, the assembler could
assemble 6800 sources... I noticed from the previous postings I am by
far not the only one here who remembers that.
In a more recent twist, I wrote an ... hmm... assembler or compiler,
not sure how to call it, which assembles 68K (up to CPU32 complexity)
source code into PPC object code (believe it or not, the resulting code
length is on average only about 3.5 times the native CPU32 code
length).
If one has access to all the sources, this is a viable emulation (if
emulation is the right word...) choice.

Dimiter
(saying hello to the embedded group, just joined - and to
those crossposted :-)

------------------------------------------------------
Dimiter Popoff Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------

 
Reply With Quote
 
Everett M. Greene
Guest
Posts: n/a
 
      11-24-2005, 07:52 PM
"Alexei A. Frounze" <(E-Mail Removed)> writes:
> "Everett M. Greene" <(E-Mail Removed)> wrote:
> ....
> > 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"].

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


Not a thing. Just try doing signed comparisons without
any signed operations.
 
Reply With Quote
 
 
 
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Emulating JTAG with micro for programming PROM scott.manton@gmail.com Embedded 13 05-05-2006 03:00 PM
Emulating a processor Gromer Embedded 36 12-01-2005 03:30 AM
Re: Emulating a processor Gromer Intel 2 11-22-2005 02:09 PM
Re: Emulating a processor Gromer Embedded 2 11-22-2005 02:09 PM
Emulating ADDWFC on 16F PIC uCONTROLLER SpaceInvader Embedded 8 12-21-2004 10:02 PM


All times are GMT. The time now is 02:44 PM.


Welcome!
Welcome to Motherboard Point
 

Advertisment