Max, it’s not quite that simple.
Our x64 OS actually contains an emulator that will allow BIOS code to
be called at run time, usually limited to just INT 10. (The video
guys are still somewhat stuck in a business model where they can’t
guarantee that their chips can do a mode set without information about
the specific motherboard or add-in card that the video chip is part
of.)
Furthermore, part of the BIOS gets invoked every time the chipset
generates a System Management Interrupt (SMI.) On some machines, this
is almost never and on others it’s all the time. When this happens,
the processor jumps into a known mode (SMM,) which is definitely not
64-bit even if the OS is running in long mode. Generally, all the
processors take the interrupt (directly or indirectly) and they
rendezvous in the BIOS before anything else happens, making it
possible for the BIOS to touch hardware without fear that some other
processor is messing with the same device.
We at Microsoft have been looking for ways to make SMM obsolete and
unattractive to motherboard makers for years, since it interferes with
our ability to make the computer work deterministically. (And, yes,
we know that isn’t the only thing between our current situation and
deterministic operation.) But the truth is that SMM makes it possible
to ship chipsets that have bugs in them and then respond to the bugs
in a timely manner, making the machines built on those chipsets
cheaper, which is generally good for everybody.
Lastly, as you’ve mentioned, the OS interprets ACPI AML (bytecode)
which performs small tasks that are motherboard-specific. Because
ASL/AML is a fairly restrictive language, frequently these methods
just trigger SMIs. ACPI was originally designed to be restrictive
because we were trying to limit the things that were done in it so
that we could guarantee that there was no collision between what the
BIOS was touching and what the OS drivers were touching. In reality,
the hardware couldn’t be easily changed to create such a clean
separate, at least not if we wanted to continue to boot DOS on those
machine (where “DOS” means "DOS, Win 3.1, Win95, etc.)
I (along with others) added many things to ACPI 2.0 and ACPI 3.0 so
that the language was more descriptive and wouldn’t require so many
SMIs. But by then, the installed base of Win98, WinME, Windows 2000
and Windows XP was so large that most motherboard implementers won’t
target anything but ACPI 1.0. We’ll see in five years or so whether
they can start to move beyond SMI.
- Jake Oshins
Former Windows ACPI Guy
“Maxim S. Shatskih” wrote in message
news:xxxxx@ntdev…
> Surely the modern OSes rely on ACPI table and ACPI bytecode from
> the BIOS,
> but the machine code from the BIOS is never executed after the
> kernel is loaded
> (with the exception of int 10h in Windows for some older video
> chips, usually
> for power management on them).
>
> For instance, int 13h is never used after the kernel is in
> memory.
>
> I even have doubts that on x64-capable machine the BIOS contains
> any x64
> mode code.
>
> This is architecturally correct. The role of the firmware is to
> abstract
> any motherboard-specific and chipset-specific stuff, not to be the
> lower layer
> of the OS.
>
> –
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>