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."

Comments

What Benefit Does C Have Over Assembly?

[eldavojohn]

On CoreBoot's benefits page, it lists:

Written in C, contains virtually no assembly code

What is the benefit of writing a BIOS in C over assembly code? Is it for transparency? Easier to catch bugs? Does compiling from C to machine assembly protect you from obvious errors in assembly? Is it for reusability of procedures, modules & packages?

Oftentimes I have wished I knew more assembly so I could rewrite often used or expensive procedures to fit the target machine and try to optimize it. I don't know assembly well, however, and therefore don't mess with this. Doesn't handwritten assembly have the potential to be much faster than assembly compiled from C? I thought often run pieces of the Linux kernel were being rewritten into common architecture assembly languages because of this?

I'm confused why mainboard companies don't write their BIOS in C if this is an obvious benefit--or is it that they do and all we ever get to see of it is the assembly that results from it?

Can anyone more knowledgeable in this department answer these questions?

Re:What Benefit Does C Have Over Assembly?

[Anonymous Coward]

One word: agnostic. It becomes agnostic in C as opposed to ASM.

Re:What Benefit Does C Have Over Assembly?

[eldavojohn]

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?

Re:What Benefit Does C Have Over Assembly?

[sprag]

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.

Re:What Benefit Does C Have Over Assembly?

[CompSci101]

I thought C compilers had gotten to the point where C was just a convenient syntax for assembly anymore?

I'm only half-kidding here. I'm sure the main reason is for portability across different chipsets, as well as ease of debugging. But, as I said, I think a lot of current C compilers can generate code that's not appreciably larger than hand-written assembly.

Compiler writers, please educate me otherwise.

C

Re:What Benefit Does C Have Over Assembly?

[Just Some Guy]

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.

Re:What Benefit Does C Have Over Assembly?

[Anonymous Coward]

Compiler writers, please educate me otherwise.

Given your nickname it may have been wise for you to omit your response to this question.

Re:What Benefit Does C Have Over Assembly?

[richlv]

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."

Re:What Benefit Does C Have Over Assembly?

[sprag]

Those should have been multiplies by 160 instead of 80.

Re:What Benefit Does C Have Over Assembly?

[.tom.]

Easier to maintain, more portable accross platforms, easier to do more complex stuff, easier to integrate/reuse existing librairies/code, etc.... ?

Re:What Benefit Does C Have Over Assembly?

[palegray.net]

Given that 101 indicates entry-level courses, the GP post isn't really that surprising.

Re:What Benefit Does C Have Over Assembly?

[Vellmont]

what does this matter? I mean, isn't the BIOS tied to the architecture of the chipset anyway?

I'm not a BIOS writer, but I am a software developer.

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? Or has a TCP/IP stack in it? These might be bad examples, but I can certainly see that there's generic things to be done that aren't necessarily tied to a particular processor.

Re:What Benefit Does C Have Over Assembly?

[Anonymous Coward]

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.

Re:What Benefit Does C Have Over Assembly?

[Anonymous Coward]

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.

Re:What Benefit Does C Have Over Assembly?

[Thaelon]

What is the benefit of writing a BIOS in C over assembly code?

Maintainability. Further, it's fairly common knowledge that C compilers these days can often produce code that is more efficient than hand written assembly, so it's a no-brainer to write C instead.

Re:What Benefit Does C Have Over Assembly?

[trailerparkcassanova]

Only very small sections of Coreboot are specific to a particular architecture. The rest can be reused without modifying source code.

 

Re:What Benefit Does C Have Over Assembly?

[Anonymous Coward]

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.

Actually, in my experience it's more about the modern CPU than the modern compiler. If you look at the output from modern compilers, there's some truly awful code in there. gcc can be particularly awful (Intel and MSVC appear to be substantially better).

But tricks like hand-reordering matter little when you've got a superscalar CPU with a 20-instruction reorder window.

I suspect it would be a lot more obvious on platforms like the Atom or the consoles, which are all using in-order cores.

That doesn't mean that the technology doesn't exist to make the compilers better, but if it does, nobody's bothering because it isn't making a difference (on most x86, at least).

Re:What Benefit Does C Have Over Assembly?

[moteyalpha]

Those should have been multiplies by 160 instead of 80.

I would have thought that immediately ( 160 ) since I did so much assembly with CGA, however I may be even older and some of the displays were 40 characters wide, so 80 would be correct for that. On the issues of coreboot, that is fantastic and I want it for my machine now. I want instant boot to linux and ext4 for my next upgrade. On the other issue of _asm_ as faster, I bet I could make some of it faster, but gcc is way good anymore and I often objdump my "c" code to look at the assembly and the people who write the compiler are virtually magicians with that code. I have tried competing with the compiler and it is a waste of time for most things and unless I was doing firmware or a device driver, I wouldn't even consider assembly. As far as the code, the one thing I wouldn't do is a "mul" just for the cycle cost, I would combine shifts and adds to get (16x+64x).

Re:What Benefit Does C Have Over Assembly?

[salimma]

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.

Re:What Benefit Does C Have Over Assembly?

[Anonymous Coward]

You're doing it wrong!

Short answer: no.

Long answer: NOOOOOOOOOOOOOOOOOOOOOOOOOOOOO! (courtesy of George Lucas acting academy)

Re:What Benefit Does C Have Over Assembly?

[slyn]

That doesn't mean that the technology doesn't exist to make the compilers better, but if it does, nobody's bothering because it isn't making a difference (on most x86, at least).

The LLVM + Clang project would probably disagree with you.

Re:What Benefit Does C Have Over Assembly?

[Hordeking]

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?

Re:What Benefit Does C Have Over Assembly?

[Anonymous Coward]

Is it for transparency? Easier to catch bugs? Does compiling from C to machine assembly protect you from obvious errors in assembly? Is it for reusability of procedures, modules & packages?

Yes.

Re:What Benefit Does C Have Over Assembly?

[agbinfo]

Doesn't handwritten assembly have the potential to be much faster than assembly compiled from C?

Short answer: no.

Long answer: ...

I don't know how good compilers have become but I've had to optimize generated code (for space and speed) a long time ago.

To do this, I would write the best possible code in C first, then compile it and then optimize the generated assembler code.

My point is that if you already start with the best code the compiler will provide, you can only improve from there.

Also, in some situations, looking at the generated assembler code helped identify clues as to how writing the original C code could result in better performance.

This was a long time ago, for an embedded application with very limited CPU and memory. I haven't had to do that since.

Re:What Benefit Does C Have Over Assembly?

[FrankSchwab]

Writing in 'C' is an order of magnitude faster than writing in assembler; if you're building a system with 10 man-years of coding in it, that becomes really, really important.

Imagine writing a host-side USB stack in assembler; a BIOS has to have that. Or writing an Ethernet driver and TCP/IP stack in assembler. Or any of the other large subsystems of a BIOS; the task would be daunting to me, a 20 year veteran of embedded systems (yes, my 'C' and Assembly mojo is strong).

Assembler has proven its worth when sprinkled through embedded systems. When profiling finds the routines that are bottlenecks for time-critical functions, a good assembly programmer can often speed up the 'C' code by a factor of 2 to 10. But, this generally involves very small chunks of code - 10 to 50 lines of assembly.

In most real systems, the vast majority of the code is executed rarely, and rarely has a performance impact. For example, on a modern dual-core, 2 GHz processor with a GB of RAM, the code used to the display the BIOS setup UI and handle user input will execute faster than human percepption in almost any language you could imagine (say, a PERL interpreter written in VB which generates interpreted LISP). There is no reason in the world to try to optimize performance here. Even in things like Disk I/O, the BIOS' job is mostly to boot the OS, then get the hell out of the way.

Re:What Benefit Does C Have Over Assembly?

[clone53421]

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.

Ahh, I envision the "God" language...

Do_What_I_Want();

Re:What Benefit Does C Have Over Assembly?

[CarpetShark]

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?

No, not really. Small parts of a standard bios are, but if you notice BIOS version numbers for say, Award or AMI, you'll see that they don't actually vary much by motherboard; just by manufacturing date. There are also major bits that stay the same -- PCI drivers, for instance, even across different architectures like x86, AMD64, PowerPC, Alpha, etc.

Essentially, the BIOS stays the same, with a few changes for each chipset. This applies even more so, with CoreBoot, which is intended to be very open and reuseable across many chipsets, manufacturers, and even platforms.

Re:What Benefit Does C Have Over Assembly?

[clone53421]

Never much heard of BIOS interrupts, eh?

Re:What Benefit Does C Have Over Assembly?

[hesaigo999ca]

That is exactly what this is for, think about the new chipsets that want to boot mini mode, to offer web access without booting the OS....this stems from such tasks, as now the C library that could be referenced was already tested and made for such things, although now I believe the bios to be possibly more open to viruses.

Re:What Benefit Does C Have Over Assembly?

[trjonescp]

Turns out that the amount of bugs in a given amount of lines of code is fairly constant, regardless of language.

I'm not sure if this applies to Perl. It's probably one of the few languages, where you can have about 10 different bugs in one single line of code.

Re:What Benefit Does C Have Over Assembly?

[jthill]

All BIOSes are supposed to do the same things; it's the point of having one. All the hardware they run on is made to support doing those things. The functions you are required to perform differently on different hardware are very, very few.

The functions you could perform differently for a measurable speed boost don't make nearly enough difference to outweigh the benefits of implementing only the required parts and then typing "make" to get your shiny new hardware working.

