----- Original Message ----- From: Jonny Taylor To: Sent: Friday, February 07, 2003 2:02 PM Subject: [PIC]: fast emulator > Hi everyone, > > I have been experimenting with writing a PIC emulator, and was hoping for > some advice. I started doing this as a way of demonstrating the power of > dynamic compilation. The result is a (currently partially-complete) PIC > emulator which I have tested at sustained speeds of around 80 MIPS on my > 300MHz computer (and I mean with genuine code downloaded from the internet, > not code contrived to be gentle to the emulator). > > This is far faster than I am aware of any currently-available emulators > managing. Of course, this speed is reduced a little sometimes (for parts of > the program which deal with ports and with complex control registers such as > the OPTION register, and for programs which use lots of timers of very short > [< 20 cycles] duration), but the joy of dynamic compilation is that this > reduction can be minimized. In addition, features such as logging, > conditional breakpoints, watchpoints and the like can be implemented with > very little overhead (and none at all in areas of code that are not > affected) - and time-delay loops can be identified at compile-time and > optimized to be VERY fast indeed. > > What I am hoping for advice on is whether it is worth pursuing this project. > It has served its purpose well as a demonstration of dynamic compilation. I > am now trying to decide whether I should continue and take the time to > produce a program that others could use for their development. I am > confident that it would perform far better than existing emulators (unless > there's one I'm not aware of), but the question is whether that is actually > *necessary*. > > Do you find that existing emulators are too slow for your needs (or are not > able to provide the features that you want without compromising emulation > speed), or are they actually sufficient? I have some very good ideas for > features that would be useful in a PC-based emulator, but I know that there > are a number of existing emulators available. I don't feel it is worth the > effort of writing another one unless it has a compelling advantage over the > existing ones. > > There is one further caveat to my claims. The prototype that I have written > runs on a Macintosh computer, which I know is not the most popular of > platforms :). Unfortunately dynamic compilation is about as > platform-specific as you can get, so porting it to Windows or Linux would > not be trivial. Unless someone else was interested in transferring my ideas > over to such a platform (maybe based on the platform-independent core of my > code), this would probably reduce the popularity of my emulator. I assume by this that what you actually mean is that each PIC instruction is converted to a sequence of host instructions. That you build a native host executable that does not execute a given function per instruction, no call or returns. The thing is, most simulators do hardware specific simulation at every CPU cycle. They interleave instruction and hardware simulation. You also need to trace instructions as they are processed. You need to provide the user with a mechanism where they can run to a break point then check to see what events occured that lead to that point. A trace buffer of some kind is invaluable. With this you would need to show what changes occured, instruction by instruction, so that the user can work his/her way back. Again this does not go well with non-stop no-boundry execution. > > Incidentally, one particular feature which someone suggested to me was that > a fast software emulator could easily be linked up to a circuit board as a > way of providing in-circuit emulation with all the advantages of running it > from a PC and without the expense of dedicated ICE hardware. I am very > interested by this possibility (has it been done before?) although I > recognise that it would be limited by latencies in the data transfer between > computer and circuit, preventing it from being useful in some applications > where precise I/O timing was critical. not just that, but your simulated processor cycles will have different times depending on which instruction is being simulated. If you are going to simulate a processor you need to be able to accurately predict timing. It cannot run at 100 MIPS in loop A and 90 MIPS in loop B. That would really cause you problems. > > I would be very grateful for advice (on or off list) on whether people think > this is worth spending time on - even if it's just a "I would/wouldn't use > it". > > Thanks very much in advance > Jonny I don't want to put you off. I just think that these are things you should consider carefully. Look at specific PIC and consider how you would simulate ALL the hardware (e.g. A/D, UART, I2C, EEPROM read/write, PORT B interrupts, watchdog). As personal projects go I certainly think it is worth while. Regards Sergio Masci http://www.xcprod.com -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.