What is at address 0?

This is a discussion on What is at address 0? within the A Brief History of Cprogramming.com forums, part of the Community Boards category; All of you scare me....

  1. #16
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,598
    All of you scare me.

  2. #17
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Quote Originally Posted by BobMcGee123
    Feel free to elaborate?!
    Protected mode is a feature of the CPU. The OS just enables it.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  3. #18
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,598
    Especially Bob.


    No seriously, the OS just enables the PE bit thus throwing the CPU into protected mode. If you google for 'enabling protected mode in x86' you will probably find some source to do just that.

    The process is quite simple and easy when you have total access to the system. In other words you cannot do it after booting into Windows unless you find a way to elevate segment descriptors to ring 0 or requested privilege level 0 (Intel calls it RPL0). Your segment descriptor contains all the information relative to your RPL, descriptor size (size of the block the descriptor refers to), etc, etc. This piece of information is used every time you access memory via a descriptor - essentially every time you access memory. So let's say you attempt to access memory at a higher (0 being highest) RPL or PL. The CPU will compare your RPL in your descriptor to the descriptor who controls the area you are requesting access to. If your RPL is lower (meaning higher in value) then the memory access will not be allowed. You cannot read from it or write to it. There is a lot more to the RPL mechanism and you can request to elevate your RPL, however the OS will most certainly reject this request as they will probably provide an OS-specific mechanism to adjust your RPL so that it can directly control the RPL's of all applications.

    Notice I said probably. Microsoft Windows does provide such mechanisms - but often it provides them on accident. Several API calls must adjust your RPL to perform their operations and for some odd reason MS Windows will NOT re-adjust your RPL back down. This means that after the API call, your RPL is at 0 which is a serious problem - especially if you are not a well-behaved program.

    Fordy knows much more about this than I and the information I'm gathering is straight from the Intel docs. Intel documentation is written in generic form and does not apply to Microsoft Windows or any specific operating system. They simply tell you how do accomplish tasks and then leave the implementation to the operating system designers. This means there are a plethora of ways to get around the RPL mechanism.

    Protected mode has been around for a very long time - since the 80386 processor. It is just now that we, and MS, are using it everyday. We were stuck in DOS's horrid 1MB limit not because of DOS but because that's how Intel designed real-mode and virtual-8086 mode programming to work. It is DOS's fault that it continued to insist on operating in real mode. We could have had a simple 32-bit DOS but MS opted for the visual style of Windows 3.0/3.1. OS/2 is also another example of a first dive into the 32-bit operating system world. Both, however, must follow the same basic guidelines that Intel layed out for protected mode programming. But as to the memory management mechanisms they employ and use were solely up to the designers.

    I highly recommend reading the Intel technical ref docs on both the Xeon and x86 32-bit platforms. They are extremely interesting reading if you are a techy and IMO they will begin to shed some light on why Windows and other operating system conduct business the way they do. The x86 CISC instruction set is extremely complex in nature (thus CISC), however the underlying principles are rather straightforward and simple.

    The only requirements prior to flipping into protected mode are that you setup the global descriptor table (GDT), possibly the local descriptor table(LDT), the interrupt descriptor table (IDT) - similar to the interrupt vector table (IVT) in real mode, 2 segment descriptors, and then flip the PE bit.

    However when you do this you should have drivers and the kernel ready to use because now all access to memory is protected. This is why everything is now based on the driver model. Intel does not think it is a good idea for any program to be able to access any portion of memory any time it chooses. This is very wise of them and so now to access things like the sound card, video card, 3D accelerators, etc, etc, we must go through a driver API - built by using the Microsoft DDK or device driver kit. The API then acts as a layer between the software and the hardware - the HAL, or hardware abstraction layer as DirectX docs call it. You are never supposed to directly access video memory or any memory that does not belong to you.

    So:

    Code:
    unsigned char far *pVideoMem=MK_FP(0xA000,0);
    Is completely illegal, won't work, and is deprecated. You also cannot do the simple DJGPP near pointer protected mode hack in which it was possible under Windows 95/98 and DOS to access the linear frame buffer of the video card via a near pointer. Thus to plot pixels you did not have to go through the DPMS by calling the farnspoke* family of functions and/or directly using DPMS functions.

    The current model is much better. Just imagine trying to access the 3D accelerator hardware directly to perform some arcane operation. It would only work on certain computers with certain video cards, etc, etc. Now with OpenGL and DirectX, as long as the driver supports the function/operation, it can be done. To perform operating system functions you no longer have to setup registers, perform interrupts, etc, etc. You just call the correct function with the correct parameters and boom.....the OS takes care of it regardless if you have restrictions that it does not have. See the OS is now truly the boss and everything you do must go through the boss first. DOS was not truly boss, but be assured Windows XP is watching you every step of the way and will let you know when you are venturing into territory it does not approve of. It's not perfect and if it's made with code, it can be broken with it, but it's very good and much better than anything we've had previously.

    That is why in game programming you are almost never allowed to directly access a surface, and if you are, it necessitates a huge slowdown in your code. But if you dig deeper you find out that the API does allow you to access the surface w/o taking a performance hit, however, you cannot get/create a pointer to it.
    DirectX does this through COM and simply gives you a pointer to an interface that then is responsible for accessing the surface. In other words the interface is accessing the HAL which is then doing the nitty gritty work of talking to the hardware. It's a beautiful design IMO.


    I like the current setup far better than the 'old school' way of doing things. Sorry so long, but you asked for it Bob.
    Last edited by VirtualAce; 07-15-2006 at 05:25 PM.

  4. #19
    ---
    Join Date
    May 2004
    Posts
    1,379
    Too long, Bubba

  5. #20
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,598
    As always. .

    Hey folks ask and so I respond. They asked me to do it, honest, they did. Blame it on Bob.


  6. #21
    Dump Truck Internet valis's Avatar
    Join Date
    Jul 2005
    Posts
    357
    Quote Originally Posted by BobMcGee123
    I've found that although Intel is the chief market big guy, it's instruction set is built on a series of hopeless hacks and kludges just waiting to explode.
    I'm actually impressed with how much intel has been able to do carrying around all it's old luggage. Many of the complex instruction have been rendered useless because a set of simpler instructions which perform the same task does so faster (jcxz and xlat for instance); more crap examples: lmsw and smsw (mov is used now).
    MMX really was a hack (although handy), however sse1/2/3 are all legitimate editions.

    I've always liked assembly but never the x86 architecture. It has unnecessarily complex hardware to solve stupid problems. As it has proved, many of its complex instructions are useless, and its out-of-order execution hardware--although necessary for how few registers it has--is fat and energy hungry. All that should be passed off to the compiler which are proving very capable and always being extended (gcc with its new auto-vectorisation research or whatever you want to call it and higher level languages like clean producing efficient code).

    Intel has already taken a quasi-RISCy route with its itanium.

  7. #22
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,598
    And yet Intel is the one who won out over those things that grow on trees and another fading memory once known as the Mac.

    You fail to give credit where credit is due.

    And BTW by the time that MMX was even useful, video hardware and accelerators had far surpassed it thus eliminating the need for it. And how do you call it a hack? Just because it uses the floating point registers to do integer arithmetic?

    Some of your claims IMO are a bit out there. CISC might be a more complex instruction set and slower than RISC, but we see how far RISC got in the computer world. We are here now today because of CISC and although the underlying implementation may now be more RISC in nature, Intel will always be CISC since changing the entire set of x86 opcodes to RISC would be ludicrous.
    Last edited by VirtualAce; 07-16-2006 at 02:16 AM.

  8. #23
    Dump Truck Internet valis's Avatar
    Join Date
    Jul 2005
    Posts
    357
    I call MMX a hack because it was just a bit of a quick fix, it worked well, it didn't ruin anything else, it was just a patch. I'm not saying it's a worthless architecture. I just think we need a reform, x86 has done well--but time has passed and we have learned quite a bit. Some of the newer architectures are using some older techniques which failed (but are seen with new light).

    I think RISC failed for two main reason: 1) it was cost inneffective. 2) Too much software already existed, software companies weren't willing to port their applications, and the hardware designers didn't create software to effectively help companies port software.

    Hardware is reaching a point where we just can't squeeze a whole lot more performance out of chips while keeping heat down among other things; Intel and AMD have realized it's much easier to just go parallel. Not a lot of apps are written to take advantage of multi-core or multi-chip hardware (therefore current apps won't take *full* advantage of the new chips anyway) so I think it would be a good chance to break away from x86 and supply the tools needed to do so.
    The conroe chip is pretty impressive but still tied too tightly to compatability.

  9. #24
    The superhaterodyne twomers's Avatar
    Join Date
    Dec 2005
    Location
    Ireland
    Posts
    2,262
    Ok, does anyone know what the address at 0X2A is?

  10. #25
    and the Hat of Clumsiness GanglyLamb's Avatar
    Join Date
    Oct 2002
    Location
    between photons and phonons
    Posts
    1,109
    Quote Originally Posted by Bubba
    The CPU will compare your RPL in your descriptor to the descriptor who controls the area you are requesting access to. If your RPL is lower (meaning higher in value) then the memory access will not be allowed. You cannot read from it or write to it.
    Unless you work with things like call gates or task gates.

  11. #26
    Just Lurking Dave_Sinkula's Avatar
    Join Date
    Oct 2002
    Posts
    5,006
    Quote Originally Posted by twomers
    Ok, does anyone know what the address at 0X2A is?
    What's at address 0? What's at address 0x2A? What's at address x? -- Read the processor manual.
    7. It is easier to write an incorrect program than understand a correct one.
    40. There are two ways to write error-free programs; only the third one works.*

  12. #27
    The superhaterodyne twomers's Avatar
    Join Date
    Dec 2005
    Location
    Ireland
    Posts
    2,262
    >> What's at address 0? What's at address 0x2A? What's at address x? -- Read the processor manual.

    What? Where it describes the meaning/function of every memory address?

  13. #28
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Here, I've written a small program that will explain to you every memory address. Stream the output into a file and print it as a handy reference.
    Code:
    #include <iostream>
    #include <limits>
    #include <cstdlib>
    #include <iomanip>
    
    int main()
    {
      for(std::size_t a = 0; a < std::numeric_limits<std::size_t>::max(); ++a) {
        std::cout << "Address: 0x" << std::hex << std::setfill('0') << std::setwidth(sizeof(std::size_t)*2) << a << "\tStuff, probably.\n";
      }
    }
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  14. #29

    Join Date
    May 2005
    Posts
    1,041
    >>This piece of information is used every time you access memory via a descriptor - essentially every time you access memory

    ya, I had absolutely no idea what is actually going on behind the scenes when you access memory (well, in protected mode), that the 'memory address' you use in a program is, as you said, an index into a descriptor table, which ultimately gets divided up into 'pages' blocks...etc, before you get a 'real' memory address. I'm still not totally sure I have any friggin' clue whats going on *kicks computer case*

    I wonder what is going on behind the scenes when you access memory on a 64 bit platform :-0


    >>The x86 CISC instruction set is extremely complex in nature (thus CISC), however the underlying principles are rather straightforward and simple.

    Again, this is something I never appreciated, or even thought about, until I tried dabbling with assembly. asm isn't really 'my thing,' but it if you *really* want to know how a computer works, you have to pick up some sort of assembly. Basically, I didn't realize that something 'simple' such as adding integers together is considered 'high level,' and that with RISC instruction sets you are forced to implement these relatively mundane things yourself, at the bit manipulation level.

    The only requirements prior to flipping into protected mode are that you setup the global descriptor table (GDT), possibly the local descriptor table(LDT), the interrupt descriptor table (IDT) - similar to the interrupt vector table (IVT) in real mode, 2 segment descriptors, and then flip the PE bit.
    Yeah! It's so easy!!!!

    >>Sorry so long, but you asked for it Bob.

    Sorry it took me so long to read it! Thx for the reply!

    >>MMX really was a hack (although handy),
    The only thing I have heard consistently was that it was useful for was automatic color saturation.
    I'm not immature, I'm refined in the opposite direction.

  15. #30
    The Right Honourable psychopath's Avatar
    Join Date
    Mar 2004
    Location
    Where circles begin.
    Posts
    1,070
    This thread actually makes me want to finish my OS kernel.

    must.....stay.....focused....
    Memorial University of Newfoundland
    Computer Science

    Mac and OpenGL evangelist.

Page 2 of 3 FirstFirst 123 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. What does this do (Windows API)?
    By EVOEx in forum Windows Programming
    Replies: 4
    Last Post: 12-19-2008, 10:48 AM
  2. Writing array, to file
    By zootreeves in forum C Programming
    Replies: 9
    Last Post: 09-08-2007, 06:06 PM
  3. I thought pointers were pointers...
    By keira in forum C Programming
    Replies: 19
    Last Post: 08-16-2007, 12:48 AM
  4. DX - CreateDevice - D3DERR_INVALIDCALL
    By Tonto in forum Game Programming
    Replies: 3
    Last Post: 12-01-2006, 07:17 PM
  5. pointers
    By InvariantLoop in forum C Programming
    Replies: 13
    Last Post: 02-04-2005, 09:32 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21