You want assembly when some human is waiting long enough for your results to take them out of the zone, you already have the best algorithm to produce those results, nobody has already built a hand-tuned library to do it and your compiler can't be made to understand.

You don't actually need assembly until all of the above apply and the results are late enough to cause damage.

Re:What Benefit Does C Have Over Assembly?

[sco01]

Speed is essential. Turning on a machine typically means that you want to use said machine for something. Most of the computers i regularly use takes between 40 and 90 seconds to boot and that is the same time it took 15 years ago. It just doesn't make sense. I think most people agree that a clean boot into a *usable* state really shouldn't take more than 5 to 10 seconds in total. Having a bios that consumes even as little as two seconds of that time doesn't make sense.

Re:What Benefit Does C Have Over Assembly?

[clone53421]

My wife is proficient in that language. In fact, she's improved on it:

>:(

Now if I could just write a better interpreter...

Re:What Benefit Does C Have Over Assembly?

[billcopc]

A BIOS actually does not have that much to do, by definition. The problem is that PC architecture is crusty and hasn't evolved all that much since the 80's. It should not be the BIOS' job to handle USB/Ethernet or any other hardware niggling, such feats belong in the hardware's own controller. If each component did its job and presented a uniform, reliable interface to the BIOS, we could be writing very simple BIOSes that glue it all together and give us a simple UI to configure the pre-boot stage. That's really all a modern operating system needs.

Re:What Benefit Does C Have Over Assembly?

[Kadin2048]

As for TCP/IP, that would be nice to allow diskless boots. PXE anyone?

Not only that, but a minimal TCP/IP stack in the BIOS would remove much of the reason for purchasing expensive remote-management add-in cards (and sacrificing PCI slots as a result) in order to perform hard reboots and view the boot console over a network. (Those cards are in themselves an alternative to even more expensive out-of-band management systems, using either the serial port or proprietary hardware interfaces.)

Although there would be some obvious security concerns with such a system -- you wouldn't want to enable it by default on non-headless systems, clearly -- it would be a pretty neat feature and would go a long way towards making commodity servers (built up from semi-generic components, like Rackspace's) feature competitive with the big names. And it'd be nice, just in general, to get a standardized approach to true headless operation that was vendor-agnostic and didn't require the purchase of additional addon parts.

Re:What Benefit Does C Have Over Assembly?

[dargaud]

I've had to optimize generated code (for space and speed) a long time ago

I did too. But how can you write assembler for a 31 stage pipeline by hand ? Or out of order instructions ? I'm pretty sure that's completely impossible, unless you insert 30 NOPs between each instructions, and by that time it's far from being optimized anymore !

Re:What Benefit Does C Have Over Assembly?

[Anonymous Coward]

The mul is a waste. Please learn how to optimize before you brag about your poor assembly skills.

(row*80) = (row*16) + (row*64) = row

or

mov ax, row
mov bx, col
mov cx, ax
shl ax, #6
shl cx, #4
shl bx, #1
add ax, cx
add ax, bx
mov pos, ax

FWIW both ia-32 and x86_64 are a fucking piece of shit as an ISA.

Glass

Re:What Benefit Does C Have Over Assembly?

[delphi125]

You have some insight, but not into how compilers work, nor how good programmers improve code. It has been a very long time since I wrote any C, but it was writing much of a (non-optimizing) C compiler. It must be said though that one reason I didn't finish it was looking at all the cool ways to optimise :)

If I were writing/designing a BIOS (which I must admit I am glad I am not) I would also pick C as the "best" language for the job. I'd then write the cleanest possible implementation of the design, using assembler only where absolutely necessary - which would likely be for platform dependent bits in >90% of the cases anyway.

The code need not be fast (as long as it performs), and it need not be tiny. But it needs to be 100% accurate, and sufficiently well documented to be easily readable.

By not using assembler, developer time until now has been relatively low. No premature optimisation has taken place. The next step is profiling, for which a benchmark suite is set up. This suite will ALSO be used to test that alternative implementations return the same results!

In parallel, the BIOS would be used in Virtual Machines; no ROMs need to be created, to get a good picture of how often various functions are called.

On the basis of this, it can be decided where to focus optimisation efforts. The historical target used to be primarily to get size down to 64k, since the 8088/6 booted to F000:FFF0. Assuming this is still a primary issue on many platforms, the first point of call for optimisation is to reduce any "big" functions - like those which use large (lookup) tables as their easiest/cleanest implementation (an obvious example might be the ascii characters in raster format).

Simply writing multiple versions of a routine in a HL language and then profiling may be enough to achieve the desired performance level (IIRC Jon Bentley wrote on this as one of his "Programming Pearls"), but even then an improvement may be possible by going right down to the silicon.

Admittedly it takes people like John Carmack and Michael Abrash to get everything out of it, but if everybody has a week to optimise a 20 line C "inner loop" function for speed, those who can read the produced assembler will do better than those who cannot, and those who can edit it will do even better.

Of course, over 20,000 lines of code, the C expert will manage better in a month, since rather than fixing 4 functions to perfection, they may be fixing 20 to 95%.

One final thing to note: optimising C compilers are known to have occasional bugs in their optimisation. When you are going to eventually write something to a (flash) ROM responsible for booting your computer, that is not an acceptable risk. That means that you don't want to rely purely on an optimising compiler to do your work for you.

Re:What Benefit Does C Have Over Assembly?

[forkazoo]

I did too. But how can you write assembler for a 31 stage pipeline by hand ? Or out of order instructions ? I'm pretty sure that's completely impossible, unless you insert 30 NOPs between each instructions, and by that time it's far from being optimized anymore !

Out of order execution is something to compensate for suboptimal instruction ordering, so I'm not sure why you think it would make it harder to write assembly for an OOO chip. You just worry slightly less about sequencing. As for deep pipelines, you really just have to be careful with conditionals and load/store to memory. I'm oversimplifying a bit, and I think it's almost never useful to write much in assembly these days, but these new chip features don't make it any harder to write ASM. They just make it hard to beat the compiler by doing it.

Re:What Benefit Does C Have Over Assembly?

[master_p]

C++ has exactly the same run-time environment as C.

Re:What Benefit Does C Have Over Assembly?

[fjhb]

Actually, a BIOS that can read EXT would be kickass.

It already exists, it's called GRUB ;-)

You can combine GRUB with coreboot and install that to your board's flash memory, then instruct GRUB to do whatever you want.

Re:What Benefit Does C Have Over Assembly?

[amRadioHed]

True, but given his 6 digit UID, if he's still in 101 level classes there's a problem.

Re:What Benefit Does C Have Over Assembly?

[ChunderDownunder]

But why use C when you could develop a 'BIOS' in Forth? :)

Re:What Benefit Does C Have Over Assembly?

[doshell]

Oftentimes I have wished I knew more assembly so I could rewrite often used or expensive procedures to fit the target machine and try to optimize it. I don't know assembly well, however, and therefore don't mess with this. Doesn't handwritten assembly have the potential to be much faster than assembly compiled from C? I thought often run pieces of the Linux kernel were being rewritten into common architecture assembly languages because of this?

I'd say speed is hardly a concern for BIOS code, which is run only during the booting process. AFAIK, modern operating systems have their own hardware access routines that bypass the BIOS.

Thus one can take advantage of C's readability and maintainability (as compared to assembly) without worrying with the performance penalty. And even then, as others suggested in this thread, it is not entirely clear that the compiled code would be less efficient than the hand-assembled one...

Re:What Benefit Does C Have Over Assembly?

[Anonymous Coward]

It's easier to write structured programs in C than assembly.

Not if the assembler has good macro support or other high level language functionality. If the assembly in question is a Forth dialect, then it's much easier to write structured programs in Forth then in C.

Well, it's much easier to write anything in C than assembly

Not if the assembler has good macro support or other high level language functionality. If the assembly in question is a Forth dialect, then it's much easier to write large and reusable systems then in C.

but assembly lends itself to small pieces of self-contained code that do one thing only.

Yes, the ease and low cost of creating Forth words compared to creating C functions, it is one of its biggest selling points. You can do this in some other assembly to, if there is good support for high level programming.

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.

It's like Forth, but with two very different grammars.

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.

Forths are higher level then C, as is some other assembly. C usually require a more complex runtime environment, at least if it loads dynamic libraries.

Re:What Benefit Does C Have Over Assembly?

[ChunderDownunder]

Having a bios that consumes even as little as two seconds of that time doesn't make sense.
Sure, but if writing a BIOS in in C/C++ which may add, say, 5-10% to that time, is it discernible?
I'd favour higher level abstractions, CPU independence and maintainability over theoretical performance gains.
Hint: Use a profiler to diagnose where the actual bottlenecks lie. It could be algorithmic rather than language-dependent, in which case performance will suck in any language. :)

Re:What Benefit Does C Have Over Assembly?

[CarpetShark]

The mul is a waste. Please learn how to optimize before you brag about your poor assembly skills.

Which is yet another reason why assembly is better left to a compiler these days.

Re:What Benefit Does C Have Over Assembly?

[nategoose]

As an embedded programmer who does mixed C and assembly programming the most difficult part of assembly is keeping track of more than a very few variables, so register allocation alone is enough to warrant using a compiler.
That being said, compilers sometimes do terribly stupid things.

Re:What Benefit Does C Have Over Assembly?

[cr_nucleus]

What is the benefit of writing a BIOS in C over assembly code?

Oh man, that is a weird question.

I for one like to think that programming is a good way to make you computational life easier.
Using a high level language is not too bad at making that happen.
Using assembly will actualy make my life a lot more complicated than it should be.

