developers for emulator

[asdfgh]

hi i am writing an emulator for x86 architecture.

currently i disassembles the object file and emulates some of the instructions

if anyone is interested we can work to gether

[Combuster]

what's wrong with bochs and qemu?

[OrOS]

It's typically an attractive school project, or just for fun. Example, look at yourself, what's wrong with windows, mac, and linux?

[Love4Boobies]

what's wrong with bochs and qemu?

Lol. What's wrong with Linux/Windows/Mac OS/Solaris/BSD/whatever? Why would there be any need for MOS86 or whatever it's called?

[Combuster]

Oh, the world doesn't need my OS, if that's what you're asking.

The question was serious nonetheless - if you want to attract people you must have a plan. Not just a simple "help wanted".

[Love4Boobies]

True. Sorry, I thought you were just being a troll

[Combuster]

Even then you should know better to not feed it

[bewing]

what's wrong with bochs and qemu?

Bochs is slow, its memory structures are awful, its external debugger interface is awful, it is coded inefficiently, its "features" are silly and obsolete, its configure script makes me want to cry, it is not built to be thread safe, and it suffers from having too many fingers in the pie. It is in desperate need of a complete rewrite.

QEMU is not being well supported, it does not compile on current GCC, its simulation is not particularly accurate, it is lacking the stunningly wonderful GUI debugger that bochs has, and its coding is overly intricate.

[Alboin]

It's actually really hard to make a beautiful emulator. At least...in C\C++....

Perhaps we should try writing one in Haskell....

[pcmattman]

Considering Bochs at the moment, I'd imagine that would be an immense project that no single person would be able to pull off (at least, if they keep their sanity).

A new emulator would be interesting, but to truly compete against Bochs and QEMU it would have to be designed well, implemented well, and tested thoroughly.

[JohnnyTheDon]

Try writing a VT-x (Intel) or AMD-V (AMD obviously) emulator. The processor does all the actual execution of code, you just have to point it in the right direction. It can also give you experience for developing an exokernel OS.

[bewing]

bewing, why not slowly rewrite bochs to better shape? you can do it step by step without major breakage and in a controllable manner, can't you?

If I were to take all the bochs sourcecode, rename it "rebochs" (with a shoe for an icon), and begin a rewrite -- some of it could be done in that way, yes. The configure script, the param_tree, the main cpu_loop that runs the sim, the breakpoints, the "BX_Events", and making the "devices" threadsafe.

The memory code is already good, and so is the disassembler (and the gui debugger, of course).

However, the main thing that needs the most help is that the model of the CPU is all stored in C structures. Structures (and C++ objects) are SLOW. I know that programmers hate to hear that, but it is true. Arrays are MUCH FASTER. So, the basis of the rewrite would be to recode the entire CPU model using arrays instead of structures. Sadly, this would completely and utterly break every bit of the code in the entire program. And that is such a major design change that it would need to be done FIRST. Which means that the program WOULD be broken for the first 3 months.

But, overall, the answer to your question is:
Yes, I could probably get a really good rewrite started on the thing. I have spent 4 months on the user interface already. If I were to spend another 6 on bochs itself, I could probably get it to the point where it was singificantly simplified, and significantly faster -- with only easy incremental changes required to further improve it.

And I am tempted to do it, too. But I am also tempted to get back to working on my assembler, and my OS. And I am also tempted to spend some time trying to make some money, too.

[JohnnyTheDon]

Structures (and C++ objects) are SLOW.

Why? If they're aligned properly there won't be any problems with actually reading the data. Finding an offset might take a bit longer, but in the end

Code: Select all

     mov rbx, arrayBase
     mov rax, index
     shl rax, log2(elementSize)
     mov rdx, [rbx+rax]

is not much shorter or faster than:

Code: Select all

     mov rbx, arrayBase
     mov rax, index
     shl rax, log2(structSize)
     add rax, offsetInStruct
     mov rdx, [rbx+rax]

Unless I'm oversimplifying (which I might be, I haven't run efficiency tests on this).

[JohnnyTheDon]

Did some follow up with a little C program. Results:

Structure Time: 39163486164. Array Time: 38919099390.
Winner: Array. Difference: 244386774.

I had both do 1 billion random accesses of the same size (long). The results are in clocks (retrieved from rdtsc). My computer clocks at around 3.02 GHZ. That means the structure took 12.97 seconds, and the array took 12.89 seconds. The difference was 0.08 seconds. That is a 0.6% speed up. Ultimately, it doesn't seem like there is much of a difference. I got a higher speed increase with bochs when I compiled it using LLVM (which does robust link-time optimization).

I agree that bochs is one of the slower emulators. However, it also gives a lot more information about what is going on, especially in simulated hardware devices. And structures don't appear to be that slow, so you can't blame boch's speed issues on structures.

[Creature]

Why not organize some sort of community project where there is one main developer (or a few main developers) and others can contribute code? I know community projects usually aren't a good idea, but if it works you'd have a nice emulator. You could use parts of the Bochs/QEMU source code (after they've been rewritten to be more efficient).