(And if my code doesn't run 5 times faster than yours, I'll eat my hat. High-efficiency code is my specialty, and I am even published once on the topic.)
Keep your hat for now, high efficiency code is my speciality as well
And do not forget about Amdahl law!
The Siminterface has been deleted. Most of textconfig has been deleted. Access to variables through the param tree is done for user display only, and the param tree has been completely redefined and simplified.
Looks fine but will not change things that much.
The testconfig and siminterface is running less than 0.5% of the time. Simplest profiling shows what 99.5% of the time you running CPU emulation code.
I agree with you, siminterface is ugly and good to be be rewritten. But even throwing it away completely won't change if you want to reach "5 times faster" goal.
All the CPU memory structures have been completely redefined for efficiency (as arrays).
What is the CPU memory structure (I just don't understand what do you mean) ?
Could you send me an example of your redefined CPU code ?
The selected debugger now is completely in charge of driving the simulation. The interface between the init code and the debuggers has been standardized.All the multithreaded mods above have been implemented.
Cool! This is what I wanted to get on Bochs 2.3.8 time frame but not succeded because of ... nobody responded when I asked about this interface and help to define it.
The instruction decoder has been made more efficient than the instruction cache, and therefore the instruction cache has been deleted.
Now it is my time: I will eat my hat if you could show x86 instruction decoder which is faster than just blind copy of the decoded instruction from the cache.
The instruction cache/trace cache in Bochs could be improved 2-3 times at least but there is no way to write x86 decode which is faster than caching.
I remember you described how do you plan to do the decoder. I could guarantee you pretty nice slowdown of 2-5x against cache.
BX_EVENTS have been deleted.
What do you mean ? Did it exists ?
Breakpoints have been simplified and are managed for efficiency.
I once asked you this new break point code for current Bochs, could you send it - it is pretty good idea and I want to integrate it into today's Bochs.
(Who knows when and if the rewrite will be finished)
All the code is written in pure C for portability and simplicity.
Portability or simplicity even not near here.
Current Bochs code written with "very basic" C++, i.e. we stay away of teemplates, STL, even hardly try to stay away of virtual functions unless required.
Personally me highly agains virtual functions of any complex classes hierarhy in Bochs.
Such subset of C++ can't more portable than C
About simplicity we can argue a lot. I still will not belive that pure C code is simpler to understand.
Look on your GUI debugger code - Once you doing smth complicated you end up with dozens of global variables (which you never understand) or catch yourslef emulating C++ in C with structs which you must transfer to all the function by pointer (not adds to simplicity as well).
All devices are always compiled into the code, and "enabled" at runtime. Plugins have been eliminated.
You missed the point here. The "plugins" were invented to allow user to write a device module separately from Bochs and attach it to the already comiled Bochs model. You can argue this is not working yet, even now, but this is certainly an intention. Plugins - the only way I see to enable such capability.
Most conditional code has been eliminated. Almost all compile-time options have been eliminated, and turned into runtime options (bochsrc or commandline). One GUI and one textmode debugger are selected at compile time (only).
You want to say that checking for every instruction if it supported on current CPU (which is configured on runtime) is faster than just conditionally compile all such features ? Add yourself another 1.5x slowdown vs current Bochs.
Next, I am going to redefine and simplify the interface between the sim and the devices.
Bruce, of course I am a bit cynic above, and I am sure some of your ideas are very good.
I am will be very glad to replace param tree in current Bochs already or take some of your ideas into the code.
You should understand, once in a year or two comes a person with ideas of complete rewrite of whole Bochs code to make it 10 times faster and 10 times simpler. You know, it is never succeed yet. On paper everything looks perfect but becames different when converted to the algorithms and code.
But every such person always has brilliant ideas which give a break-through to Bochs. And I am already schedule a next break-through, even if I can't tell your rewrite will succeed or even happen.
Stanislav
