long mode 32bit offsets?? huh??

[kubeos]

I was reading up on long mode=big real mode=flat mode and one tutorial says I can use the 32 bit registers to generate offsets into my 4gb segments... how? If I'm in real mode how can I use 32bit registers? Isn't real mode only a 16 bit mode?

eg.

mov edi,0x100000
mov al, byte [fs:edi]

If I'm in real mode (big real), then how can I move anything bigger than 0xffff into a register. And wouldn't edi translate as di?

Sorry, this just seems strange to me..

[urxae]

The basic trick is that the 32-bit registers are available in 16-bit modes (well, assuming it's at least a 32-bit processor ), but they are just not the default.
If you put an operand-size override prefix (0x66) or address-size override prefix (0x67) in front of an instruction, it switches between 16- and 32-bit sizes for operands and addresses, respectively[1]. The assembler should add these automatically where needed.
For example, your code would assemble to:

Code: Select all

00000000  BF00001000        mov edi,0x100000
00000005  648A07            mov al,[fs:edi]

when assembling 32-bit code, but to

Code: Select all

00000000  66BF00001000      mov edi,0x100000
00000006  64678A07          mov al,[fs:edi]

when assembled for use in a 16-bit mode. Note the extra 0x66 and 0x67 in the 16-bit code used to specify use of 32-bit registers. (the 0x64 in the second instruction is also a prefix, because the instruction uses fs; that's why the 0x67 address-size override prefix isn't the first byte of the instruction)


[1]: Assuming an x86-family processor running in a 16- or 32-bit mode, the rules are a bit different in 64-bit mode.

[kubeos]

Wow, I didn't know that at all.. That's awesome, now I can add an extended memory manager to my 16bit OS.

Thanks.

[urxae]

Oh, and I think I should mention that "long mode" != "unreal mode" (aka "big real mode") as you seem to think.
Long mode is the 'native' mode of 64-bit processors (though it's not necessarily 64-bit mode, that's technically just a sub-mode of long mode).

Another thing: beware that you have to be careful with segment registers in unreal mode, if you reload them without first switching to protected mode (even to the same value) they will revert back to have limits of 64k(-1). It doesn't do much good to have a 32-bit index into a segment that has a 16-bit limit...

Note: I've never written (much) 16-bit code, and have never used unreal mode. This is all just from stuff I read. Fair warning .

[Combuster]

If you reload a segment register in unreal mode, the 4GB limit will be kept. Just annoying to see that the wrong facts are kept in the circulation.

[urxae]

If you reload a segment register in unreal mode, the 4GB limit will be kept. Just annoying to see that the wrong facts are kept in the circulation.

It will? Sorry then, like I said I've never used unreal mode myself. I've never seen it mentioned before that it will work either, while having read multiple times that it won't...

[m]

Using unreal mode largely seems a hacking behaviour as it's not so native to a 16-bit environment...

I first came to understand this when I tried to switch back to real mode from protected mode.We have to load null segment selector before changing CR0.Maybe the idea of unreal mode is based on this.

I don't intend to use that because I'm not sure that would be so reliable or consistency...For example,the IP is still 16 bit long.

[Brendan]

Hi,

Using unreal mode largely seems a hacking behaviour as it's not so native to a 16-bit environment...

It's an artifact of the way protected mode works inside the CPU, and has been (ab)used by almost everyone, including Microsoft.

If you take a look at SMM (System Management Mode) you'll find it almost the same as unreal mode, and SMM is a standard part of 80x86 CPUs (that uses the same artifact of the way protected mode works inside the CPU).

I don't intend to use that because I'm not sure that would be so reliable or consistency...For example,the IP is still 16 bit long.

It doesn't work for CS (at least not without some severe difficulties, including being unable to reliably use BIOS functions). Because of this it's easier to use protected mode (and 32-bit) if CS limit must be > 16 bit for any practical purpose.

Usually "unreal mode" means using 4 GB limit/s for data segment register/s only (i.e. not CS, and usually not SS).


Cheers,

Brendan

[inflater]

My OS initializes the unreal mode, but I don't work with it practically, for now.

Using unreal mode largely seems a hacking behaviour as it's not so native to a 16-bit environment.

Hacking? I don't think so - HIMEM.SYS from MS-BOSS and other DOS clones are using unreal mode for accessing the HMA. A bit weird, but ... that is MS-DOS architecture

Yes, like others say - by using unreal mode, neither CS nor IP is affected by this - so the code is still limited to 64k. But nothing limits you for using UPX - but UPXing a part of the kernel that will set up some ISRs will certainly do no good. That's because I've splitted my OS to boot sector, bootloader (and boot-up drivers) and the main, BP kernel.

I write my OS in (un)real mode only for the simplicity of real mode and to access some memory larger than 1 MB without switching to pmode. Almost all of my functions are using BIOS and switching to RM and back to PM for these functions will be very slow.

Yes, combining unreal mode with BIOS can be a massacre, but you can construct a function that will copy the data from ES:BX or any other location to higher memory area and nextly free the memory located at ES:BX (filling zeros).

Anybody compared INT 13h and writing your own FDD driver in PM?

//EDIT number XYZ: I can't realize that Windows 3.1 was 16-bit PROTECTED mode... Bill Gates could say goodbye to 286 in Win3.1 era and remake Windows 3.1 to 32-bit. Sounds pretty curious, no? But, the 80386 was in market by 1993-1994...
If protected mode, only 32-bit for now

inflater