It might be because i'm not subject to this strange neurosis that make people want to control the exact instructions that go into the registers of their cpus. But somehow, i like it this way.

I'm not even gonna go on the field of performance, because many many other posts are already on the subject.

Do yourself a favor, don't micromanage (and i'm not just talking about code here), it'll make your life easier.

Re:What Benefit Does C Have Over Assembly?

[Hucko]

Forth is dying, Netcraft confirms it.

Re:What Benefit Does C Have Over Assembly?

[Tweenk]

Not exactly - you need a support library (usually written in C...) which will do things like virtual method lookups and exception handling for you.

Re:What Benefit Does C Have Over Assembly?

[Lost Race]

Doesn't handwritten assembly have the potential to be much faster than assembly compiled from C?

Short answer: no.

Correct answer: Yes.

Useful answer: If you have to ask, don't bother trying it in any real application. The keyword above is "potential", which you almost certainly won't be able to realize unless you're already a very high-level wizard of low-level programming.

(It also depends on what you mean by "much faster". You're not going to get 10x but you could get 2x.)

Re:What Benefit Does C Have Over Assembly?

[BikeHelmet]

The benefit is the same one as using Windows rather than DOS, or using Python rather than C++.

Easier management of more complex things to use more of the available resources.

It results in:
-Faster dev time.
-Easier to spot errors.
-Easier to spot performance snags. (like waiting for a device to initialize - for 5 seconds - without doing anything else)

Compilers are less falliable than people, especially when it comes to complex optimization like this must involve.

Re:What Benefit Does C Have Over Assembly?

[Fred_A]

One word: agnostic. It becomes agnostic in C as opposed to ASM.

Shouldn't it be written in Python then ? Or in Java ?

Re:What Benefit Does C Have Over Assembly?

[Workaphobia]

> Doesn't handwritten assembly have the potential to be much faster than assembly compiled from C?

Meh, that's overstated. My boss, an engineer who knows assembly whereas I do not, once commented to me how impressed he was that gcc was able to compile C code into something that was almost as good as hand crafted assembly.

Of course low level operations like initializing the DRAM controller should probably be done manually, but that kind of code is minimal. In fact, they have a special compiler that only puts variables in CPU registers instead of memory so even that part can be in C.

As far as efficiency goes, the CPU is way faster than any other component of the computer, so optimizing the number of cycles you take is pointless until you demonstrate a need to do so.

Re:What Benefit Does C Have Over Assembly?

[Fred_A]

I don't know how good compilers have become [ ... ]

Better.

but I've had to optimize generated code (for space and speed) a long time ago.

Well, that's why then.

And for those who diss gcc, it does support a bit more architectures :
        * Alpha
        * ARM
        * Atmel AVR
        * Blackfin
        * HC12
        * H8/300
        * IA-32 (x86)
        * x86-64
        * IA-64
        * Motorola 68000
        * MIPS
        * PA-RISC
        * PDP-11
        * PowerPC
        * R8C/M16C/M32C
        * SPU
        * System/390/zSeries
        * SuperH
        * SPARC
        * VAX

(list taken from Wikipedia without further checking) than the other super optimized compilers. So while I expect a bit more work goes into x86 and al., the rest of them are still active (not to mention all the other architectures maintained on a parallel tree).

So while it's not great, it's still not too bad.

Re:What Benefit Does C Have Over Assembly?

[salimma]

Touché. What's the percentage of uptime spent in BIOS interrupt handlers, though? Looking at the list of interrupts, most of the tasks seem optimizable by any decent compiler.

Re:What Benefit Does C Have Over Assembly?

[Dolda2000]

Actually, a BIOS that can read EXT would be kickass.

FYI, Coreboot doesn't do that, but many of the payloads that you put with it in ROM do. For example, I use Coreboot with FILO on my server. FILO is a port of GRUB that uses no legacy BIOS code (but rather accesses disk hardware directly). It is quite nice indeed to have a good bootloader in ROM.

Re:What Benefit Does C Have Over Assembly?

[userw014]

A skilled assembly language programmer can significantly reduce the byte size of the program over C, which was very important in the days when boot ROM sizes were small (8K or less.)
C is more maintainable and portable.
Knowing and choosing appropriate algorithms is more likely to gain you speed than coding in assembler, although I won't deny that if you need every last bit of speed from your CPU, you'll end up coding in assembler. However, if you need that much speed, you're really coding against the exact hardware too - I/O controllers, graphics, memory system, even CPU model.
Any company writing most of their BIOS in C is doing it for legacy reasons - changing the code base over from assembly to C isn't worth the effort, especially if the existing code base is reliable and well tested.

Re:What Benefit Does C Have Over Assembly?

[Anonymous Coward]

I have had similar experiences. This saying about unbeatable optimizing compilers is 20 years old, at least. But I have beaten the pants of the optimizer every single time I tried, without much effort.
The fact is that a human is and will be much better at optimizing a single function than a compiler, for a single simple reason: the compiler has to be consistent with the semantics of the source code as written.

Re:What Benefit Does C Have Over Assembly?

[InfiniteLoopCounter]

Your optimization may not be best either.

Try,

mov ax, row

shl ax, #4

mov bx, ax

shl bx, #2

add ax, bx

mov bx, col

shl bx, #1

add ax, bx

mov pos, ax

This will save you using the "cx" variable, register, or whatever it is. This means that the value of "cx" does not have to be separately saved and restored.

In addition, if "#x" is a register, then the hard drive calls can be spaced out more and "ax" may be processed further whilst this call is being made.

Of course this response is written in true /. style as I haven't actually programmed in assembler that looks like this before.

Re:What Benefit Does C Have Over Assembly?

[Anonymous Coward]

cf. http://www.coreboot.org/FILO

Re:What Benefit Does C Have Over Assembly?

[khanyisa]

You can't say "thank God" - it's agnostic kaching!

Re:What Benefit Does C Have Over Assembly?

[jd]

Then you'd use OpenBIOS. CoreBoot is just a bootstrap, anyway, it's not a full BIOS replacement. Which is fine, as very few modern OS' use the BIOS for anything any more. Of course, if you're sick, you can always use CoreBoot to boot OpenBIOS to boot CoreBoot to boot Linux.

Re:What Benefit Does C Have Over Assembly?

[afidel]

When you are going to eventually write something to a (flash) ROM responsible for booting your computer, that is not an acceptable risk.

Sure it is, modern motherboards have one or more of the following features: fallback ROM (non-flash), secondary flash ROM location, ROM recovery method. Basically on a decent modern computer it's not really possible to brick them, there's always a way to get back to a working ROM image.

Re:What Benefit Does C Have Over Assembly?

[Hordeking]

It already exists, it's called GRUB ;-)

Any chance you know where I can find a GOOD tutorial to installing and using Grub with Slackware? I'm on Lilo right now, and while I don't mind Lilo, I wouldn't mind trying out Grub.

Re:What Benefit Does C Have Over Assembly?

[PCM2]

My point is that if you already start with the best code the compiler will provide, you can only improve from there.

Oh no, trust me, you can definitely screw it up worse, too.

This is awesome

[kcbanner]

I'd really like to see the buggy vendor bioses get the boot and be replaced by this. The BIOS on my motherboard has all sorts of quirks, like missing one stick of my ram during detection randomly, to really laggy page switches. Windows support is what CoreBoot needs to get accepted.

Re:This is awesome

[richlv]

some fully supported desktop mobos is what coreboot needs ;)
if a mobo was fully supported, that would be a huge plus when i'd choose.
we've seen a lot of issues where even if a bios isn't massively buggy by itself, future development of hardware leaves a lot to be desired, but vendor has dropped any support. this includes servers by ibm, hp, desktop boards...
problems have been various during the years (and i really mean only the problems that can be fixed in bios) - larger disk drive support, larger memory support, proper booting from hdd (for example, ibm netfinity 5000 stops booting when an ide drive is attached), proper booting from all cdroms, usb booting...
so, amd, if your products will be fully supported by - or even shipped with - coreboot before everybody else, it is very likely that my future purchases will go to you :)

Re:This is awesome

[hedwards]

Well, there's two issues there. One is that Vendors haven't cared a lot about getting it right, and two that the BIOS itself as a specification is pretty limited.

Replacing the BIOS with EFI or something more up to date and extensible could potentially solve the second problem.

But, ultimately vendors are lazy and tend not to bother doing it right. More often than not they just use a stock BIOS which is itself buggy. Really it's probably the BIOS manufacturers that ought to be taken to task for screwing it up.

Re:This is awesome

[palegray.net]

More often than not they just use a stock BIOS which is itself buggy.

So let's start encouraging manufacturers to start using Coreboot as the "stock" option instead.

Re:This is awesome

[theJML]

Wow. Sucks to be your board. I don't think I've ever had any big problems with BIOSes on desktop boards (or even on server boards passed the "a few updates after public release" point. My current setup doesn't have ANY that I know of, or care about... and newer versions of the BIOS simply add support for newer procs/stepping.

Now on server boards, I've only really had problems with boards from Tyan. Though mostly it was because they mislabeled things or couldn't spell ("CPU1 FAN DOESN'T DETECTED" comes to mind, when there's only one CPU in the system. luckily it wasn't a fatal error.) Everything would work once they got their boards to a certian code rev, but that was really only something we saw where I worked because we got pre-pre-pre-pre-production boards with wires running along the board for traces they missed/forgot) Usually everything is ironed out before they go public. At least IMHO. And I've worked with a few hundred boards if not more.

