[coreboot] REPLY: INT 13H

[Zoran Stojsavljevic]

> I don't see a reason why it should be impossible to abolish Real Mode,
Segmentation and basically everything beside Long-Mode
> and virtual 32 Bit-mode.

This is why: https://en.wikipedia.org/wiki/Itanium

> The Operating-System-Manufactures would need a bit of time to change
their operating systems to be able to start without BIOS
> calls and remove the procedures to set up the flat segmentation.

This is why: https://en.wikipedia.org/wiki/Itanium#Software_support

Best Regards,
Zoran

On Thu, Aug 31, 2017 at 10:30 AM, Philipp Stanner <stanner at posteo.de> wrote:

> On 30.08.2017 14:54, Peter Stuge wrote:
>
>> Compatibility is the only actual value of x86.
>>
> Hi,
> I was often wondering why they don't at least try to get rid of the *very*
> old stuff when it's not possible to get rid of the middle-old stuff.
>
> It's understandable that it's necessary to provide a 32-bit-compatibility
> mode on 64-bit systems. It *was* understandable that it  was necessary to
> provide a 16-bit-compatbility-mode then the first 32-bit-CPUs appeared. As
> far as I understood the Intel Programmer's Manual the CPUs provide a 16-bit
> compatibility-mode in 64-bit-long-mode...
>
> I don't see a reason why it should be impossible to abolish Real Mode,
> Segmentation and basically everything beside Long-Mode and virtual 32
> Bit-mode.
> The Operating-System-Manufactures would need a bit of time to change their
> operating systems to be able to start without BIOS calls and remove the
> procedures to set up the flat segmentation.
>
> Intel is powerful enough to make this change I believe. The question is if
> they benefit from changing x86, making it more modern.
>
> By the way we shouldn't forget that behind the legacy-compatibility-stuff
> and the microcode a very strong, efficient and modern RISC-machine is alive.
>
> P.
>
>
> --
> coreboot mailing list: coreboot at coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20170831/3deedc15/attachment.html>