When reading
Intel® 64 and IA-32 Architectures Software Developer Manuals
and Some relevant tutorials about protected mode.
I came across with this question.
According to the manual and the blog
http://translate.google.com/translate?hl=en&sl=auto&tl=en&u=http%3A%2F%2Fwww.fh-zwickau.de%2Fdoc%2Fprmo%2Fpmtutor%2Ftext%2Fr_phys7.htm (translated by google)
The virtual address should be 16 + 32 bits,am I right?
So, what is the address with provided when programming using some low level assembly languages? Or, simply put it, what is the address we saw when we are debugging?
It's 32bits I assume.
Is the address in programming or debugging, linear address?
Thanks very much.
In usermode on modern x86 systems like windows/*nix, the virtual addresses are either 64-bit (though some bits are currently unused) or 32-bit.
Virtual addresses on x86 machines are always 32bit, usually with userspace on addresses 0 - 0x7FFFFFFF and kernel addresses 0x8000000 - 0xFFFFFFFF (there are exceptions how the address space is split, of course). The page you posted link to speaks about 16-bit real mode, where addresses are 16-bit but in fact there can be addressed only 1MB of memory, because also the segmentation was used (additional register).
I am not sure why you speak about 16 + 32 bits - maybe you mixed the virtual addressing and segmentation. There are still 16-bit segmentation registers, however, segmentation is deprecated an on most operating systems it is not used. See the Intel manuals you mentioned for details how this works.
Size of virtual addresses has nothing to do with low-level assembly, there you still usually write 32-bit apps (as long as you are not writing your own OS which requires some real-mode code to boot on x86).
Related
Involving the Windows operating system, a lot of things use the number 32, especially with Win32. I see it in everything from system folders:
C:\Windows\System32\
to system files:
C:\Windows\System32\win32k.sys
to Windows app development:
Develop a Win32 Application
The significance of the number 32 and computers makes me think 32-bit processors, but, if this is correct, why is there a need to explicitly mention 32-bit systems?
Googling around brought me to the Win32 API. This is, I presume, the main cause of its frequent use, but that doesn't change my question. The Windows operating system works perfectly fine on 64-bit systems.
Is Windows specialized for 32-bit systems?
Or is this just a historical thing (i.e. Windows and its API were developed before the 64-bit system emerged)?
Before Win32 there was Win16 (although perhaps maybe not using that name), and running 32-bit code was a special feature or it had special requirements, especially your CPU had to be able to do so.
Intel 8086 was a 16-bit CPU with 20-bit address space.
Intel 80286 was a 16-bit CPU with 24-bit address space.
Intel 80386 was full 32-bit, both registers and address space.
I recently noticed that the 32-bit version of Cheat Engine has its Thread Environment Block at a higher address than what is available to the 32-bit address space. To my knowledge user space is only accessible up to address 0x7FFFFFFF, but this TEB was located at 0xFFFDB000. Every TEB I ever saw started at 0x7EFD8000 or 0x7EFDB000 and subsequent TEBs continued downwards. I assume since Cheat Engine is a memory scanner it is to simplify the scanning process. The Process Environment Block had also been moved. Can anyone please tell me how this is possible? Is this a setting in the Portable Executable, by any chance?
for 32 bit programs available addresses from 0x00000000 to 0xFFFFFFFF but on x86 platform historical [0x00000000, 0x7FFFFFFF] was user space and [0x80000000, 0xFFFFFFFF] kernel space. but on x64, where 32bit apps run in wow64 subsystem this already not true - all 32bit range - [0x80000000, 0xFFFFFFFF] is user space. but for compatible reason system anyway restrict user address space of wow64 bit apps to 2GB [0x00000000, 0x7FFFFFFF] by default. for break this and have 4GB space need use flag
IMAGE_FILE_LARGE_ADDRESS_AWARE The application can handle addresses larger than 2 GB. in IMAGE_FILE_HEADER.Characteristics
On 64-bit editions of Windows, 32-bit applications marked with the IMAGE_FILE_LARGE_ADDRESS_AWARE flag have 4 GB of address space available.
It is known that there are different kinds of Virtual-address translations (x86) with the help of MMU such as Segmentation, Paging, Combined Segmentation-Paging (Paged segmentation, Segmented Paging), etc. Each having its own advantages and disadvantages.
My Questions:
1) Are general Operating systems like Linux/Windows use only one particular technique (like Paging)?
2) If 2 or more techniques are available for a given OS, when & where each one will be used?
Can we customize according to our needs?
3) If 'Paging' only is used, then x86's segment registers are used in what ways?
In general, modern operating systems on x86 use paging and not segmentation. This means the base address of segment registers is set to zero and the segment limit is set to the maximum. Paging is used to map virtual addresses to physical addresses, this gives the OS fine grained control of the address space of a process, protection between processes, and protection between privileged (kernel) and user address space. Segments are still used in x86 for special purposes:
to run legacy operating systems and applications in a virtual environment
to efficiently access thread local storage for each thread in a multithreaded application (with thanks to #PaulA.Clayton for pointing this out).
Microsoft Windows switched from segmentation to a flat, linear memory model with Windows 95.
http://technet.microsoft.com/en-us/library/cc751120.aspx
Windows 95 addresses this issue by using the 32-bit capabilities of the 80386 (and above) processor architecture to support a flat, linear memory model for 32-bit operating system functionality and Win32-based applications. A linear addressing model simplifies the development process for application vendors, and removes the performance penalties imposed by the segmented memory architecture.
In order to run old Win16 applications (Windows 3.1) Windows 95 ran a 16-bit virtual machine where all Win16 applications ran. Newer, 32-bit applications ran in separate address spaces using the paging facility of the MMU.
Here's the relevant description from the link above
I am running Windows XP on an Intel x86 machine and I got an error in the instruction at memory location 0x00000001.
I am not worried about debugging the error, but I was interested to know what instructions would generally be located at the very begging of memory.
The only processors I have written low-level code for are PIC microcontrollers, and I know that the first memory location would be a GOTO and then the interrupt vectors.
Windows guarantees that the first 64k and the last 64k of memory will always cause an access violation to read or write. This makes detecting null pointer dereferences easier.
See the graphic in this page below the heading
Free, Reserved, and Committed Virtual Memory
http://msdn.microsoft.com/en-us/library/ms810627.aspx
That is not the actual physical address space 000001. XP is a modern virtual paged memory OS so each application gets its own address space.
I believe that the zero page of a process's address space is deliberately inaccessible on Windows to help detect null pointer errors, in which case there's nothing there.
Imagine the same hardware running Windows XP 32bit, or Windows XP 64bit..
(being that it's a 64bit processor currently running XP 32bit)
2gigs of ram...
Will the performance of Visual Studio benefit from going to the 64bit OS?
The hardware and ram is currently out of my control... If I could throw more hardware or ram at it I would.
For 2 GB of RAM, most likely not. The biggest advantage of 64-bit is the additional address space. With 2GB of physical RAM, 32-bit OS's can map all of physical memory.
Above 3GB 64-bit OS does give some benefit, since some of your physical memory may be unusable on 32-bit OS's due to devices mapping physical addresses for their own use.
And obviously if you want to use above 4 GB of memory you should absolutely go for a 64-bit OS.
Yes, if you have sufficient physical memory, you will gain some benefits from running Visual Studio in 64-bit Windows as described in Visual Studio: Why is there no 64 bit version? (yet):
Doesn’t being a 64 bit application save you all kinds of page faults and
so forth?
A 64 bit address space for the process
isn’t going to help you with page
faults except in maybe indirect ways,
and it will definitely hurt you in
direct ways because your data is
bigger. In contrast a 64 bit
operating system could help you a lot!
If you’re running as a 32 bit app on a
64 bit OS then you get all of the 4G
address space and all of that could be
backed by physical memory (if you have
the RAM) even without you using 64 bit
pointers yourself. You’ll see
potentially huge improvements related
to the size of the disk cache (not in
your address space) and the fact that
your working set won’t need to be
eroded in favor of other processes as
much. Transient components and data
(like C++ compilers and their big .pch
files) stay cached in physical
memory, but not in your address space.
32 bit processes accrue all these benefits just as surely as 64 bit
ones. (my emphasis added)
not unless you add more RAM.
In fact 64 bits might even slow you down because 64-bits Windows sometimes have to load both 32-bits and 64-bits versions of a same DLL in RAM.
Add more RAM is the way to go because if you are using Windows 7 or Vista they aggressively caches disk files in RAM.