So then I'd like to know how stable these things are for server & 24/7 environments. Is this the kinda thing I'd want to put on that pre-pre-pre-release board to make it work without having to wait for the vendor to udpate their stuff? Sounds kinda iffy to me.

Re:This is awesome

[dk90406]

So with windows support, CoreBoot can be accepted? Leads to the question: Is anyone here using it now?

What is your experience.

I would be terrified by the risk of harming my MOBO, but I may be the only one so timid.

Re:This is awesome

[Wonko the Sane]

I don't think I've ever had any big problems with BIOSes on desktop boards

You've never run across the "Keyboard not found. Press F1 to continue booting" motherboards before?

Re:This is awesome

[Chabo]

Read this:

http://www.anandtech.com/mb/showdoc.aspx?i=3471

Re:This is awesome

[makeajazznoisehere]

Missing one stick of your RAM randomly...

Sounds like a hardware problem to me. :/

Re:This is awesome

[fm6]

Don't you just hate it that software has no sense of irony?

Re:This is awesome

[jd]

Each time I do a Coreboot/LinuxBIOS announcement on Freshmeat, I usually add a whole bunch of chipsets and a fair dollop of motherboards. I don't, as a rule, state the level of completeness, simply because there's barely enough space to list just the components.

Having said that, assume the web page is out-of-date when it comes to fully-supported motherboards. I know for a fact that I've seen a lot more motherboards get listed as complete in the changelog than are listed on the website, even though I started tracking those changes relatively recently and they'd plenty of mobos complete even then.

One of the important things to remember about LinuxBIOS/Coreboot (the new name doesn't have the same ring to it, for me) is that it's a highly modular bootstrap, so it has a high probability of working on just about anything, so long as the components you need are listed and ready. I feel certain that a few good QA guys with a bit of backing from mobo suppliers could pre-qualify a huge number of possible configurations. The developers, as with most projects, don't have time to validate, debug and extend, and their choice has (wisely) been to put a lot of emphasis on the debugging and extending.

Of course, Coreboot isn't even the only player in the game. OpenBIOS is out there. That project is evolving a lot more slowly, and seems to have suffered bit-rot on the Forth engine, but that's a damn good piece of code and it deserves much more attention than it is getting.

Intel also Open Sourced the Tiano BIOS code, but as far as I know, the sum total of interest in that has been zero. I've not seen a single Open Source project use it, I don't recall seeing Intel ever release a patch for it. That's a pity, as there's a lot of interesting code there with a lot of interesting ideas. I'd like to see something done with that code, or at the very least an assessment of what is there.

Re:This is awesome

[jd]

Reprogramming the BIOS is not a good idea unless you've some method of recovery. This is true whether you are timid or brave. CoreBoot goes through a lot of bugfixes each day, every day, and there's no telling that tomorrow's patch might relate to a problem with your hardware.

If there's a way to flash your BIOS externally, such as via JTAG, your number one concern should be to get the hardware you need. Dump the contents of the flash to some backup storage (that you can access without a working flash), then flash the BIOS using the CoreBoot/LinuxBIOS tools, then if there's a problem, restore the known-working flash image.

This is perfectly safe to do*. Some cards I've worked with needed me to mess around with installing BIOS images.

*World War III won't start, the universe won't fall into a supermassive black hole, and the sky won't fall more than 3000 feet. Anything else is subject to whatever bugs you just know the motherboard and the programming software have.

Re:This is awesome

[LoRdTAW]

Its not AMD's decision to say whether or not Coreboot is used in place of AMI/Award/Phoenix/etc but motherboard makers themselves. Coreboot has to be stable and fully support all the chipsets, CPU's, hardware and operating systems attached to that board. And on top of that it has to have a full tool kit to enable the maker to easily customize the bios for their exact board configuration.

But I will add that I too have been eagerly awaiting a free open source BIOS that will ship on mainstream boards. Problems can be fixed by the community instead of waiting for BIOS/board makers to issue patches (and we all know how long that can take). Fun part is I have seen Coreboot running TinyX and Busybox in a 2MB bios flash chip. Would be nice to have a bios that can run memtest86 right out of the box to ensure the memory is working without the need for boot devices. And it could be even better if they give you disk check utilities, ghosting tools and even user addable utilities right on the bios. It could allow extra space so you could install clustering node software so you remove the need for a boot device and OS. It could even run software right off a disk or flash drive instead of installing to the flash chip keeping the flash chip write protected. Hell even grub or another boot loader can be right on the bios instead of the disk.

Re:This is awesome

[ffflala]

some fully supported desktop mobos is what coreboot needs ;)
if a mobo was fully supported, that would be a huge plus when i'd choose.

Here, here. This project's interia will depend on mobo support.

I chose my last desktop mobo specifically b/c it was a LinuxBIOS 'compatible' board... compatible in the sense that a fairly skilled hardware hack is required.

http://www.coreboot.org/GIGABYTE_GA-M57SLI-S4_Build_Tutorial

The board is Gigabyte's GA-M57SLI-S4; its nForce 570 chipset is aging, but if you have an AMD2 CPU and some DDR2 lying around it's still on the market for under $100.

Re:This is awesome

[jd]

That might be a tough sell. However, if you started by targeting motherboards that are going to be used for embedded systems (eg: PC104s), where memory is an absolute premium, and then persuading those same manufacturers that they can cut costs by using the same software on their other lines, rather than having to license something, then you're in with a chance.

Alternatively, if there was a Ubuntu-derivative that auto-sensed if the motherboard was 100% compatible and offered an upload into flash as an install option, even if nobody uses the option, the added inches in the press and the added enquiries by customers will put pressure on motherboard manufacturers to consider if it might not be a good PR move on their part.

Re:This is awesome

[jd]

I tried giving a computer some irony filings before. It seemed to sense them just fine.

Re:This is awesome

[fm6]

What? You sued your own computer? This litigation epidemic is really out of hand!

Yes, but will it run...

[tygerstripes]

Oh never mind.

Re:Yes, but will it run...

[Anonymous Coward]

Ninnle Linux runs just fine on it.

Ignorance

[Thanshin]

Excuse my ignorance but is it already possible to have a fully working computer that doesn't perform a single unknown operation?

Help! I'm conflicted!

[Kludge]

I've been buying Intel because they support their 3D graphics with open source code really well under Linux, unlike AMD/ATI.
But Coreboot says support AMD, because AMD helps them run on AMD chipsets, unlike Intel.

Help!

Re:Help! I'm conflicted!

[KasperMeerts]

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.

Re:Help! I'm conflicted!

[77Punker]

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.

Re:Help! I'm conflicted!

[SanityInAnarchy]

Wait for Larrabee, which should be available as a discrete card. Buy AMD motherboards and CPUs, and Intel video cards.

Or wait longer, for the open source ATI drivers to start working -- most of the specs have been released.

Re:Help! I'm conflicted!

[jgtg32a]

I have an ATI 4850, it doesn't run all that well in Linux but I can guarantee that it will still run better than whatever Intel is trying to pass off as a graphic card.

Re:Help! I'm conflicted!

[Haiyadragon]

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.

Maybe when those good open source 3D drivers are released. Somehow I think it's going to take a while. Right now, you'd be lucky to get either composite or xvideo working, nevermind both.

Right now, NVidia is the way to go. Their drivers actually work.

Re:Help! I'm conflicted!

[77Punker]

ATI's binary drivers actually work, too. They had problems in the past, but I've recently bought a new card from ATI to replace my Nvidia card and I can say easily that they both work very well with the binary drivers.

That's beside the point, though. We're talking about open drivers.

Re:Help! I'm conflicted!

[RiotingPacifist]

I beg to differ, if you want a stable system capable of running well, consuming power, suspending, doing composting, flash, etc, intel are the only choice. Unless you play recent games intel really kick the pants out of ati/nividia for stability (the same can be said for windows drivers tbh)

Most of the BIOS is probably generic

[Giant Electronic Bra]

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.

Re:Most of the BIOS is probably generic

[Tweenk]

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.

1. You still have to know what C code will compile to the most efficient assembly representation. For example, computing a sum of 1 million floats will have different performance when you add to a single variable in a loop, and when you use 16 variables as subtotals and add those in the last step (depending on the number of execution units in the CPU it can be up to 16 times faster).
2. Compilers are usually not clever enough to use conditional moves and other conditional instructions that avoid branching. This is important, since branching overhead is rather large in modern deeply pipelined processors.
3. It's actually quite easy to beat a compiler when you know what you're doing. I'm not an experienced assembly programmer by any measure and I did this a few times. The reason few people use assembly today is that the code is then no longer portable, and it's much easier to introduce bugs.

Re:Most of the BIOS is probably generic

[afidel]

In your first example a modern compiler will do loop unrolling and will automatically vectorize the instruction so it will run faster then even your 16 subtotals since you have multiple SIMD units and each is more powerful then the ALU.

Limited chipset support

[Anonymous Coward]

LinuxBIOS/CoreBoot is fantastic for embedded work, but no one has been performing ports to hardware with Intel chipsets.

Re:first post

[Anonymous Coward]

Idiot! It should be "One small post for a troll."

The original misquote only worked because of the double meaning for man. Stupid troll.

Boot Windows 7? So what?

[Manip]

Why is it "news" that it can launch Windows 7?

I guess what I am struggling to understand is why the news isn't - "CoreBoot can now boot x86 operating systems."

What is special about Windows 7 that made it harder to boot / run under CoreBoot as opposed to Windows XP or 2003 Server?

