OSDev.org

how vm32 works in amd64 platform?
if it just a 32bit code, 64 bit kernel how to process it?

32bit code has to run in a 32bit segment, I'm not sure if you can run 32bit code in the kernel, although I don't see why not.

You can run 32-bit code at _any_ privilege level. Simply set up a GDT entry just like old 32-bit code would, and jump to an address in that segment. It then runs in compatability mode, and runs exactly like 32-bit code, except for exception/interrupt handling, which uses the new method, and the sysenter instruction, which is replaced with syscall and has different semantics.

Of course, this all assumes that long mode is enabled first.

See the wiki for more information (look for x64, amd64, intel em64t, etc.)

Mike

I think there is an emulation layer that lies on top of 64-bit code so it can run ANY 32-bit application.

Like WOW64.

In longmode, you can still use 32bit and 16bit segments which allows the 64bit kernel to run 64, 32 and 16 bit software all at the same time.

WOW64 (Windows on Windows 64bit) is mainly just a collection of 32bit DLLs, the stuff for actually running the processes is in either the kernel or the HAL.

AR wrote: In longmode, you can still use 32bit and 16bit segments which allows the 64bit kernel to run 64, 32 and 16 bit software all at the same time.

can you confirm that ? esp. for 16 bits and the "segments" word ? (i thought there were no segments anymore in long mode -- and if there were 16 bits segments, using VBE bios wouldn't be that hard, right ?)

Pype.Clicker wrote:

AR wrote: In longmode, you can still use 32bit and 16bit segments which allows the 64bit kernel to run 64, 32 and 16 bit software all at the same time.

can you confirm that ? esp. for 16 bits and the "segments" word ? (i thought there were no segments anymore in long mode -- and if there were 16 bits segments, using VBE bios wouldn't be that hard, right ?)

I can confirm that you can use 16 and 32 bit modes, and that they both support segmentation (although only as a superficial thingy on the paging layer, but it's logically equivalent with the normal way of doing stuff). I've not seen a problem using the VBE bios (now that I think of it) aside from being required to use 16/32-bit mode which not all have and which not all properly support.

I do expect WinXP to use it too, so that would kind of guarantee a usable interface up to a given level.

Think it's time for me to get that stuff working, and get back to OSdev. I feel like it...

oh wait... *remembers* was saving money for an amd64 computer so I could test anything...

Hi,

Pype.Clicker wrote:

AR wrote:In longmode, you can still use 32bit and 16bit segments which allows the 64bit kernel to run 64, 32 and 16 bit software all at the same time.

can you confirm that ? esp. for 16 bits and the "segments" word ? (i thought there were no segments anymore in long mode -- and if there were 16 bits segments, using VBE bios wouldn't be that hard, right ?)

IIRC, and using the terminology that AMD use, "long mode" has 2 different submodes (that are determined by CS) - "64 bit Mode" (64 bit registers, additional registers, 64 bit addressing, 64 bit operands), and "Compatibility Mode" which is intended to run 32 bit and 16 bit applications that were originally designed for normal/legacy protected mode.

More specifically, from section 1.2.3 "Compatibility Mode" in "AMD64 Architecture Programmer's Manual Volume 1: Applications Programming" it says:

Compatibility Mode --the second submode of long mode-- allows 64 bit operating systems to run existing 16 bit and 32 bit x86 applications. These legacy applications run in compatibility mode without recompilation.

Applications running in compatibility mode use 32-bit or 16-bit addressing and can access the first 4 GB of virtual-address space. Legacy x86 instruction prefixes toggle between 16-bit and 32-bit addressing and operand sizes.

As with 64-bit mode, compatibility mode is enabled by the operating system on a per code-segment basis. Unlike 64-bit mode, however, x86 segmentation functions the same as in legacy x86 architecture, using 16-bit or 32-bit protected mode semantics. From the application viewpoint, compatibility mode looks like the legacy x86 protected mode environment. From the operating system viewpoint, however, address translation, interrupt and exception handling, and system data structures use the 64-bit long mode mechanisms.

AFAIK this basically means that 16-bit protected mode code and 32 bit protected mode code can be run like normal if the 64-bit kernel/OS supports it, which would include the 16 bit protected mode interfaces used by the VBE BIOS (and the protected mode interfaces for Plug & Play, APM, PCI, etc).

In addition, the MSRs used by the SYSCALL and SYSRET instructions have been expanded to include a 64 bit "RIP target for long mode" and a 64 bit "RIP target for compatibility mode". Therefore using SYSCALL where possible (and by adding code to check the callers CS to software interrupt handlers) a 64 bit operating system can have seperate interfaces for both while still allowing 16-bit and 32-bit protected mode software to use the entire 4 GB (without reserving any of the 4 GB for the kernel/OS's own use).

I guess what I'm saying is that not only can a 64 bit OS run software designed for 16-bit and 32-bit protected mode, but it can also give the software access to more memory than a 32 bit protected mode OS possibily could, and that applications designed for 16-bit protected mode, 32-bit protected mode and 64-bit long mode can all happily co-exist (either as seperate tasks, or within the same task), with the OS switching between modes by simply changing CS.

[EDIT]
I just thought that to avoid all confusion I'd point out that "16-bit protected mode" is not the same as real mode or virtual 8086 mode, and that real mode and/or virtual 8086 are not supported in any sub-mode of long mode.
[/EDIT]


Cheers,

Brendan

Food for thought: Windows XP Professional x64 edition has removed all support for 16 bit apps. This will probably mean that in the future (unless you're using linux) any 16/32 bit code will probably be running under an emulator regardless of what an x64 processor supports at the hardware level.
As Virtual PC is owned by Microsoft and it would be of benefit for Microsoft to terminate all that old 'legacy' software, might I propose that we all be very very nice to the BOCHS and DOSBox developers. That way all the mess I've collected over the last 30 years can keep on running without dragging out the 286 every few months.

AFAIK, once in long mode, no 16-bit protected mode code is supported at all. The bit in the GDT entry used to specify 16-bit code is used under long mode to specify 64-bit code. Therefore, 16-bit protected mode cannot exist.

16-bit pmode _does_ exist on x64 machines before long mode is enabled.

The CS, DS, ES registers still exist, but only to specify mode and protection information. FS and GS are fully functional, probably because FS and GS are used by various OSes to store thread/process/cpu-local data. I know Windows uses it, and Linux probably does as well.

Everything here is also in the FAQ, at http://www.osdev.org/osfaq2/index.php/Tell%20me%20about%20x86%2064%20bits%20CPU%20.... (P.S. Why are the FAQ page names so long! It would be so much easier to just be called Amd64Cpu or something, rather than "Tell me about x86 64 bits CPU ...")

Hopefully I cleared up some confusion, and didn't add to it

Mike

Hi,

Mike wrote:AFAIK, once in long mode, no 16-bit protected mode code is supported at all. The bit in the GDT entry used to specify 16-bit code is used under long mode to specify 64-bit code. Therefore, 16-bit protected mode cannot exist.

16-bit pmode _does_ exist on x64 machines before long mode is enabled.

How confused can you be? Let me count the ways....

Once upon a time there was no protected mode (8086, 80186, etc). Then Intel decided to introduce protected mode (probably due to 1 MB memory barriers, but maybe influenced by other factors). This was "16 bit Protected Mode" and was introduced with the 80286!

Read this carefully, because it can be hard to understand (and yes I do mean the 80286).

16 bit Protected Mode used a GDT and had segment bases and limits, and also supported hardware task switching, but it was before anything was 32 bit (no EAX, no paging, no virtual 8086, etc). Intel also messed it up because they didn't provide a way to switch back into real mode. Instead you had to set a value in the CMOS and reset (using the keyboard controller) which was ugly and slow.

This 16 bit Protected Mode is what Microsoft used for old versions of Windows (e.g. Windows 3.0).

Anyway, one day Intel got bored and invented "32 bit Protected Mode", releasing it with the 80386. This is what we are all mostly familiar with .

32 bit Protected Mode was much better, and allowed you to run 16 bit code and 32 bit code (and added paging, virtual 8086, etc). Microsoft eventually released Windows 95, and everything was good (or good enough), except for compatibility problems with earlier "16 bit Protected Mode" applications.

To solve this, Intel's 80386 "32 bit Protected Mode" supported barely enough old 16 bit Protected Mode to allow old software to work. This includes the 16 bit TSS structure and nothing else (because everything else can be done with 32 bit Protected Mode, including running 16 bit binaries). All Microsoft did was add the "80286 style" API to the new 32 bit OS (Windows 95). The 16 bit TSS structure still lingers on as a lonely reminder of what once was (like a fart in an elevator that still smells weeks later, or the gate A20 thing).

Anyway, when "16 bit Protected Mode" was first released no-one really bothered using it (it was crap and "32 bit Protected Mode" came soon after). I'm not surprised that after about 20 years Microsoft are dumping it (although I'm surprised it took so long).

Then came "Long Mode"...

Long Mode still has 2 "sub-modes", as explained above in my earlier post (in the quote from the AMD manual).

In the "64 bit" sub-mode the GDT isn't used much at all. Instead there's MSRs for the 64 bit base address for GS and FS (MSR 0xC0000100 and MSR 0xC0000101). Of course the base addresses for CS, DS, ES and SS are zero (and none of them have any limit at all).

In Long Mode, a code segment descriptor (in the GDT or LDT) uses bit 21 to determine if it's a "64 bit Long Mode" code segment or a "Compatibility Long Mode" code segment. If you do some cross-checking you'll find that this bit is reserved (must be zero) on older CPUs.

Basically, they've used this previously reserved bit 21 and called it "L", but the original default size bit (or bit 22, called 'D') still selects the default operand size. My AMD manual also says that if the 'L' bit is set, then the 'D' bit must be clear (that combination might be good for future 128 bit code ::)).

This gives 3 possible code types for long mode:
[tt] L = 1, D = 1 - A 64 bit code segment (the 64 bit sub-mode of long mode)
L = 0, D = 1 - A 32 bit code segment (the compatibility sub-mode of long mode)
L = 0, D = 0 - A 16 bit code segment (the compatibility sub-mode of long mode)[/tt]

Now, an operating system that is designed for Long Mode can switch between 64 bit "64 bit long mode" software and 32 bit "compatibility long mode" software and 16 bit "compatibility long mode" software just by loading CS. This means that an OS designed for Long Mode could even allow 64 bit code, 32 bit code and 16 bit code to be mixed in the same application .

Of course all of the above is Long Mode and should not be confused with Legacy Mode. Legacy mode is the same as 32 bit Protected Mode, with virtual 8086 and everything else we're all used to.

Anyway, "Long Mode" can run 16 bit software designed for 32 bit Protected Mode (and might run 16 bit software designed for 16 bit Protected Mode, but definately won't run real mode code designed 8086).

I hope this all doesn't confuse things more...


Cheers,

Brendan

I'm pretty sure Windows x64 supports 16bit protected apps still, it's the real mode 16bit apps support that has been removed. You can't run DOS programs at all, period (Windows comes up with a box saying "This program is not compatible with this version of Windows but is otherwise valid" or something along those lines).

AR wrote: I'm pretty sure Windows x64 supports 16bit protected apps still, it's the real mode 16bit apps support that has been removed.

I recall reading something on MSDN that warned developers about migrating their installers to Win64. The problem is that some installer bootstrap programs are Win16 (i.e. -- 16-bit protected mode), and therefore won't run.

So, I'm pretty sure that MS does not support Win16 apps on Win64.

KB article

Brendan wrote: How confused can you be?

Oops! :-[

Just shows you what happens when I post without verifying what I am saying. My apologies!

Mike

Brendan wrote: Hi,

Basically, they've used this previously reserved bit 21 and called it "L", but the original default size bit (or bit 22, called 'D') still selects the default operand size. My AMD manual also says that if the 'L' bit is set, then the 'D' bit must be clear (that combination might be good for future 128 bit code ::)).

This gives 3 possible code types for long mode:
[tt] L = 1, D = 1 - A 64 bit code segment (the 64 bit sub-mode of long mode)
L = 0, D = 1 - A 32 bit code segment (the compatibility sub-mode of long mode)
L = 0, D = 0 - A 16 bit code segment (the compatibility sub-mode of long mode)[/tt]

Is it just me, or do I see a contradiction here? FYI, I don't know much about 64 bit, since I didn't look at it..
But according to what you just said, you're wrong. It should be
[tt]L = 1, D = 0 - A 64 bit code segment (the 64 bit sub-mode of long mode)
L = 0, D = 1 - A 32 bit code segment (the compatibility sub-mode of long mode)
L = 0, D = 0 - A 16 bit code segment (the compatibility sub-mode of long mode)[/tt]

Or am I wrong ??