OSDev.org

stlw wrote:Neolander, "They" - is me

Yes, I learned that some post later, by randomly reading the "Stanislav" at the end of your posts
But... I thought that you were two ?

bewing wrote:while bochs is only maintained by Stanislav and Volker

And I actually planned up-front all CPU related changes that were introduced in Bochs in last few years.

What about the rest ? GUI debugger (can't even get it to compile, it keeps asking for wxsomething even with wxwidgets+wxgtk 2.6 and 2.8 with dev versions around), new hardware, and so forth ? Looking at bewing's posts, it seems that it wasn't that easy everywhere...

Some rewrite will be needed only for parallel Bochs (doing SMP in many threads), but this not ground up rewrite.

Good ! SMP support is nice, indeed, since single CPU are getting slower these days

Now while I am here, some ideas for Bochs and ReBochs (because competition is good ^^) :

What about preventing it from making some Linux GUIs laggy ? I don't know if it's the case for gnome, too, but at least on KDE 4.3 the slowdown is terrible.

The Flash plugin used 100% CPU on my old computer, but it only slowed down the web browser, not the rest of the GUI, I still could do everything I want in the background, so they must have found out some trick to give control to the GUI when it needs to.
To the contrary, Bochs annoyingly makes everything slow on my computer while it runs. I managed to reduce this effect a bit by playing with niceness, but I've still got something like the when older versions of xvidcap were running in the background.

That's my main issue with Bochs now. I'm ready to pay the price of slighty slowed down emulation speed in order to keep a snappy underlying OS, and think it should at least be available as an option.
Other issues are slow GRUB loading (is it so hard to load less than 300 KB of data in memory, or did you make it intentionally slow in order to emulate diskette speed ?) and having to disable numpad in order to enable it in bochs. Plus, there seems to be something wrong about the way Bochs is refreshing the GUI : it keeps refreshing it when nothing new happened and even if the CPU is in HLT state (I can tell by some small screen artifacts on top of the windows ), which clearly is wasting CPU time, and when you stop bochs emulation through the debugger, I think that the main windows should still be refreshed when something is moving in front of it (something that would require a multi-threaded program and maybe more GUI/emulator separation, I suppose)

Note that if all those issues were solved, this software would be close to perfect from an user's point of view. That's why I'm using it, after all

Volker doesn't contribute nearly as much time as Stanislav -- so Stanislav is by far the major maintainer of bochs.

I wrote the Bochs GUI debugger and contributed it to the Bochs project. It is the same one as you are using on ReBochs now (basically). I don't know why a lot of people have problems compiling it. That's one reason I made ReBochs -- to simplify the 'make' process so that the debugger would compile easily. The autoconf script for bochs stinks. Autoconf stinks, period.

There are several reasons why bochs loads grub slowly -- probably mostly involving ISA DMA emulation. ReBochs does the DMA emulation differently, and is much faster.

The main problem with linux slowdowns is probably that the linux timeslices per job are waaaaay tooooo loooooong. 100th of a second? Bochs calculates efficiently, and does not have many system calls -- so it does not swap out. If you can, try speeding up your scheduler's clockrate.

And I could make a fairly long list of why bochs is not perfect. While I was writing the GUI debugger, I spent a lot of time going through the bochs code, and not being happy.

-- Oh, and when you talk about "the GUI" on bochs (or rebochs), you need to be quite specific. It is best to call the "VGA Window GUI" the VGAW, and otherwise talk about "the debugger". Or else we get confused as to which window you mean.

bewing wrote:The main problem with linux slowdowns is probably that the linux timeslices per job are waaaaay tooooo loooooong. 100th of a second? Bochs calculates efficiently, and does not have many system calls -- so it does not swap out. If you can, try speeding up your scheduler's clockrate.

Can I do so without recompiling my kernel ? I saw an option for scheduler's clockrate when doing so while I was trying gentoo, but long-time gentoo use also convinced me to stop recompiling everything and try to use binary that works (tm) as much as possible.

I'm afraid I don't know the answer to that. I know that it's possible on some linuxes to set it to a much higher rate, but I am not a linux expert. Maybe make a post on the General Programming board?

bewing wrote:Volker doesn't contribute nearly as much time as Stanislav -- so Stanislav is by far the major maintainer of bochs.

Actually the picture is different. I am maintaining Bochs CPU and some related stuff (APIC, I/O APIC and Memory).
I am also maintain Bochs internal debugger (but not the GUI debugger by bewing, the code as is more or less unmainatable, even not very readable to me).

Volker holds all the rest, including devices, GUI, interfaces, param_tree ... Even documentation.
Historically it happens that CPU had more modifications that all the rest, eventually CPU will become nearly perfect and won't be bottleneck anymore.

bewing wrote:And I could make a fairly long list of why bochs is not perfect. While I was writing the GUI debugger, I spent a lot of time going through the bochs code, and not being happy.

I think it is good idea if you make this list. Knowing the problems is the first step to fixing them.
Pretty sure most of your complains have nothing to do with CPU model

Stanislav

Hey guys. Long time. Sup ?

Hi there! Just making progress in having the debugger we wrote take over the world. No biggie.

Have you considered native 64-bit Windows support (just because it's becoming more common and could give some nice performance boosts)?

Creature wrote:Have you considered native 64-bit Windows support (just because it's becoming more common and could give some nice performance boosts)?

We do

So the debugger we started will take over the world in x64 as well ?

Nice move btw. All my projects are in x64 since ages but I am worried to see that users still prefer x86 OSes.

Michael.

WindowsNT wrote:So the debugger we started will take over the world in x64 as well ?

Nice move btw. All my projects are in x64 since ages but I am worried to see that users still prefer x86 OSes.

Michael.

Agreed, I recently got a Windows 64-bit targetted GCC. But now I'm having doubts about whether I shouldn't switch back. In any case, if you support 64-bit, you'll almost have no choice but to target 32-bit too, since apparently most users still use a 32-bit Windows XP (I think 64-bit became a bit more common with Vista and probably even more with 7).

x64 will prevail when Windows is finally released only as a x64 rtm.

It only takes 2000 new lines of code to support any new GDI and/or OS. Anyone is free to donate code anytime they want. But between extending this emulator to model 64bit CPUs, adding hardware models to it, and writing my OS -- it is likely to be several years before I even think about native 64bit Windoze support. Especially since I think Windoze sux, and I don't plan on ever buying an upgraded version of it. I'm more likely to create a Qt port before I do much more with Windoze. The linux performance needs the help more than the Windoze performance does. Win32 is stable, it has been debugged, the 2000 lines of support code are written, and this emulator is computation-bound ... not GDI bound, when it comes to performance.

Or, perhaps, I may try doing a SkyOS port. Everyone keeps saying what a well-designed GDI it has. I'd be curious to see for myself -- and the best way of seeing is by trying it.

bewing wrote:It only takes 2000 new lines of code to support any new GDI and/or OS. Anyone is free to donate code anytime they want. But between extending this emulator to model 64bit CPUs, adding hardware models to it, and writing my OS -- it is likely to be several years before I even think about native 64bit Windoze support. Especially since I think Windoze sux, and I don't plan on ever buying an upgraded version of it. I'm more likely to create a Qt port before I do much more with Windoze. The linux performance needs the help more than the Windoze performance does. Win32 is stable, it has been debugged, the 2000 lines of support code are written, and this emulator is computation-bound ... not GDI bound, when it comes to performance.

Or, perhaps, I may try doing a SkyOS port. Everyone keeps saying what a well-designed GDI it has. I'd be curious to see for myself -- and the best way of seeing is by trying it.

If you're only planning on supporting mainstream OS' like Windows, Linux and Mac, why not just opt for 64-bit only? It just seems to me that several years from now, 32-bit OS' might have completely vanished from the PC and you will still be stuck with an older architecture, which you will probably feel annoyed about because you'll have to rewrite it again to support another architecture.

Qt is IMHO a fairly good choice, since it's crossplatform and all (and "fairly" fast). Note that even though it has no 64-bit binaries, there are reports that building the sources with a 64-bit target doesn't give you any trouble.

You can't opt for ONLY x64 atm. As I said, it all depends on next Windows version. If it comes in x64 only, THEN you want to only mess with x64. As about QT, it is goot but untested solution with many issues yet - and lack of x64 binaries indicates that many developers are reluctant to support x64 even in 2010.