Should a bios even be able to tell the difference between booting Linux and Window's bootloaders?

Re:Boot Windows 7? So what?

[Anonymous Coward]

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" ;-)

Re:Boot Windows 7? So what?

[Anonymous Coward]

Given that the computer market is such a horrible mess of drivers and incompatibility, i would think that, yes, a BIOS really would need to know how to load a specific OS because the bootloaders are almost certainly different.

Correct me if i am wrong, never really looked into BIOS related things much.

Re:Boot Windows 7? So what?

[TheThiefMaster]

I've run Windows 7 in VirtualBox. I told it it was "Vista", because it didn't know about 7 yet.

No update needed.

Re:Boot Windows 7? So what?

[RiotingPacifist]

Thats a shame, i naively assumed that this meant windows 7 was no longer relying on the bios to report system information.

Re:Boot Windows 7? So what?

[dargaud]

I had to write a bootloader for an embedded PPC board recently (and the associate Linux kernel). I was really surprised at how easy it was. Basically 3 lines of C: main(), an almost fake function using a static pointer and a return !

Re:Boot Windows 7? So what?

[spandex_panda]

Virtualbox booted windows 7 fine for me. I called it Vista and it was good. Needed the Vista network drivers and now I have it running good in a VM. Now... I wonder if I can change the date in the machine so it lasts longer than July/August and then can replace my aging XP VM for windows apps...

Yay! Let's trade speed for dumb.

[mandark1967]

In our ever-increasing need to "dumb down" all things related to computers, this will only result in more bloated, slow code.

*sigh*

I for one look forward to our "21 freaking seconds to access BIOS?!" overlords.

Re:Yay! Let's trade speed for dumb.

[LingNoi]

Why do you assume it to be slower? I would rather the compiler optimise the assembly then a human which tends to make mistakes.

It's true that human optimisation of assembly used to be faster but these days and on multiple different processors, I very much doubt it.

Re:Yay! Let's trade speed for dumb.

[TheThiefMaster]

Actually you get massive speed gains if you use SSE assembly (and your app benefits from SSE) because the compiler often doesn't produce it willingly.

SSE-intrisinc functions are much better though.

Re:Yay! Let's trade speed for dumb.

[Hordeking]

In our ever-increasing need to "dumb down" all things related to computers, this will only result in more bloated, slow code.

*sigh*

I for one look forward to our "21 freaking seconds to access BIOS?!" overlords.

I'm sure there are a lot of #ifdefs in there for specific things. A lot of the code is probably generic enough that asm isn't required (variables, structures, control structures such as if/while, etc)

Re:Yay! Let's trade speed for dumb.

[j-pimp]

Actually you get massive speed gains if you use SSE assembly (and your app benefits from SSE) because the compiler often doesn't produce it willingly.

SSE-intrisinc functions are much better though.

I'm not sure what the SSE instructions are, I have never coded assembly outside of one class in college. However, maybe the key is to fix the compiler to produce the proper SSE code. If a human can produce better assembly than a compiler, he can probably teach the compiler to do the same.

They probably need to give compiler specific hint flags therefore marrying the build to a specific compiler. This still produces code that can be changed quickly and is free of the errors that the particular automations prevent. However, this still speeds up development time, at the cost of forcing everyone to use the same compiler.

Re:Yay! Let's trade speed for dumb.

[clone53421]

Streaming SIMD Extensions

Re:Yay! Let's trade speed for dumb.

[sveinungkv]

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.

Re:Yay! Let's trade speed for dumb.

[j-pimp]

Streaming SIMD Extensions

Ok, it seems to be similar to the mmx instructions. Everything I said about building better compilers still applies.

Re:Yay! Let's trade speed for dumb.

[Grishnakh]

As another poster pointed out, Coreboot (which is written in C now) already boots Linux in 3 seconds, which is far faster than normal BIOSes. So obviously, performance isn't a problem here.

Custom assembly language routines, written by an expert, may be helpful for certain things which are executed a lot. However, BIOS code is NOT executed a lot: it's executed just before booting the OS, and that's it. After the OS boots, BIOS code is never seen again. So if you're trying to eke out every bit of performance on your computer, writing custom assembly language code for your BIOS is probably the biggest possible waste of time. Instead, you should concentrate on things like OS interrupt routines, or certain software libraries which demand high performance (video codecs for example). Of course, even then it's debatable how well your asm routines will perform compared to well-written C code that's compiled by a good compiler with optimization.

Re:Yay! Let's trade speed for dumb.

[bram]

3 seconds should be enough for anyone.

Re:Yay! Let's trade speed for dumb.

[Dolda2000]

Indeed, what you said about building better compilers certainly does apply, but it is well known to be a very hard problem to solve.

For example, one kind of code which would benefit greatly from SSE (or some other vector engine) is a simple matrix addition, for which the manually written C code might look like this:

/* Slashdot's stupid ecode tag removes my indentation :-P */
void add(int *m1, int *m2, int len)
{
int i;

for(i = 0; i < len; i++)
m1[i] += m2[i];
}

In assembler, you could easily write this code with SSE, packing four ints into an SSE register, adding them all with one instruction, and storing them back, making the code potentially four times faster (assuming all the data to be in cache, of course). However, how would you propose that a compiler be able to see this fact? It would have to do some kind of global analysis on the loop itself and figure out the aggregate effects of the operations happening inside.

Not that it's impossible, of course, and as I recall it, one of the largest changes in GCC 4 was that it switched to a new form of internal data flow representation, SSA, which was supposed to make it easier for the GCC devs to add certain kinds of auto-vectorization techniques later on. I seem to recall that it was supposed to be added in GCC 4.1, but I never kept track of it. Does anyone, by any chance, know if it was implemented?

Either way, the point I wanted to make is that some things are very hard to optimize. Even if it can be done, it may take quite some time between the point where a CPU vendor adds a new feature and the point where people figure out how to use it automatically in a compiler. (MMX, AltiVec and other vector engines have been around since -- I don't know? The 80s? -- and only recently have compilers been emerging to take advantage of them automatically (excluding such specialty languages as C*). For this reason, writing assembly language to optimize certain, specific code paths is still relevant. For the most part, however, it is very much correct that a good compiler with knowledge of a CPU's execution units, branch prediction techniques, register renaming schemes and whatever other have you, will outperform human-written assembler in most cases.

Re:Yay! Let's trade speed for dumb.

[rrohbeck]

Performance isn't an issue for the BIOS anyway. It spends 99% of its time waiting for IO devices (or memory, in the memory test, which is usually skipped because you can't test GBs of memory in a tolerable time.)
The only good reason why BIOSes are still mostly Assembler is legacy.
Oh, and we used (some) C in the BIOS in the early 90s. Linking Borland C with Phoenix BIOS code was interesting though.

Re:Yay! Let's trade speed for dumb.

[Joce640k]

Yeah, 'cos Matrix multiplication is the sort of thing BIOSs do a lot of...!

Re:Yay! Let's trade speed for dumb.

[BBandCMKRNL]

(or memory, in the memory test, which is usually skipped because you can't test GBs of memory in a tolerable time.)

Given that most non-servers don't have ECC RAM, I'm more than willing to wait an extra minute or so on boot to give the system a chance to catch any bad RAM.

Re:Yay! Let's trade speed for dumb.

[rrohbeck]

My recent experience is that any non-trivial RAM problems take days to catch. I run memtest86+ for at least a weekend if I suspect a memory problem, less isn't worth it.

Re:Yay! Let's trade speed for dumb.

[afidel]

My HP servers test 128GB is a tolerable time. They probably do a very rudimentary check, but they seem to be using all 16 cores to do the check so that it completed in a reasonable timeframe.

Re:Yay! Let's trade speed for dumb.

[Sj0]

You'd be looking at a pointer increment, a memory write, a memory read, and a compare. I'd call it 5 instructions to test. According to wikipedia, the fastest processor available gets about 14 billion instructions per second, so the CPU should be able to test about 3GB/s.

It's strange; I figured it would be a memory bandwidth issue, but memory throughput in such a machine would be about 8GB/s, more than enough to stock the CPU.

Changes

[Wowsers]

Just a random ramble, but why change the name from LinuxBIOS, surely it would have been easier to point out the irony of Windows needing Linux to start itself. Maybe it would have got some people to think more of the capabilities of Linux then?

Re:Changes

[anothy]

because it isn't linux, and really has nothing to do with linux. the original name was a marketing gimmick.

Re:Changes

[McFly777]

This may not be the reason that this project changed its name, and IANAL, so take this with a block of salt, but one reason that I can think of immediatly is Trademark Dilution. Since the BIOS has little to do with Linux (and visa versa), using Linux in the name simply confuses things by suggesting a connection that isn't there. Really "Open BIOS" is more accurate than Linux BIOS, and CoreBoot is probably better yet from a trademark standpoint.

Now, before somebody else says it, I read in another thread that Linux was one of the earlier OSs that this BIOS could boot, but that is because Linux doesn't use the bios for much at all, whereas Microsoft OSs rely much more heavily on the BIOS. Thus the reason that this article is news.

Re:Changes

[Daengbo]

What is Linux BIOS?

We are working on making Linux our BIOS. In other words, we plan to replace the BIOS in NVRAM on our Rockhopper cluster with a Linux image, and instead of running the BIOS on startup we'll run Linux. We have a number of reasons for doing this, among them: ... [LinuxBIOS.org, Aug. 2000, at the bottom of the page]

You're wrong.

Re:Changes

[clone53421]

the irony of Windows needing Linux to start itself

First, CoreBoot isn't Linux. Second, Windows doesn't need it; plenty of closed-source BIOSes will boot Windows.

The irony is that [closed-source] Windows can now use an open-source BIOS to boot itself, which reflects on the capabilities of OSS and not necessarily of Linux in particular.

Re:Changes

[RiotingPacifist]

because coreBoot doesn't run linux so the name is more relevant than LinuxBIOS

Re:Changes

[BOFHelsinki]

Actually CoreBoot both is a Linux and can run Linux. ;-)

