1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

Emulating a processor

Discussion in 'Intel' started by Gromer, Nov 22, 2005.

  1. Gromer

    Gromer Guest

    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
     
    Gromer, Nov 22, 2005
    #1
    1. Advertising

  2. why not take a look at the Bochs source code? Of course, it emulates
    an entire PC system, not just the processor...
     
    Michael Quinlivan, Nov 22, 2005
    #2
    1. Advertising

  3. Gromer

    Simon Felix Guest

    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
    (http://dosbox.sf.net/). 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:
    > 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
    >
     
    Simon Felix, Nov 22, 2005
    #3
  4. [F'up2 cut down --- OP neglected doing it.]

    In comp.arch.embedded 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 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 (-aachen.de)
    Even if all the snow were burnt, ashes would remain.
     
    Hans-Bernhard Broeker, Nov 22, 2005
    #4
  5. Gromer

    Damiano Guest

    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:...
    > 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
    >
     
    Damiano, Nov 22, 2005
    #5
  6. ["Followup-To:" nach comp.arch.embedded gesetzt.]

    Simon Felix <> schrieb:

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


    VMWare does not work this way.

    Markus
     
    Markus Becker, Nov 22, 2005
    #6
  7. On 2005-11-22, 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.


    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.

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


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

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


    --
    Grant Edwards grante Yow! Yow! Are we in the
    at perfect mood?
    visi.com
     
    Grant Edwards, Nov 22, 2005
    #7
  8. Grant Edwards wrote:

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


    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
    | two, one and one make one."
    mrkesti at comcast dot net | - The Who, Bargain
     
    Michael R. Kesti, Nov 22, 2005
    #8
  9. In article <>, says...
    > Grant Edwards wrote:
    >
    > >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.

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

    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
     
    Mark Borgerson, Nov 22, 2005
    #9
  10. 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?

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

    --
    ========================================================================
    Michael Kesti | "And like, one and one don't make
    | two, one and one make one."
    mrkesti at comcast dot net | - The Who, Bargain
     
    Michael R. Kesti, Nov 22, 2005
    #10
  11. 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------
     
    Laurent D.A.M. Menten, Nov 22, 2005
    #11
  12. In article <>, 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
     
    Mark Borgerson, Nov 23, 2005
    #12
  13. "Gromer" <> ???????/???????? ? ???????? ?????????:
    news:...
    > 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:).
     
    Alexei A. Frounze, Nov 23, 2005
    #13
  14. 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
     
    Mark McDougall, Nov 24, 2005
    #14
  15. "Michael R. Kesti" <> 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?
     
    Everett M. Greene, Nov 24, 2005
    #15
  16. "Everett M. Greene" <> ???????/???????? ? ????????
    ?????????: news:...
    ....
    > 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
     
    Alexei A. Frounze, Nov 24, 2005
    #16
  17. 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
     
    Florian Boelstler, Nov 24, 2005
    #17
  18. Gromer

    Gromer Guest

    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" <> ???????/???????? ? ???????? ?????????:
    > news:...
    > > 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:).
     
    Gromer, Nov 24, 2005
    #18
  19. Gromer

    Didi Guest

    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
    ------------------------------------------------------
     
    Didi, Nov 24, 2005
    #19
  20. "Alexei A. Frounze" <> writes:
    > "Everett M. Greene" <> 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.
     
    Everett M. Greene, Nov 24, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Gromer

    Re: Emulating a processor

    Gromer, Nov 22, 2005, in forum: Intel
    Replies:
    2
    Views:
    281
    Rob Warnock
    Nov 22, 2005
  2. SpaceInvader

    Emulating ADDWFC on 16F PIC uCONTROLLER

    SpaceInvader, Nov 15, 2004, in forum: Embedded
    Replies:
    8
    Views:
    470
    Anthony Marchini
    Dec 21, 2004
  3. Gromer

    Emulating a processor

    Gromer, Nov 22, 2005, in forum: Embedded
    Replies:
    36
    Views:
    878
    oldfogie
    Dec 1, 2005
  4. Gromer

    Re: Emulating a processor

    Gromer, Nov 22, 2005, in forum: Embedded
    Replies:
    2
    Views:
    245
    Rob Warnock
    Nov 22, 2005
  5. Replies:
    13
    Views:
    676
    Ulf Samuelsson
    May 5, 2006
Loading...

Share This Page