i c.Love4Boobies wrote:You misunderstand; a non-16-bit x86 implementation is any 32/64-bit x86 CPU (i.e., 80386 or later).
hi-memory access in real-mode
Re: hi-memory access in real-mode
Re: hi-memory access in real-mode
thanx. one more thing, is 'unreal mode' documented by say intel or others?Love4Boobies wrote:You've already been answered: by switching to unreal mode.
- Love4Boobies
- Member
- Posts: 2111
- Joined: Fri Mar 07, 2008 5:36 pm
- Location: Bucharest, Romania
Re: hi-memory access in real-mode
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.
"Computers in the future may weigh no more than 1.5 tons.", Popular Mechanics (1949)
[ Project UDI ]
[ Project UDI ]
Re: hi-memory access in real-mode
Hi,
Regards,
Shikhin
Hmm. I'm not too sure - if it is considerably safe, I might dump a bit of my code and use un-real mode.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.
Regards,
Shikhin
- Combuster
- Member
- Posts: 9301
- Joined: Wed Oct 18, 2006 3:45 am
- Libera.chat IRC: [com]buster
- Location: On the balcony, where I can actually keep 1½m distance
- Contact:
Re: hi-memory access in real-mode
Why change something that (apparently) works?I might dump a bit of my code and use un-real 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.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?
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
Hi,
Regards,
Shikhin
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.Combuster wrote: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.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?
Basically, after any BIOS call you'll have to restore unreal mode to be sure. Depending on guesswork is not smart.
Regards,
Shikhin
Re: hi-memory access in real-mode
many thanks, Love4Boobies!Love4Boobies wrote:The earliest account of unreal mode, as far as I know, is this.