However, I prefer the new name too. Well, maybe "core" is a bit all over the place nowadays, but "CoreBoot" still rolls off the tongue better than "LinuxBIOS" and the name doesn't need to be a description. (Enthusiasts know already, casual users couldn't care less anyway.)

Re:Changes

[RiotingPacifist]

are you sure? i got the impression from:

Some of the many possible payloads are: a Linux kernel, FILO, GRUB2, OpenBIOS, Open Firmware, SmartFirmware, GNUFI (UEFI), Etherboot, ADLO (for booting Windows 2000 and OpenBSD), Plan 9, or memtest86.

that linux is only in coreboot when it is compiled as the payload, much like linux isn't intrinsically in grub

Re:Changes

[anothy]

not really. i over-simplified and omitted history.

more precisely, the project started as an effort to add whatever "extra stuff" was necessary to a dramatically neutered linux kernel to make it work as a BIOS. that only lasted a few years; since then (circa 2001) the focus has been on that "extra stuff", and that's what the name "LinuxBIOS" has refereed to for most of the project's existence.

for the authoritative story, here's the name change announcement from about a year ago.

Re:This is great news for us all

[Dunbal]

Sign on a Google desk:

"The chair stops HERE"

EFI?

[Midnight Thunder]

Given the slow move towards EFI, would it not make sense to make CoreBoot an EFI loader, with the BIOS support option? If it is EFI compatible I couldn't see it clearly marked on the website.

Re:EFI?

[mhatle]

EFI is useful in the same way Open Firmware on PowerPC and Sparc is useful. It gives you an extensable system that can do different things with devices. This is great on a system where you don't know what the hardware may be (i.e. Workstations).. but starts to fall down when you get to servers, blades or embedded systems.

On most systems these days BIOS or any type takes between 3 and 30 seconds to boot to the OS. This is simply not acceptable to many blade and embedded system designs.. (Even some server designs this isn't acceptable.)

I can boot a system with coreboot in a second or less to the OS. This is really the most important part of coreboot. (For embedded systems, most of the time our target is in the .2 to .5 range from power on to OS start... this almost all but excludes ia32 from many embedded applications today.)

Re:EFI?

[rickb928]

The only EFI I deal with is on Itanium servers. Not your typical "system where you don't know what the hardware may be".

Re:EFI?

[Cyberax]

EFI allows lightning-fast boot.

First, you can put your kernel in EFI (if there's enough flash) and boot it directly from there.

Second, EFI itself is pretty much efficient - you have access to lots of RAM, CPU works in protected mode, etc.

It's quite possible to have 1 second until kernel startup with EFI. Almost like on my 166Mhz MIPS board :)

Re:EFI?

[sveinungkv]

I think you misunderstand what Coreboot is. Coreboot initializes the hardware that needs to be initialized and then give the control to a payload. That payload can be the Linux kernel, SeaBIOS (that implements a legacy BIOS so you can boot systems like Windows), OpenFirmware or, if somebody did the work to make it happend, an EFI implementation like GNUFI. So what you want (an EFI loader) would just be a payload, not a part of CoreBoot. I think the reason why people are giving priority to a BIOS implementation (SeaBIOS) over EFI is how much code you can get running by adding BIOS support compared to how much you can get by adding EFI.

Re:EFI?

[phsdeadc0.de]

Coreboot by itself is initialization firmware only. That means, it doesn't provide any callable interfaces to the operating system or its loader. So you cannot ask coreboot to load a block from disk. That's were BIOS, OpenFirmware and (U)EFI come into play to fill the gap. They don't define the firmware, but its interface.

I haven't read the article, but I'm quite sure that they're using SeaBIOS - running on top of coreboot - to boot Windows. In this setup, coreboot performs hardware initialization and SeaBIOS provides the required BIOS routines for Windows to boot.

So why not (U)EFI, you ask? Well, it just takes someone to place an EFI implementation on top of coreboot. I think GnuFI used to be able to run off coreboot, but I think the project is dead. TianoCore is probably a better option. Actually, I know that TianoCore is the better option and that it can be done, but certain legal obligations prevent me from porting TianoCore to coreboot at the moment.

Why????

[Archangel Michael]

My view is .. "it ain't done till Windows 7 doesn't run"

I think they should tweak it so that Windows 7 boots, but every 30 mins or so it crashes. Call it ... Karma!

Re:Why????

[maugle]

To me, that sounds more like nostalgia than karma.

Re:Why????

[Anonymous Coward]

How would you tell the difference?

Does the OS still use the BIOS?

[NonUniqueNickname]

I thought modern operating system (i.e. not-DOS) make no BIOS calls once the drivers are loaded. Does any of this code get executed from the desktop?

Re:Does the OS still use the BIOS?

[dk90406]

But the code is in the BIOS is needed in order to initialize they memory, display (basic), CPU, HDD etc in order for the OS to boot.

Re:Does the OS still use the BIOS?

[SanityInAnarchy]

You still need a video BIOS to display VGA until/unless the OS provides real drivers.

Perhaps more importantly, you still need the BIOS to provide hard drive support until the native support is loaded.

In the case of Linux, all the needed drivers will be loaded from the initramfs within the first few seconds of boot, but the bootloader (Grub or Lilo) still needs the BIOS to read the kernel and initrd from disk. Only way around that, that I can think of, is for coreboot to natively support loading and running the kernel/initrd.

Either approach means the BIOS needs to either reproduce the old BIOS bug-for-bug, or be compatible with a specific OS.

Re:Does the OS still use the BIOS?

[thogard]

Why? It only needs to load some code from the disk to some RAM and then start it. That means the CPU needs to be in the right mode to run 32 or 64 bit code, init the VM system enough to use some memory, init the disk drive and read in some blocks. It doesn't need to touch the display unless something bad happened. I suspect that most of what a typical BIOS does isn't needed at all unless it can't find a kernel on the disk.

Re:Does the OS still use the BIOS?

[dk90406]

True, some of what a BIOS does (e.g. initializing the display, sending reset to printers etc) is not really needed. Including the POST. But much of it makes diagnostics easier, in case of an OS boot failure.

You can follow the early boot process if the graphics is initialized - if it fails, control is never returned to the BIOS, so you would end up with a black screen and a dead computer without graphics.

Re:Does the OS still use the BIOS?

[Daengbo]

No. Modern OSes initialize hardware by themselves. CoreBoot simply passes off to a kernel as soon as possible (generally 1 sec).

Re:Does the OS still use the BIOS?

[Daengbo]

Only way around that, that I can think of, is for coreboot to natively support loading and running the kernel/initrd.

This is exactly what LinuxBIOS used to do. The system was for clusters and booted directly to a kernel. I haven't followed the project in maybe five years, so things may have changed.

Re:Does the OS still use the BIOS?

[Anonymous Coward]

Check this out:

http://permalink.gmane.org/gmane.linux.bios/20954

Proper drivers, no more bios.

Re:Does the OS still use the BIOS?

[RiotingPacifist]

why? by that i mean if linux doesn't need it why does windows?

Re:Does the OS still use the BIOS?

[Hucko]

Y'd think that it would default to the most likely options then have a test option for when the OS fails to boot.

Congrats

[Anonymous Coward]

Congrats to the team.

At first you think no big deal, then you realize they are making their own bios, something most of us would fear trying. Congrats for doing something difficult, well.

Interested in free printer chips and ink formula

[bogaboga]

I wish we in the OSS world had "Open Source" printer chips and toner formula. These would enable anyone with the ambition, to build "free" printers instead of shelling dough to these greedy companies.

Open cores

[tepples]

Excuse my ignorance but is it already possible to have a fully working computer that doesn't perform a single unknown operation?

Possible? Yes. Feasible for an enthusiast? Not in the first quarter of 2009. Intel and AMD CPUs contain secret microcode. There exist Free CPU cores such as the MIPS-compatible Plasma, but as far as I know, none are commercially fabricated in significant quantities.

Re:Open cores

[howlingmadhowie]

have a look here: http://guiodic.wordpress.com/2008/09/17/richard-stallman-interview/

the lemote seems to be about as free as a system gets nowadays. i do not know however, if you can download schematics to the chip and microcode. you can do this with the opensparc processor, btw

Some questions..

[Anonymous Coward]

There are some things I don't understand about CoreBoot, so perhaps someone can enlighten me ;)

Let's say i replace the BIOS of my mainboard with CoreBoot. How do I configure the system? I know that Linux doesn't really do any BIOS-calls any more (legacy-free), but how do I for example change ram-timings, voltages, memory speed, change the multiplicator of my cpu, disable certain onboard devices, or tell the system do boot from cdrom and not from disk? To me it seems that CoreBoot makes sense for "locked" devices, like routers and stuff, where you don't actually need/want to change these things. Am I right or wrong? :-)

Re:Some questions..

[Grishnakh]

I don't know either, but I would guess that Coreboot has a menu you could bring up when you power up which would allow you to choose your boot device order. However, many modern motherboards have many settings in BIOS for things you mention, like RAM timings, voltages, CPU multipliers, etc., and it seems like most of those would be board-specific.

AMD Geode

[chill]

Looking at the CoreBoot site, it seems there best support is for the AMD Geode chips. It is ironic that this Slashdot article is one after the article saying AMD has no successor planned for the Geode line and it may fade away.

they need to do better, sys info pics are differen

[Locutus]

I noticed in the first system info image that the processor and memory fields said "Not Available" but in the 2nd image labeled "system information closeup" it then shows data populating those fields.

Maybe I've been trained to look for tricks in marketing campaigns run by Microsoft but these kinds of details should not be overlooked or else it gives a sense of being falsified.

LoB

Hence, One line Perl scripts

[Marc_Hawke]

I always wondered why people thought they were so cool...but if you can equate bugs to 'lines of code' I have a feeling they are pretty efficient. ;)

Re:Hence, One line Perl scripts

[Chabo]

One of my favorite sections from the book "Learning Perl":

Now, we're not saying that Perl has a lot of bugs. But it's a program, and every program has at least one bug. Programmers also know that every program has at least one line of unnecessary source code. By combining these two rules and using logical induction, it's a simple matter to prove that any program could be reduced to a single line of code with a bug.

Re:Hence, One line Perl scripts

[Anonymous Coward]

... every program could then be further reduced to the single empty program, which would still contain at least one bug.

Which in turn means that all programs are the same, thus - assuming deterministic execution - all exhibit the same behaviour.

Or in other words: Linux is Windows.

Re:Hence, One line Perl scripts

[Anonymous Coward]

any program could be reduced to a single line of code with a bug Doesn't that encompass like 95% of perl programs?

Re:Hence, One line Perl scripts

[Anonymous Coward]

Normal people like to write readable code. This is just a rule of thumb that helps you with the common case (where you are trying to write code you can read later). Obviously there's more factors involved, but its simplified because most code is written extremely similarly.

Re:Hence, One line Perl scripts

[Anonymous Coward]

They have only one buggy line of code, do they not?

Re:Hence, One line Perl scripts

[Fred_A]

Normal people like to write readable code.

It's just a damn shame that so few normal people are programmers.

Shouldn't have told 'em . . .

[frankenheinz]

. . . now they'll fix things so that it can't.

This is a Mission Critical OSS Project

[mpapet]

It deserves praise and support previously reserved for deities. I'm only overstating this a little.

The benefits of CoreBoot are many:
1. Cheaper motherboard manufacturing. TPM chips are expensive components when mass producing motherboards.

2. CoreBoot gives hardware manufacturers a viable market that Microsoft and Apple cannot touch.

3. Keeps the hardware open for all operating sytems and devices. This simple fact cannot be stressed enough. As the world slowly migrates to 64-bit everything. Microsoft has locked hobby driver developers out of Vista in 64-bit land.

TPM BIOS modules have the capacity to lock out unapproved operating systems, devices, etc. Are they widely implemented? No. Is it possible to the point of being well documented? Yes.

Re:This is a Mission Critical OSS Project

[afidel]

Huh? TPM 1.2 chips are merely a hardware keystore, they don't do anything to lock out 'unapproved' software. In fact the spec is fully open and open source applications can make use of them to securely hold keys just as easily as Vista does. My biggest gripe about TPM at this point is that only Dell ships servers with them, I want to use the keystore for automatic booting of Bitlocker encrypted 2008 remote domain controllers but can't bring myself to use Dell hardware.

Why as AC?

[WED Fan]

Idiot! It should be "One small post for a troll."

Sweet historical slam on an FP troll. Sweet. Just wish I could have used my mod points on you.

You do know that with the historical reference you would have gotten modded up if you hadn't posted AC?

What about Intel?

[ygslash]

Will it also boot Windows 7 on an Intel chipset?

You forgot one thing

[Anonymous Coward]

Specialized instructions (MMX, SSE, etc) can provide substantial speed boosts with certain code. Unfortunately no C compiler really takes full advantage of those features (if at all) despite them being widely available nowadays.

So in those cases it may be a whole lot faster to use assembly. Usually this is just embedded within a C function because of the specialized nature.

Re:first post

[sexconker]

Recent analysis of the tapes show that he DID say "One small step for a man".

Zing.

What about EFI?

[nsayer]

BIOS is way, way obsolete. The bigger question is whether or not Windows 7 will be bootable on EFI machines. This article says that Windows 7 "delivers support" for EFI. It is likely that means that it will be bootable on EFI equipped machines, but there's wiggle room there.

EFI and GPT offer real improvements beyond merely sweeping away the legacy cruft of decades of backwards compatibility. It's time to move on.

Re:Interested in free printer chips and ink formul

[LandGator]

I wish we in the OSS world had "Open Source" printer chips and toner formula. These would enable anyone with the ambition, to build "free" printers instead of shelling dough to these greedy companies.

Dayumn! Superb idea? 1) Which obsolete hardware would be best to start with? 2) What's the high-volume, most available? 3) Sturdiest, least likely to be a pain? Freegeek.org has oodles of used printers if anyone wants to start building a hardware base.

