Page 2 of 2

Re: hi-memory access in real-mode

Posted: Sun Mar 04, 2012 2:06 am
by Boba
Love4Boobies wrote:You misunderstand; a non-16-bit x86 implementation is any 32/64-bit x86 CPU (i.e., 80386 or later).
i c.

Re: hi-memory access in real-mode

Posted: Sun Mar 04, 2012 2:09 am
by Boba
Love4Boobies wrote:You've already been answered: by switching to unreal mode.
thanx. one more thing, is 'unreal mode' documented by say intel or others?

Re: hi-memory access in real-mode

Posted: Sun Mar 04, 2012 2:20 am
by Love4Boobies
No, it's an effect of the way descriptor caches were implemented in these CPUs. CPU vendors (and others) don't really like to talk about the internals of their products; they'll only do it if it's imperative for software optimization. The earliest account of unreal mode, as far as I know, is this.

Re: hi-memory access in real-mode

Posted: Sun Mar 04, 2012 2:33 am
by shikhin
Hi,
Love4Boobies wrote:I doubt there are many implementations that do that, as much boot loader code relies on this technique; other than that, there would be little reason for the BIOS to do anything of that nature. If you want to play it somewhat safer, only use FS or GS. Either way, if this problem even exists in the real world, it's very uncommon.
Hmm. I'm not too sure - if it is considerably safe, I might dump a bit of my code and use un-real mode.

Regards,
Shikhin

Re: hi-memory access in real-mode

Posted: Sun Mar 04, 2012 4:21 am
by Combuster
I might dump a bit of my code and use un-real mode
Why change something that (apparently) works?
If the BIOS interrupt handlers, say, reload the segment registers (and you can't be sure that they don't), then wouldn't you need to switch back to unreal mode?
A bios call might flush all descriptor caches. It becomes increasingly likely with the newer bioses that boot from new equipment. For example, USB controllers are mostly inaccessible in 16 bit mode because they lack I/O ports and they are memory mapped outside 1M. Therefore the BIOS needs either protected mode or SMM to do read calls from them.
Basically, after any BIOS call you'll have to restore unreal mode to be sure. Depending on guesswork is not smart.

Re: hi-memory access in real-mode

Posted: Sun Mar 04, 2012 4:33 am
by shikhin
Hi,
Combuster wrote:
If the BIOS interrupt handlers, say, reload the segment registers (and you can't be sure that they don't), then wouldn't you need to switch back to unreal mode?
A bios call might flush all descriptor caches. It becomes increasingly likely with the newer bioses that boot from new equipment. For example, USB controllers are mostly inaccessible in 16 bit mode because they lack I/O ports and they are memory mapped outside 1M. Therefore the BIOS needs either protected mode or SMM to do read calls from them.
Basically, after any BIOS call you'll have to restore unreal mode to be sure. Depending on guesswork is not smart.
Aha! Knew that a BIOS might flush all descriptor caches - so, overall, I find it better to switch constantly to protected mode (and back) rather than switching constantly to unreal mode.

Regards,
Shikhin

Re: hi-memory access in real-mode

Posted: Mon Mar 05, 2012 8:45 am
by Boba
Love4Boobies wrote:The earliest account of unreal mode, as far as I know, is this.
many thanks, Love4Boobies!