Slashdot Mirror
CoreBoot (LinuxBIOS) Can Boot Windows 7 Beta
billybob2 writes "CoreBoot (formerly LinuxBIOS), the free and open source BIOS replacement, can now boot Windows 7 Beta. Videos and screenshots of this demonstration, which was performed on an ASUS M2V-MX SE motherboard equipped with a 2GHz AMD Sempron CPU, can be viewed on the CoreBoot website. AMD engineers have also been submitting code to allow CoreBoot to run on the company's latest chipsets, such as the RS690 and 780G."
Being in C, it is easier to see what the person writing it was doing, compared to assembly.
Consider if you had to do some nasty computation such as finding what address is used for a given row and column on the screen:
(in bad assembly)
mov ax, row
mov bx, col
shl col,#1
xor dx,dx
mul ax,#80
add ax,bx
mov pos,ax
Whereas in C it is:
pos=(row*80)+(col*2);
and much more readable.
as coreboot targets many bioses and platforms, i'd expect portability to become so much more important.
btw, i found an interview with coreboot developer at http://www.heise-online.co.uk/open/The-Open-Source-BIOS-is-Ten-An-interview-with-the-coreboot-developers--/features/112353/2. from there :
"The real accomplishment was to be able to write memory and other early initialization code in C. Which is much easier to write and maintain then assembler. Assembly code is fragile when you change it, especially when you don't have a stack. C is much more robust â" the code is easier to change without breaking everything. This makes coreboot easier to work on, to contribute to and to maintain."
Rich
There may be SOME architecture specific code, even a lot of that can probably be written in C. 99% of the Linux kernel is C and that has to interact with hardware too.
As far as efficiency goes, in the old days it was true that a coder with an intimate knowledge of the architecture could usually hand code more efficient assembly. Modern C compilers however can do a LOT of optimization and generally the resulting code is faster than anything that could be coded by hand, or at least AS fast. Even if it is microscopically slower it is still a LOT easier to use C. Plus if hardware abstraction is done properly even a low level driver back end should be portable for the most part.
Manufacturer BIOS may be written in Assembly since they are A) targeting a specific board which is going to obviously only run that one family of chip and B) probably have a lot of legacy assembly code they would rather not bother to port to C. Neither of those would apply to Coreboot.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
What's more important to you? OSS graphics drivers or OSS BIOS? And by the way, if you need a decent graphics card, you're gonna need ATI or nVidia anyways, Intel doesn't make really high performance cards.
As long as there are slaughterhouses, there will be battlefields.
Doesn't handwritten assembly have the potential to be much faster than assembly compiled from C?
For a piece of software that gets run once per boot, speed is probably not very critical. A typical BIOS completes its run in a couple of seconds.
Using an optimizing C compiler also has a further potential benefit -- given that motherboards specifically target certain CPUs, you can optimize the BIOS code for that CPU family. Not sure how much improvement this will yield, though.
Michel
Fedora Project Contribut
My best guess is there are parts of a BIOS that are tied to the hardware architecture, and there are parts that aren't.
For instance, what if you want to write a BIOS that can read an EXT3 partition?
Actually, a BIOS that can read EXT would be kickass. My bios can only read FAT12 (and maybe FAT32 for a hdd) off the floppy. If I wanted EXT3 (or 2), I'd have to put that stuff in the "kernel" that gets loaded by the boot sector. That kernel, however is on a FAT12 partition =P As for TCP/IP, that would be nice to allow diskless boots. PXE anyone?
Disclaimer: The opinions and actions of the US Gov't are in no way representative of those held by this author or its ci