Re:Interested in free printer chips and ink formul

[Richy_T]

It's an interesting idea. I think open source toner might be a bit tricky (likely the manufacturing process is difficult) but it certainly might be possible to work out the components for an open source driver board that could be used as a module in existing printers, bypassing the "chips" and allowing the simple use of third party toner. It might then be possible to move forward with open source printer hardware from there.

I don't get the point - EFI is the future

[EXMSFT]

With Intel, Apple, and rapidly the entire rest of the x86, x64, and IA64 hardware world moving to (or explicitly running on, in the case of Apple and IA64) EFI, what is the whole point of CoreBoot besides being a nifty experiment? Intel won't let anything replace EFI anytime soon. Trust me - I've had EFI shoved at me for almost a decade.

Re:I don't get the point - EFI is the future

[YesIAmAScript]

BIOSes only boot MBR/FDISK disks. And MBR tops out at 2TB. So now that the largest drive that MBR can support was announced today, isn't it time to move forward to a new boot system that can boot GPT disks (which can go well past a petabyte)?

EFI can do this, I can't see why we shouldn't be going to it.

Re:I don't get the point - EFI is the future

[EXMSFT]

Absolutely. EFI can support BIOS-based implementations as well (witness BootCamp on the Intel Macs - which does exactly that). Bye bye BIOS.

Re:they need to do better, sys info pics are diffe

[Anonymous Coward]

I noticed in the first system info image that the processor and memory fields said "Not Available" but in the 2nd image labeled "system information closeup" it then shows data populating those fields.

If you watch the vid you'll notice it takes a moment to fetch that information.

It's a great project, but moving slowly

[Anonymous Coward]

This is a great project. Going to their website it seems like most of the CPUs fully supported are so obsolete one has a hard time buying them. My guess is that there's little support in terms of financing or manufacturers releasing specs. Could it be that the traditional BIOS makers have a lock-in and special interests are interfering?

I don't like to leave my computers on all the time, but I do use them sometimes as PVRs, so one pet peeve I have is the hassle of trying to set up my computers to switch off and switch on at various times the way an old fashioned VCR does. Or the way my Mac running OS X does when I use it as a PVR with Eye TV. I would hope that CoreBIOS would fix that situation. Now that's me. I bet a lot of people would have various needs that could be addressed by an open system.

AMD is a split company...

[Anonymous Coward]

AMD itself is helping with proper free BIOS support. But ATI is forcing world + dog to use their atombios bytecode quite harshly...

If only the AMD RS780 board BIOSes weren't editing the ATOMBIOS bytecode directly to tell it how its busses are used...

Or how ATI is holding AMD back, has it ever done anything else?

Re:Interested in free printer chips and ink formul

[Anonymous Coward]

Talk to Stallman. He may be willing to help -- since an issue with a printer was what got him started with Free software:
http://en.wikipedia.org/wiki/Stallman#MIT.27s_hacker_culture_declines

A FOSS Sandwich?

[TwistedSymmetry]

(With a fattening layer of MS)

Anybody feel like booting from CoreBoot into Windows 7 beta then running KDE 3.2RC?

Bunch 'o cock teasers

[SpaghettiPattern]

I thought: "Wicked! My mojo will finally be complete! Shagadellic!"

Then I read there's even a "Flashrom Live CD". < 185MB. Instant and spontaneous ejaculation!

Then it came to me:

This page is a work in progress. There is no ISO yet. This is just a plan for now.

This is exactly like a fine woman looking at you. Saying she will give it to you. Eventually. Maybe. Cock teaser.

Still a beautiful woman I like having around.

Now please excuse me. I'll be off masturbating.

Re:Interested in free printer chips and ink formul

[westlake]

I wish we in the OSS world had "Open Source" printer chips and toner formula. These would enable anyone with the ambition, to build "free" printers

The start-up in hardware and consumables doesn't more than ambition - he needs divine intervention.

The competition is Cannon - Dell - HP - Lexmark.

The competition is guaranteed shelf space in every WalMart.

Every drugstore or mini-mart in a town big enough to rate a single traffic light.

Year of ...

[ehaggis]

...the linux bootloader! (We'll have to wait for the desktop.)

Re:Interested in free printer chips and ink formul

[Grishnakh]

The answer is simple: just don't buy a printer that requires chips embedded in the toner cartridges. Most laser printers, AFAIK, still don't. Even my HP Laserjet 2300 doesn't require it (though it will give you a warning message when you turn on the printer with a non-HP cart, but that doesn't matter).

