flat assembler
Message board for the users of flat assembler.

Index > OS Construction > Goodbye to BIOS? [split off TetrOS thread]

Author
Thread Post new topic Reply to topic
DimonSoft



Joined: 03 Mar 2010
Posts: 585
Location: Belarus
DimonSoft
Mike Gonta wrote:
Tomasz Grysztar wrote:
While preparing to organize a 512-byte coding contest for the 20th anniversary of fasm, ...
It seems quite fitting (in an historical context) that such a contest (that is dependent on the BIOS)* coincides with Intel saying "Bye to BIOS" by 2020.

Didn’t they try to say “Bye to BIOS” ten years ago? And even before then?
Post 04 Nov 2019, 20:50
View user's profile Send private message Visit poster's website Reply with quote
Mike Gonta



Joined: 26 Dec 2010
Posts: 237
Location: the-ideom
Mike Gonta
DimonSoft wrote:
Mike Gonta wrote:
Tomasz Grysztar wrote:
While preparing to organize a 512-byte coding contest for the 20th anniversary of fasm, ...
It seems quite fitting (in an historical context) that such a contest (that is dependent on the BIOS)* coincides with Intel saying "Bye to BIOS" by 2020.

Didn’t they try to say “Bye to BIOS” ten years ago? And even before then?
The original technical implementation of The BIOS has been gone for quite a while now and replaced with the UEFI Compatibility Support Module.
It's the UEFI CSM that is going to disappear next year and as such the real mode BIOS and all such things (VGA, 0xB800, the related I/O ports, etc.) including
real mode will go with it.
Take away the BIOS and CSM requirement and it might open the door to also removing these legacy processor modes.
There have been rumors that a future Intel x86 processor would scale back some of its legacy support; a pure 32- and 64-bit processor that dropped 16-bit
compatibility would fit neatly with the plans to remove the last vestiges of the BIOS from UEFI.

Of course, we still have emulation.
Oscar Wilde could have wrote:
Emulation is the sincerest form of flattery that mediocrity can pay to greatness.

It was fun* while it lasted, (some say for too long).


*UEFI is simply no fun whatsoever.

_________________
Mike Gonta
the-ideom - now you know how to compile

https://mikegonta.com
Post 04 Nov 2019, 21:50
View user's profile Send private message Visit poster's website Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 585
Location: Belarus
DimonSoft
UEFI is simply not mature enough yet. Many implementations still have very stupid bugs compared to differences in BIOS implementations.
Post 05 Nov 2019, 09:21
View user's profile Send private message Visit poster's website Reply with quote
Mike Gonta



Joined: 26 Dec 2010
Posts: 237
Location: the-ideom
Mike Gonta
DimonSoft wrote:
UEFI is simply not mature enough yet. Many implementations still have very stupid bugs compared to differences in BIOS implementations.
Maybe stupid bugs in the UEFI CSM as compared to the stupid bugs in the real mode BIOS firmware but what has that to do with UEFI without the CSM.

_________________
Mike Gonta
the-ideom - now you know how to compile

https://mikegonta.com
Post 05 Nov 2019, 09:56
View user's profile Send private message Visit poster's website Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 585
Location: Belarus
DimonSoft
Mike Gonta wrote:
DimonSoft wrote:
UEFI is simply not mature enough yet. Many implementations still have very stupid bugs compared to differences in BIOS implementations.
Maybe stupid bugs in the UEFI CSM as compared to the stupid bugs in the real mode BIOS firmware but what has that to do with UEFI without the CSM.

I wish it was about CSM. For example, Graphics Output Protocol had a few problems in relatively new notebook models (a few years ago).

Another thing to discuss is whether the design choices like calling convention used in 64-bit UEFI were good ones. Reusing compiler-oriented calling convention might have seemed to be a good idea but why not reusing ART bytecode then? Gives even more bloat with less effort.

Probably the only good idea is to support loading arbitrarily-sized bootloaders. Used to be the most lacking feature since at least 8086. But… oh, wait, FAT? Why prefer some particular file systems? This decision might look quite stupid 30–40 years later. Why on earth a bootloader should be a normal file? From reliability point of view. Just make it a separate volume and let the OS author decide. You have GPT? That’s OK, just give us better volume-oriented disk API than BIOS did (anything is better than nothing), that would be just enough. Why add features that are to be deprecated in the future?
Post 05 Nov 2019, 12:34
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2019, Tomasz Grysztar.

Powered by rwasa.