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."
One word: agnostic. It becomes agnostic in C as opposed to ASM.
Alright, at the risk of further revealing my stupidity--what does this matter? I mean, isn't the BIOS tied to the architecture of the chipset anyway? It's not like I'm going to write a C program that compiles into the BIOS for an x86 chipset and--oh, by the way--thank god I can also compile that down to a PowerPC binary! I don't think that any piece of that integrated circuit is going to be developed in a mirror fashion on a PPC architecture ... or is that common practice?
Doesn't each BIOS target one particular machine assembly language anyway?
My work here is dung.
Doesn't handwritten assembly have the potential to be much faster than assembly compiled from C?
Short answer: no.
Long answer: rarely. Optimizing compilers are so good these days that very few humans would be capable of writing better assembler, and I contend that no humans are capable of maintaining and updating such highly-tuned code.
Embedded assembler makes a lot of sense when you're embedding small snippets inside inner loops of computationally expensive function. Outside that one specific case (and disregarding embedded development on tiny systems), there's not much need to mess with it. Note that need is not the same as reason. Learning assembler is good and valuable on its own, even if there are few practical applications for it. If nothing else, it'll cause you to write better C.
Dewey, what part of this looks like authorities should be involved?
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
Easier to maintain, more portable accross platforms, easier to do more complex stuff, easier to integrate/reuse existing librairies/code, etc.... ?
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.
Turns out that the amount of bugs in a given amount of lines of code is fairly constant, regardless of language. Thus, it takes fewer lines in C code = fewer bugs.
Also, it is extremely rare that the compiler cannot emit more optimal code than what is hand-written - compilers are extremely good at optimizing these days. The more common trend is to provide hints & use intrinsics so that you get all the benefits of writing in C code (type checking, more readable code), but the compiler is better able to generate the assembly you want.
You will almost never write better assembly than what the compiler outputs - remember, the compiler takes a "whole program" approach in that it makes optimizations across a larger section of code so that everything is fast. It is highly unlikely that you will be able to match this - your micro-optimization is more likely to slow things down.
There is actually very little in the Linux kernel that is written in assembly (relatively compared to the amount of C code) - the only time it is, is because it is the only way of doing it to support multiple architectures, not performance. For performance, by far, the kernel code is written in C and relies on working with the compiler people to make sure that the code is optimal.
Also, ATI has open source 2D drivers and just yesterday released specs that should allow for good open source 3D drivers. Sometime in the next 6 months, their graphics cards should support OpenCL, too. ATI is the way to go for open hardware support at the moment.
It's easier to write structured programs in C than assembly.
Well, it's much easier to write anything in C than assembly, but assembly lends itself to small pieces of self-contained code that do one thing only.
The idea is that assembly is only used where is needs to be, because you have to do something that you can't do in C, such as fiddling around with the CPU's internal state. The rest is written as a collection of modules in C. To build a BIOS for a particular board, you just link the required modules together.
That suggests the question "why not write the BIOS in C++, or Java, or whatever". Anything higher-level than C tends to require more complex runtime environments (which are usually written in C), while C requires nothing more than assembly. It's the highest level language commonly available that can run with absolutely no OS support at all.
Booting Linux (and other free operating systems) is relatively simple: They quite robust against quirks in the BIOS, as they're usually not part of the testsuite of the BIOS vendors.
It's also possible to boot Linux (and a smaller set of other free operating systems) without any PCBIOS interface (int 0x13 etc), as they don't rely on that.
Windows does. There has been, for a couple of years, a useful, but very fragile hack called ADLO, which was basically bochsbios ported onto coreboot, to provide the PCBIOS.
Recently, SeaBIOS (a port of bochsbios to C) appeared and was a more stable, more portable choice (across chipsets) in that regard.
So yes, we're proud that we can run the very latest Microsoft system, simply because it's less a given than booting Linux. ;-)
Even VirtualBox (commercially backed, and all) seems to require an update (very likely to its BIOS!) to support Windows 7. "We were first"
Actually, Coreboot is faster. The record from power on to Linux login is, according to their FAQ, 3 seconds. Writing it in C speeds up development compared to writing it in assembly and allows compilers to optimize it.
Spelling/grammar nazis welcome (English is not my first language and I am trying to improve my spelling/grammar)