It's mainly the stupid inkjet printers that have this problem, and anyone stupid enough to use an inkjet printer deserves to be ripped off, when laser printers are so much cheaper to operate, and only cost $100-200 now (and much less on Ebay for very nice HPs).

CoreBoot on the 780G?

[MoxFulder]

AMD engineers have also been submitting code to allow CoreBoot to run on the company's latest chipsets, such as the RS690 and 780G."

Now that would freakin' rock!!!

Until now, CoreBoot has been really hampered by the fact that it has mostly been supported on server boards, with little to know support on Desktop and Laptop chipsets. This is mostly the fault of the chipset/mobo manufacturers, who have zealously guarded their legacy BIOS crap for reasons that are pretty unfathomable to me.

I would love to be able to run CoreBoot on my Desktop and laptops. It would help to fix soooo many of the legacy BIOS issues that people tear their hair out over: booting USB devices, suspend/resume support, wake-on-LAN support, network booting.

So, go AMD. I've been a loyal fanb^H^H^H^H, uh, customer for years and I'm really glad to see them moving in the direction of open-sourcing their video drivers and now releasing chipset docs. Excellent news.

You pulled that out of your ass Mr. Civil Engineer

[Anonymous Coward]

Easier to maintain, more portable accross platforms, easier to do more complex stuff, easier to integrate/reuse existing librairies/code, etc.... ?

I could say that about a refrigerator-dolly manufacturing company, or a public librarian, or a nail salon.

Good on AMD for helping

[jonwil]

If only Intel would be as forthcoming with open code for their chipsets as they are with open code for their GPUs

Re:Interested in free printer chips and ink formul

[Anonymous Coward]

An interesting idea, but just pointing out that you can use cheaper toner cartridge supplier. For example Pitney-Bowes (of postage machines fame) makes a wide selection of high quality cartdridges that are often about half the cost of the original and can be ordered online; they especially ocver HP models and they include a warranty that covers printer repair costs if the cartridge fails and pours toner all over the machine. Alphajet is another supplier I have had good experience with. There's also BC in color inks and Zebra in toners (with a less stellar track record but usually much better than refilled cartridges; refills are horrible once the same cartridge has been refilled over two or three times). The funny thing is, I know a Zebra rep, and he revealed that they subcontract the same generic cartridge plant in Portugal that Lexmark uses. ;-)

Just saying that you *can* stop shoveling money to the greedy printer makers with the Gillette business model fairly conveniently -- but I do hope the "OpenPrinter" sees the light of day someday. :-)

CoreBoot will eventually put Linux in BIOS

[Anonymous Coward]

It is much more effective to have Linux on a bios, and allow it directly throttle system settings on demand. Back when hardware IO was on a proprietary bridge, eventually an assembly procedure module will be universal to any operating system for the kernel to interact its procedures. Instant bootup in Linux or even *gasp* Microsoft Windows would be similar to how Apple has closely integreated their software to BIOS. Instant-On will be just that. In terms of Linux, memtest86 or whatever it's called, would make a fair footprint rather than the default sissy hardware check that is performed; imagine a hardware check done in Linux to test the reliability of hardware while it is actively running! Imagine firmware upgrades that take effect while still running the OS, and with compatibility backdoors to prevent hardware hangups so they could be reset into a compatibility mode to try again for full function non-default!

As for me, I wouldn't mind seeing Linux kernel integrated with a complete DirectFB with minimal X Server, all on BIOS in immediate power-on mode.

Cross-platform firmware does exist.

[Estanislao Mart�nez]

You're assuming that firmware must, of necessity, be for a single platform. This assumption is wrong; while different platforms do need different object code to some extent, it is otherwise good to use the same firmware code on many platforms.

Read up on Open Firmware and EFI. These are existing firmware standards that are used in more than one CPU platform. They go even further than that, actually, and make the firmware include a platform-independent bytecode interpreter, so that it is possible to write cross-platform binary device drivers or firmware extensions in general. The idea is that your device's firmware would come with simple platform-agnostic drivers that can be used during the bootstrap process. The OS can use those drivers provisionally until it loads more featureful, native code drivers.

From what I read, CoreBoot has a very different design philosophy from these firmware standards, and it's not trying to do anything that elaborate; but still, writing it in C allows the firmware to be much more easily ported to other platforms.

Heard that before, though

[Moraelin]

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.

The funny thing, though, is that I've heard that since at least the 80's. (Never mind that it was provably wrong, too.) But there was always some crowd repeating the same mantra. There was always some nebulous X years ago when competence was worth it, and a now where the compiler does a better job than anyone imaginable.

I'd imagine that it might be as old as when v2.0 of the first compiler was available. See last year's FORTRAN was worse than hand-optimized assembly, but this new compiler does everything better than any human! Knowing the underlying architecture is soo 50's. Move on to the 1960's already, you assembly has-beens. Heh.

The problem with the above line of thinking is assuming that a human would do the same optimizations that a compiler does. And in that case, yes, might as well let the compiler do it. What a human does better though is changing the algorithm, if another one fits the architecture better. The main advantage is probably not even the actual coding of assembly itself, but seeing actually what's the resulting code, exactly which registers are used and what the timings are for doing things the X way vs the Y way. Seeing that the X way actually needs swapping values to memory, while the Y way fits them nicely in the available registers. _That_ is the advantage.

Additionally, almost no compiler yet is _that_ complete. Most have basically a table of usual patterns that come with the associated clever optimizations, but are sometimes thrown off the hook by as little as writing a comparison the other way around. Java's JIT is for example well known and documented for it. And yes, the first Hotspot versions were documented to be thrown off the loop by as little as changing an "if (a == b)" to "if (b == a)" in a popular benchmark at the time.

There'll always be some piece of code which misses that completely.

Which brings us to another point: cheating. If you think that the compiler will perform as good on _all_ cases as it performs on the showcase benchmarks, I have some logging rights in Sahara to sell. The generated code for popular benchmarks, which performs as well as the best hand-optimized assembly... guess why? Because it _is_ hand-optimized assembly. The compiler is programmed to recognize whole chunks of that benchmark and essentially use the hand-optimized assembly that exists just for it.

Assembly has its own problems, don't get me wrong. It's _very_ expensive to produce, a nightmare to maintain, and isn't cross-platform either. I wouldn't advise it for whole projects or for most projects, for that reason. Bang per buck, the vast majority of stuff out there just doesn't justify using assembly. But the myth that an expert can't produce better assembly code, is still just that: a myth.

The real question is whether you want to pay a _lot_ more, for a little extra speed. But (unless you hired a monkey) that extra speed has always been there, and still is there.

Depends heavily

[Giant Electronic Bra]

On the compiler, the architecture, and what the code does and how its written.

It has been a few years since I had the job of writing device drivers, but we did quite a bit of experimentation around this point. This was on 68k processors back in the 80's, but what I learned was that in MANY cases the compiler is pretty good. Interrupt Service Handlers, the really speed critical part of your driver, are also usually quite simple linear code. Maybe you have a simple loop, a lookup table, index a data structure or two, move some bytes around. If you're doing more than that its probably a bad design.

Given that the entry to the ISR is already a context switch, so you're starting out with an empty pipeline what we discovered was that in actual practice the C compiler was reasonably close. Its almost 20 years later, compilers have improved. I'm sure you or I could look at gcc output and tweak away some cycles here and there, but the difference is not usually much. The other issue was of course that case where the compiler just missed something entirely, but those cases are almost always ones where you can tweak the source a bit and fix the problem or use a different flag.

Of course the 68k architecture was easily 50 times better than x86, so that helped too! lol. I still think its a tragedy that x86 went anywhere, the whole design is $*}#...

Re:Depends heavily

[Moraelin]

Of course the 68k architecture was easily 50 times better than x86, so that helped too! lol. I still think its a tragedy that x86 went anywhere, the whole design is $*}#...

Admittedly, my experience is quite the opposite: I worked mainly on the x86 (and 8080/Z80 before it), where having your counter in the CX register actually made a difference, and having your lookup table in BX made another difference, and so on. And adding some SIMD instructions to it only made it even more quirky.

Still, even on more orthogonal architecture you can usually squeeze _something_ out for your own peculiar case, that the authors of a generic compiler never thought about. A lot less, admittedly.

The other issue was of course that case where the compiler just missed something entirely, but those cases are almost always ones where you can tweak the source a bit and fix the problem or use a different flag.

Very much so, but my point was exactly that you need:

A) to at least have seen what the compiler produced, or failing that

B) at least some vague notion of the machine behind, and what the compiler does,

to spot the need for a source tweak.

The fact is, I work all the time with people who've never even seen assembly, and have really no flipping clue of the code behind it all. It shows. E.g., their assumptions of the costs of various operations is usually missing the mark by a mile. You see them assuming, for example, that speed or cost is measured in lines of code, and the fact that one is a call to bogo-sort and the other is "i++" goes right over their head.

Basically the fact that you've worked on those drivers, know what the machine can do, and actually compared C compiler output to your own assembly... that IMHO made you a better programmer, whether you're aware of it or not. Even if you write C for the rest of your days, you'll write better C code for it. IMHO.

lol, perhaps so.

[Giant Electronic Bra]

I just found 68k to be a really elegant design. All orthogonal registers, no real special cases, etc. No need to worry about the fact that your value needed to be in register A and not B, etc. That really did help a lot.

Never did make sense to me that people couldn't just pick up the documentation for the processor and SEE that instruction X took 25 clock cycles and Y took 3. Ah well, the bad programmers are what lets the good ones stand out! ;)