I've looked at both Qemu and BOCHS and have thoughts on each one.
BOCHS:
OO (C++) code. This is good an what we are doing lends itself to object representation.
Poorly documented. Not necessarily the project, but the code. Comment, comment, comment. Ramp up time to put another new graphics card in will take a while IMHO.
System level simulation only. For what we are doing, I think this is good as have user mode translation like Qemu doesn't do anything for us and adds complexity to the rest of the system that we have to understand to some degree.
Qemu:
C code. We would be contributing the first C++ code to the project. Don't know if that's good or bad or what the project maintainers would think.
Still poorly documented. However since it's not OO code it's a bit easier to read IMHO.
User mode simulation adds code complexity that we don't care about.
So my thoughts are as follows. We have a distinct need which can be reasonably met but either project. I don't care which we use. My approach would be to simply write our hardware simulator as a completely separate library module and when it reaches significant enough complexity and completeness we wrap it in the necessary translation code to hook in to either or both projects.
Patrick M Sakari Ailus wrote:
Patrick McNamara wrote:
to build a complete software simulation of the card? I'm thinking about something like adding a simulation of our card to BOCHs. A lot of work
How about Qemu?
<URL:http://fabrice.bellard.free.fr/qemu/about.html>
One advantage would be that it's much faster than Bochs on i386.
_______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
