Re: 66H and 67H override prefixes.


<h.samso@xxxxxxxxx> wrote in message
news:e6e18a46-e0fc-4e96-8fc1-24b5e8fe818b@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On 1 mar, 02:50, "Harold Aptroot" <harold.aptr...@xxxxxxxxx> wrote:
<h.sa...@xxxxxxxxx> wrote in message

news:5c91c056-7798-490d-9c6a-60d9c10ecf82@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Hello!

Interesting part of Barry B. Brey's "The Intel Microprocessors" Sixth
Edition, that tells how width of addresses and registers is toggled.
This permits the use of 16-bit instructions in 32-bit mode (protected
mode)
but also the use of 32-bits instructions in 16-bit mode (of course,
only 386
and above CPUs).

[...]

Unfortunatly the formatting was killed by my news reader,
But anyhow, I don't get it.
Why did you quote a huge piece of text about the operand size and address
size overrides?
It even contains errors, though I suspect they are due to the age of the
quoted text.
Is there something special in there that I didn't notice?

ps: you also posted in c.l.a.x..


Hello!


With cut&paste the formatting is restored! :)

I thought it was interesting, as it is an information that is usefull
for programming in the 16bit space (real mode) with the i386
instructions.

It was not very clear that this possibility did exist and how did it
function.
Somebody has called it "unreal mode". I have yet to test this kind of
intel CPU programming. I am more profound of the genuine 8086 than of
the newer 386s and Pentiums.

http://en.wikipedia.org/wiki/Unreal_mode.

As it seems, having 32bits indexes in unreal mode, it is possible to
access all of memory from real mode? Great! :)
This seemed to me a better use of the i386 without the burden of
memory and tasks descriptors.


unreal mode still requires a bit of setting up, in particular, a GDT needs
to be set, and one has to temporarily transition to protected mode, set some
things up, and transition back again, ...

but, as a big plus point, if set up right one can still use the bios and
other things (usually, CS, DS, ES, and SS remain 16 bit, but one uses 32
bits for maybe FS and GS).


the main use for unreal mode is usually in getting an OS loaded, or also
transitioning back and forth (between pmode and unreal mode), to allow one
to continue using the BIOS for those things the BIOS does (may save having
to write as many drivers, ...).

as for using unreal mode as a consistent operating mode...
well, there is the problem that I am not aware of any compilers which target
unreal mode;
more so, using it as such would be much more hairy and misbehaved than would
be using protected mode...
(although, it may be a reasonable option if the app is primarily real-mode,
and the primary use of unreal mode is to have extended memory access, and
they are in a situation where XMS was not better suited...).

if done right, one can retain access to the BIOS and/or DOS through the use
of crafty code (or by use of DPMI, which will still work in Windows but if
one uses DPMI in Windows they may as well just write native 32-bit code...).

for pure PMode operation, while still using the BIOS (and not via DPMI), an
idea here would be to set up the PM IDT for many interrupts to essentially
jump back to real-mode and redirect the call through the IDT (although, for
PMode operation, it is a good idea to remap the IRQ interrupts and similar,
such that PM interrupts such as GPF and similar don't collide with the BIOS,
but during the transition they can be remapped back to their appropriate RM
vectors...). likewise, BIOS interrupts could also be remapped (and DOS
interrupts wrapped, if running on DOS), potentially allowing one to continue
using direct BIOS calls from PM...

OTOH, one could also implement a 32-bit fake-DOS (no DOS present, but it is
emulated) using related techniques.


or such...



Greetings,
H.Samso (thebitsclub.tripod.com)


.

Relevant Pages

  • Re: Graphic options for DS10L
    ... I take it the BIOS is made up of binary 8086 architecture code? ... That could be IA-32e instructions, or it could be the decades-old 8086 instructions. ... As Fred indicates in the following, the controller itself will very likely have the minimal instruction set in the firmware, and just needed to get the controller active in VGA mode. ... The EFI byte code and the byte code engine is intended to avoid having x86 instructions in the card, to allow the firmware to be more portable across platforms -- space in the controller firmware storage area is obviously limited, which is why systems not based on x86 presently have a way to process the x86 instructions out on the controller storage. ...
    (comp.os.vms)
  • Re: I need Help. "No Safe Mode" and...? Possibly an opportunity to recover.
    ... "For someone who knows what they're doing, changing the bios to boot from ... but clear instructions are in the MSKB or link I give them ... Also having experienced the boot to windows problem early on as a beginner, ... Anyone can think of dozens of hardware related reasons why someone can't get ...
    (microsoft.public.windowsxp.basics)
  • Re: keyboard and mouse get hang immediately after moving the mouse
    ... Even if you are using an x86-based device, BIOS has nothing to ... do with handling of interrupts for CE, other than, maybe being responsible ... I have checked out the ISR in BIOS and with SysIntr registry by ... Since it affects the keyboard and mouse, though, you could trace what ...
    (microsoft.public.windowsce.embedded)
  • RE: PCI bridges & interrupts
    ... > I'm having a strange problem with interrupts, PCI bridges, and ... The BIOS settings have PnP OS ... > riser, followed by diffs when booted with the riser. ... infrastructure to route interrupts, and if your BIOS screws it up, ...
    (freebsd-hackers)
  • Re: Problems with 6 Serial Port in ICOP VDX-6327
    ... addresses and interrupts specified in your CE registry are shown in the BIOS ... Once you have a single port working, ...
    (microsoft.public.windowsce.platbuilder)