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
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
------------------------------------------------------
Not a thing. Just try doing signed comparisons without any signed operations.
What's a MAME/MESS?
No problem. Consider the most common case of 2's complemented representation of signed integers and a pair of integers of the same bit size. You subtract them the same way as you'd do with unsigned ones. If the result is 0, they're equal. Otherwise, they're not and you need to determine which one is smaller/bigger than the other. To find out which one is bigger/smaller, you only need the sign of the result (the most significant bit). But since the overflow can occur (e.g. when subtracting 16-bit integer 1 from 16-bit integer -32768 you want to get -32769 but that can't fit into just 16 bits anymore and you get 32767 and overflow), you must take that into account. So, you take the most significant bit of the result and treat it as the sign, which is subject to further correction. You can then simply XOR that MSBit with the overflow flag of the CPU (I haven't seen a CPU w/o that flag yet, so I consider that to be available) and the outcome of the XOR operation is the true sign of the result, whether there was overflow or not.
This is my 16-bit comparison routine for i8051 8-bit micro controller:
; R3(MSB) R2(LSB) is comared to R5(MSB) R4(LSB) CMP16: CLR C ; clear carry/borrow flag before 1st subtraction with borrow (there's no subtraction w/o borrow on this CPU)
MOV A, R4 SUBB A, R2 MOV B, A
MOV A, R5 SUBB A, R3
JNB ACC.7, CMP16_1 ; jump if MSBit of accumulator is 0, if the jump is taken the overflow (OV) flag is equal to true sign of the result of subtraction; otherwise OV is the inverse of the true sign CPL OV ; invert OV CMP16_1: ; got subtraction result's sign in OV!
ORL A, B ; now, find out if the subtraction gives us 0 (i.e. equal numbers), this doesn't affect carry/borrow and OV
RET
Now, this routine can be used to compare both signed and unsigned numbers. To differentiate between the two you use different conditional jumps after calling this routine:
For unsigned numbers: R5R4 = R3R2, if A = 0 (JZ) R5R4 R3R2, if A 0 (JNZ) R5R4 < R3R2, if CY = 1 (JC) R5R4 > R3R2, if CY = 0 and A 0 R5R4 >= R3R2, if CY = 0 (JNC)
For signed numbers: R5R4 = R3R2, if A = 0 (JZ) R5R4 R3R2, if A 0 (JNZ) R5R4 < R3R2, if OV = 1 (JO) R5R4 > R3R2, if OV = 0 and A 0 R5R4 >= R3R2, if OV = 0 (JNO)
There's no special zero flag on this CPU and JZ/JNZ compares the whole accumulator to 0 to make a decision on whether or not the jump is taken.
While I agree there's a bit more work involved in comparing signed numbers, it's not that big. In this case, just 2 extra instructions (JNB ACC.7,... and CPL OV). It will be different on a different CPU (if you can't test MSBit of a register directly or flag inversion is absent for OV) but it's doable. And if your signed numbers are small (and their subtraction can't give you the overflow), just to compare them you could add a positive bias to the two before doing subtraction to get away with effectively unsigned comparison. Or you could sign extend the numbers before subtraction to get rid of the overflow altogether. Depends on your CPU and maybe application. The next more complicated signed operation to implement would probably be division, especially if you want to get the remainder and both overflows (it can be that there's no overflow in the quotient, but there's in remainder!).
2's complemented multiplication is actually implemented easily with unsigned multiplication and even w/o finding the absolute values of the multiplicands. And you don't probably need signed numbers everywhere... :)Alex
how does it work then?
simon
:O
AN UNINITIATED!?!
A lot of *very* knowledgeable engineers have done some pretty amazing things with regards to processor and other emulation for these projects. About (IIRC) 7 years of effort have gone into these.
Regards, Mark
Yes, privileged instructions have to be replaced, although I don't know if VMware uses breakpoints or some other scheme. The main reason for this is that Intel made the error that not every privileged instruction causes a general protection fault when executed in user mode (ie. ring 3), although theoretically it should be that way.
Actually, applications running on a protected mode operating system shouldn't use privileged instructions anyway, so almost 100% of application code would run directly on the processor. It's the operating systems and system software (eg. drivers) where the code replacement is mainly needed.
-- M.I.K.e
In article , Gromer writes
Why a 386?
You mean simulation. emulation id a hardware system (see Lauterbach, Ashling, Nohau, Hitex, isystem, Signum etc etc
If you have to ask here don't start..... You are out of your depth.
Degree in electronics specialising in MCU's several years experience. Knowledge of some (if not most) of the tools out there now.
-- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
May be We fomilar with x86 architecture.
I suguest to find the "PCE"--IBM PC hardware emulator. It's simple enough to learn. It emulates most hardware of an IBM PC. and enable boot a DOS system
Not if you want to finish the run in your lifetime... For a simple byte code, like 8080, you use an array of pointers to functions, so you can just branch without doing any compares. For a machine with prefix codes, like x86, when you decode the prefix you add another level of indirection, and jump through a pointer to array of pointer to function. That pointer sort of converts the emulation to a state machine.
Note that if you just want to run the program and get the right results, this is relatively simple, although you need emulated hardware to go with the i/o instructions, or with more effort and per-byte flags memory mapped i/o.
If you want to handle timing, cache, etc, it's a BIG project!
-- bill davidsen SBC/Prodigy Yorktown Heights NY data center http://newsgroups.news.prodigy.com
It was a long time ago, but I wrote an 80186 emulator in C (with some assembly) that ran on an IBM-PC (or clone). It was good enough to access screen, hard drive, keyboard, floppy, etc., and do so in such a way that the emulated processor crashing (destroying interrupt vectors, etc) did not affect the "real" processor it was running on (virtual memory for the emulated processor).
It was also capable of emulating itself emulating running itself.
If you want to check it out, go to
Bill
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.