Announcement

Collapse
No announcement yet.

C and Far Pointers

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • C and Far Pointers

    Hi C gurus,

    I noticed that in C there is this concept of Far Pointers. What
    is that ? A pointer is a pointer not ? How can they be far ?

    (forgive me my ignorance or unwitty).

    ------------------
    So here we are, this is the end.
    But all that dies, is born again.
    - From The Ashes (In This Moment)

  • #2
    Steven,

    IIRC, far pointers are for 16bit, for 32bit you dont need them

    ------------------
    Wash DC Area
    Borje's "Poff's" is likely the BEST tool for learning PB.. http://www.tolkenxp.com/pb

    Comment


    • #3
      A "far pointer" isn't a C construct, as such. It's related to the hardware
      architecture. If you've done any 16-bit programming on Intel-type PCs, you
      may remember that memory locations are specified as an offset within a given
      segment. Often, for convenience, a program might deal only with the "offset"
      part, using an implied default segment. This 16-bit offset with an implied
      segment is a "near" pointer: it can only address items within the range of
      the implied segment. A "far" pointer combines both the segment and offset
      information, allowing much larger amounts of memory to be addressed.

      Under 32-bit Windows, you don't get to use segments at all-- a horrendous
      design decision for many reasons. But, the offsets are now 32 bits, so it's
      possible to address up to 4 GB of memory without needing to use segments.
      That must have seemed like a lot, back when they designed Windows 95,
      though you'd think Bill "640k ought to be enough for anybody" Gates might
      have had reason to think twice about it.

      Anyway... the upshot of all this is, in 32-bit Windows, a "near" pointer is
      the same thing as a "far" pointer. All pointers are the same size. This may
      be changing again with the 64-bit processors-- we shall see.

      ------------------
      Tom Hanlin
      PowerBASIC Staff

      Comment


      • #4
        >Under 32-bit Windows, you don't get to use segments at all-- a horrendous design decision for many reasons

        Horrendous? I kinda like 32 bits of linear address.. no more screwing around with 64K blocks, or segments, or "selectors" (remember those?)

        Pray enlighten my humble self why eschewing the segmented model was nonappropos.

        MCM


        Michael Mattias
        Tal Systems (retired)
        Port Washington WI USA
        [email protected]
        http://www.talsystems.com

        Comment


        • #5
          The Far Pointer is not just found in C. The Intel CPUs still use them. Despite rumours to the contrary, x86 CPUs still have segment registers and still have opcodes for loading both segment and offset registers simultaneously.

          The opcodes are called "Load Far Pointer" which appears quite descriptive. It's a "Far" pointer because it points to data outside of the normal addressing range.

          e.g. LDS EBP, 48-bit-literal
          will load the DS segment register with the top 16 bits of the 48 bit literal and the EBP register with the low 32 bits.

          Most folk forget about the segment registers because they aren't used much in applications, they're more of an OS thing.

          Paul.

          Comment


          • #6
            Microsoft's "flat mode" is a fake-- the segments (or selectors) are
            simply all set to the same thing. So, you are restricted to a total
            of 32 bits of address, instead of being able to access 32 bits of
            address per selector. The mingling of selectors also prevents the
            OS from being able to take advantage of selector-oriented hardware
            access protection, which could have prevented many classes of bugs,
            including many of the buffer-overflow security holes that so often
            plague Microsoft's own products.


            ------------------
            Tom Hanlin
            PowerBASIC Staff

            Comment


            • #7
              damn.
              Michael Mattias
              Tal Systems (retired)
              Port Washington WI USA
              [email protected]
              http://www.talsystems.com

              Comment


              • #8
                Waw, now I understand. In my 16bit days I never peeked and
                poked around with memory allocation, why would I, there was
                this really good DOS compiler called PB DOs 3.5

                Anyway, thanks for the clear explanation !

                ------------------
                So here we are, this is the end.
                But all that dies, is born again.
                - From The Ashes (In This Moment)

                Comment

                Working...
                X