> while in the 486 era BIOSes were exclusively written in very carefully optimised Asm
Nope; the change happened in the 386 era; by the 486 era most BIOSes would be (partially/mostly) written in a pretty uncarefully written "HLL". Even before I would argue against the "carefully optimized" ASM.
They were written in Asm up into the 2000s; at least AMI and Award were. Despite a lot of macro use, there was certainly an emphasis on keeping things as small as possible.
Contrast that with just shoving compiler output into the ROM image.
They had _some_ asm (you just can't avoid it), plus whatever historical crap they already had, but most definitely the immense majority of an Award BIOS of the 2000s is compiled C code (e.g. "new setup"). And done by "developoors" as much as it gets.
Do note that, even with compilers of the era, using HLL with care can result in having an _easier_ time managing codesize than some of the garbage written in assembly by random developers... specially as feature creep starts to set in, which by the 2000s was in full force.
Have you ever seen a USB stack (even for HID boot protocol) in assembly on a commercial BIOS?
I will take a look, but right now I would be skeptical of any such "100% asm" "leak", considering how easy it is to get a lightly commented listing. My position is indefensible, so no point arguing though.
> C didn't start showing up in BIOS until the UEFI era (Tianocore etc.).
"Showing up" is an understatement, since Tianocore is almost all C. And we didn't switch from 100% asm to 99% c overnight.
Nope; the change happened in the 386 era; by the 486 era most BIOSes would be (partially/mostly) written in a pretty uncarefully written "HLL". Even before I would argue against the "carefully optimized" ASM.