Skip to contentSkip to conversation

Bochs bios ported to gcc

ANN Kevin O'Connor 3 participants 6 messages Apr 2, 2008 – Apr 7, 2008 KVM

lore
Share & tools
lore
#0 lore raw

Hi,

I have been working on a port of bochs bios to gcc. This port is nearly complete. The new code does not rely on bcc or dev86. Instead, it uses standard gcc and gas. It should compile on any recent Linux distribution.

I'm sending this email because I understand kvm has a copy of bochs bios in its repository.

I am successfully booting freedos, linux, and netbsd with qemu. I'm interested in finding people willing to test the bios on other images and in different environments. The code is still in a testing phase - I don't think it will eat your data, but please be careful.

Source and pre-compiled bios images are available (use version 0.2.0) at:

http://linuxtogo.org/~kevin/legacybios/

More information on the details of the project can be found in the 'README' file, or at:

http://git.linuxtogo.org/?p=kevin/legacybios.git;a=blob_plain;f=README

There is also a source code repository located at:

http://git.linuxtogo.org/

Comments?
-Kevin

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

#1 lore raw
Quoted 8 lines · Kevin O'Connor

I have been working on a port of bochs bios to gcc. This port is nearly complete. The new code does not rely on bcc or dev86. Instead, it uses standard gcc and gas. It should compile on any recent Linux distribution.

I'm sending this email because I understand kvm has a copy of bochs bios in its repository.

While moving away from the horror that is bcc is a blessing, the way to really benefit from it is to have this code replace the original bochs bios. This way updates to the bochs bios are not lost for anyone using the new code.

Have you proposed replacing the bios to the bochs developers? What was the reaction?

Signature · 8 lines
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Register now and save $200. Hurry, offer ends at 11:59 p.m., 
Monday, April 7! Use priority code J8TLD2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
#2 lore raw
Quoted 7 lines · Avi Kivity
Quoted 1 line · Kevin O'Connor

I have been working on a port of bochs bios to gcc.

While moving away from the horror that is bcc is a blessing, the way to really benefit from it is to have this code replace the original bochs bios. This way updates to the bochs bios are not lost for anyone using the new code.

I agree. I've been interacting with the bochs developers since I started (about a month and half ago).

Quoted 2 lines

Have you proposed replacing the bios to the bochs developers? What was the reaction?

The reaction was pretty "quiet". The bochs project is not nearly as active as kvm, and the bios is just one small part of that project.

Now that the new code can actually launch a wide variety of payloads, I'm hoping there will be more interest.

BTW, if anyone is interested in testing, please grab the 0.2.1 version
- the v0.2.0 version had a nasty bug on disk writes to large disks (assuming one uses an OS that writes to disk via the bios).

-Kevin

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

#3 lore raw
In reply to Avi Kivity
Quoted 10 lines · Avi Kivity
Quoted 8 lines · Kevin O'Connor

I have been working on a port of bochs bios to gcc. This port is nearly complete. The new code does not rely on bcc or dev86. Instead, it uses standard gcc and gas. It should compile on any recent Linux distribution.

I'm sending this email because I understand kvm has a copy of bochs bios in its repository.

Quoted 8 lines

While moving away from the horror that is bcc is a blessing, the way to really benefit from it is to have this code replace the original bochs bios. This way updates to the bochs bios are not lost for anyone using the new code.

Have you proposed replacing the bios to the bochs developers? What was the reaction?

bcc is truly horrible. gcc is, of course, best, although it does produce bloated 16-bit code. For "proper" 16-bit code, OpenWatcom is currently the best open source compiler, and it's actually getting usable even on a Linux host.

-hpa

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

#4 lore raw
Quoted 2 lines · H. Peter Anvin

bcc is truly horrible. gcc is, of course, best, although it does produce bloated 16-bit code.

With gcc, the text size has actually been significantly reduced - I'm not sure if this is because I'm using -fwhole-program and -Os or if it is just the result of bcc being so bad.

The biggest problem I've run into is stack usage on the 16-bit bios calls.

Quoted 3 lines

For "proper" 16-bit code, OpenWatcom is currently the
best open source compiler, and it's actually getting usable even on a Linux host.

One of the developers on the bochs list also recommended OpenWatcom.

The bios currently has quite a bit of 32bit code in addition to the 16bit code. It's very convenient to be able to compile the same code in both modes (eg, printf, inb, etc.). I'd need to move both 32bit and 16bit code to OpenWatcom to do this.

-Kevin

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

#5 lore raw
Quoted 8 lines · Kevin O'Connor
Quoted 2 lines · H. Peter Anvin

bcc is truly horrible. gcc is, of course, best, although it does produce bloated 16-bit code.

With gcc, the text size has actually been significantly reduced - I'm not sure if this is because I'm using -fwhole-program and -Os or if it is just the result of bcc being so bad.

The 16-bit code is still horrid. I have done some experiments with a 16-bit backend to gcc last summer, and even when it could barely crawl, and had effectively no optimizations, it still produced 15% smaller code than the 32-bit backend with .code16gcc and the best optimizations I could find.

Quoted 7 lines

The biggest problem I've run into is stack usage on the 16-bit bios calls.

Quoted 3 lines

For "proper" 16-bit code, OpenWatcom is currently the
best open source compiler, and it's actually getting usable even on a Linux host.

Quoted 6 lines

One of the developers on the bochs list also recommended OpenWatcom.

The bios currently has quite a bit of 32bit code in addition to the 16bit code. It's very convenient to be able to compile the same code in both modes (eg, printf, inb, etc.). I'd need to move both 32bit and 16bit code to OpenWatcom to do this.

Yes, of course. OpenWatcom does do both, although I think gcc is a better compiler than OpenWatcom in 32-bit mode. OpenWatcom isn't bad, though.

As long as it's just C, it's not really an issue, though.

-hpa

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone