http://www.thinq.co.uk/2010/6/8/exclusive-msi-bios-will-be-dead-three-years/?full
-
"The main difference between a traditional BIOS and UEFI is programming," said our source, pointing out that "UEFI is written in C, rather than the assembly code used in a traditional BIOS." However, he points out that this means that there's much more flexibility with the code."
This is the second to last paragraph but to me it is among one of the most telling. The author and his source are clueless. There is no more flexibility with code in C than in assembly. There's just a lack of imagination on the part of the coder. Yes, assembly is a bit more complicated than C because its a lower level language but nothing "new" or different is achieved by using C.
This is rather like comparing Linux to Windows and saying one is better. They both are capable of achieving the same goal. It really boils down to whether one wishes to roll up the shirt sleeves and get to know their system. Once one delves into the nuts and bolts they find there are many more possibilities available.Whats more.... The entire article is gratuitously aggrandizing. I suspect the author was remunerated or bought off by MSI. UEFI has been out for at almost a decade now. (The article notes MSI started dabbling in UEFI 2 years ago.) MSI has or had very little say in the whole UEFI development/introduction matter, it was an Intel initiative (also noted in the article).
So what makes this story "exclusive"? The mere fact that MSI is going to exclusively use UEFI? Color me unimpressed. It is nice to see, however, that a mb manufacturer has decided to catch up with the modern era of computing.
What sad journalism.
Posted 1 year ago # -
Pierre
offlineMemberThe real point of using C (or any other "high-level" language) vs. using assembly, is speed – and cost – of development. From specs to RTM, a good programmer produces an average of about 10 lines of code per day, whatever the language. In a similar time frame, you can accomplish approximately 20 times more using C/C++ than with assembly – but the resulting code is bloated by 60% at the very least. Even with today's cheap memory and CPU, there's a performance price; most recent OSes bypass the BIOS anyway for all but the most basic hardware interface ("legacy" USB or PS/2 KB and/or mouse, boot sector loading, VGA video output), so UEFI makes sense in that respect.
"If those who say bad things about me knew what I think of them, they'd say even worse." (Sacha Guitry)
------------------------------------------------
"Earth is the cradle of mankind. Nobody can live in the cradle forever" (Constantin Tsiolkovski)Posted 1 year ago # -
UEFI is going to show its real power in the area of the computer enthusiast. Folks will have much more control over their system either in the form of hardware tweaks accomplished via software or by re-writing the UEFI to include more switches for control of the hardware settings. There's an active community of UEFI hackers that have broken the code of tweaking things and they're only going to continue growing. The folks that will eventually benefit are us, the everyday user. It's all good in my book.
Posted 1 year ago # -
Nate
offlineMemberThe real point of using C (or any other "high-level" language) vs. using assembly, is speed – and cost – of development. From specs to RTM, a good programmer produces an average of about 10 lines of code per day, whatever the language
That's tested and documented code, BTW, and the figure has not changed for years. I saw a chart recently that listed languages and their "productivity" or what they could get done with a line of code. Other languages such as Java and Python are several times more productive than C which itself is more productive than assembly. Hardware is cheap and programers expensive.
I remember the days when I had to write my own queues and trees now I can just use the language's built in ones or use a library that has well tested and efficient code. Takes a few minutes rather than a few days.
What matters is not the years in one's life but the life in one's years.
Adlai Stevenson - more or less.Posted 1 year ago # -
Pierre
offlineMember -
Steven Hodson
offlineHead Honchofunny thing happened after reading this thread .. ran across this http://www.menuetos.net/index.htm - OS written in assembly with a GUI
Steven Hodson
WinExtra / Shooting at Bubbles / Braincell SoupPosted 1 year ago # -
Pierre said:
The real point of using C (or any other "high-level" language) vs. using assembly, is speed – and cost – of development. From specs to RTM, a good programmer produces an average of about 10 lines of code per day, whatever the language. In a similar time frame, you can accomplish approximately 20 times more using C/C++ than with assembly – but the resulting code is bloated by 60% at the very least. Even with today's cheap memory and CPU, there's a performance price; most recent OSes bypass the BIOS anyway for all but the most basic hardware interface ("legacy" USB or PS/2 KB and/or mouse, boot sector loading, VGA video output), so UEFI makes sense in that respect.How bloated your code is is also a function of how much you pay for your compiler.
In the end, C or any other language compile to hex code/machine language, the same language assembly must compile to. At least this is the case for me. I don't write any code for PCs. I write for embedded designs. How efficient the code is is largely relative to your compiler and your skill. One can make any code terribly inefficient if they aren't careful.
Regardless of how poorly the article is written or how viable UEFI is, MSI is signaling a probable change on the horizon that will cause a pretty big ripple in the industry.
MSI has always been an innovator in the PC motherboard industry. That's not to say they are the best, but they do innovate.
I hate assembly. Might as well have to chisel a wheel out of granite to make a cart. Bit banging communications in Assembly sucks!
Posted 1 year ago # -
Pierre
offlineMemberFrom examining a lot of assembly code generated by compilers of all kinds (including Watson C and FORTRAN, and MicroFocus COBOL), I know for a fact that a lot of unnecessary PUSHes and POPs remain even after the best possible optimization. I remember spending a lot of time pruning them from generated code for a project I was working on some 30 years ago. That's what I'm basing my estimate on
Posted 1 year ago #
