Why (non-std) near and far keywords? 
Author Message
 Why (non-std) near and far keywords?

Several (all?) C compilers for i8086 have keywords "near" and "far",
which are used with pointers:

void far *far_ptr;      // sizeof far_ptr == 4
void near *near_ptr;    // sizeof near_ptr == 2

Why were new keywords reserved, when the same thing could have been
done with the preexisting "short" and "long"?

void *long far_ptr;
void *short near_ptr;
--



Fri, 31 Jan 2003 03:00:00 GMT  
 Why (non-std) near and far keywords?


Quote:
> Several (all?) C compilers for i8086 have keywords "near" and "far",
> which are used with pointers:

> void far *far_ptr; // sizeof far_ptr == 4
> void near *near_ptr;       // sizeof near_ptr == 2

> Why were new keywords reserved, when the same thing could have been
> done with the preexisting "short" and "long"?

My understanding is that 'near', 'far' (perhaps even 'huge' on Intel 8086
...) modifiers for pointers were inherited from the assembly language. Their
meaning is related to a particular hardware (processor).

--

---------------------------------
Web-based organizer and calendar:
http://caldonia.com
--



Fri, 31 Jan 2003 03:00:00 GMT  
 Why (non-std) near and far keywords?

Quote:
>Several (all?) C compilers for i8086 have keywords "near" and "far",
>which are used with pointers:

>void far *far_ptr;  // sizeof far_ptr == 4
>void near *near_ptr;        // sizeof near_ptr == 2

>Why were new keywords reserved, when the same thing could have been
>done with the preexisting "short" and "long"?

>void *long far_ptr;
>void *short near_ptr;

In my opinion, using the same keyword to mean different things
is a bad idea.  Consider the widespread, severe, and apparently
uncorrectable confusion caused by overloading the 'static' keyword.
It's so bad I have frequently seen the oxymoron "local globals".

Having one set of standard keywords that apply to arithmetic types
('short', 'long') and a different set of implementation-specific keywords
that modify pointer types ('near', 'far', 'huge', etc.) has several advantages:

(1)
When porting code littered with these non-standard extensions to a
system that doesn't use them, you can usually just
   #define near
   #define far
   #define huge
and make them go away.  If 'short', 'long', and 'long long' were used
instead, you wouldn't be able to do that.

(2)
It avoids accidentally modifying the type pointed to rather the pointer.
If 'short' were used instead of 'near', you could accidentally write

   unsigned short *p;

when you really meant

   unsigned * short p;

Both are valid, but they don't mean the same thing at all.
The first is a default-sized pointer to an unsigned short int.
The second is a near (short) pointer to an unsigned int.

These errors would be extremely easy to overlook.

(3)
There's more to these pointer memory models than just number of bits.
For example, on the 8086, 'far' and 'huge' pointers are the same size,
but pointer arithmetic on them is performed differently.  Therefore the
analogy between different sizes of integer types, and different
pointer memory models is inexact.  Using the same keywords for both
would obscure the quirks of memory models from the programmer,
without actually protecting him from them.

(4)
Some processor architectures are even crankier than the 8086;
there aren't enough intuitively meaningful keywords to cover all
the cases.

For example, the company I work for sells a C compiler for the
8051 family of 8-bit microcontrollers that has the following
memory-type specifiers for pointers:
   data
   idata
   bdata
   pdata
   code
   xdata
Which SIX keywords should we re-use for all those?
As it is, we use the same names that the data books for the
chips use.  I think that was a good choice, although they ought
to have leading underscores added.

-- Gary Culp
--



Sat, 01 Feb 2003 03:00:00 GMT  
 Why (non-std) near and far keywords?

Quote:

> Several (all?) C compilers for i8086 have keywords "near" and "far",
> which are used with pointers:

> void far *far_ptr;      // sizeof far_ptr == 4
> void near *near_ptr;    // sizeof near_ptr == 2

> Why were new keywords reserved, when the same thing could have been
> done with the preexisting "short" and "long"?

> void *long far_ptr;
> void *short near_ptr;

There is a very good practical reason:

The "far" and "near" keywords were only used in C implementations for some
very strange hardware (80x86 processor running in 16 bit mode), while
other implementations didn't need this at all. Now lets say you want to
write a program with portable sourcecode, but because of the restrictions
of your 80x86 compiler you need a pointer that is a "far" pointer on and
80x86 system, but a normal pointer on other systems. How do you do this?

If the keywords were "long" and "short", you would have to write

   #ifdef X86_COMPILER
      void *long far_ptr;
   #else
      void* far_ptr;
   #endif

because any "normal" compiler would not accept "void *long far_ptr;". You
need to do this for every single use of a far or near pointer.

With keywords "long" and "short", you write once in a header file

   #ifndef X86_COMPILER
      #define far
      #define near
   #endif

and then write

   void far *far_ptr;
   void near *near_ptr;

It is still damned ******* ugly, but at least your code will run everywhere.
--



Sat, 01 Feb 2003 03:00:00 GMT  
 Why (non-std) near and far keywords?

Quote:
> Several (all?) C compilers for i8086 have keywords "near" and "far",
> which are used with pointers:

> void far *far_ptr; // sizeof far_ptr == 4
> void near *near_ptr;       // sizeof near_ptr == 2

> Why were new keywords reserved, when the same thing could have been
> done with the preexisting "short" and "long"?

> void *long far_ptr;
> void *short near_ptr;

long and short are definitely not the same as far and near. Consider
these:

short far *ptr1;
long near *ptr2;

Note that, for example, DJGPP doesn't need these keywords at all, and
AFAIK doesn't have them.

Richard
--



Sat, 01 Feb 2003 03:00:00 GMT  
 Why (non-std) near and far keywords?


Quote:
>Several (all?) C compilers for i8086 have keywords "near" and "far",
>which are used with pointers:

>Why were new keywords reserved, when the same thing could have been
>done with the preexisting "short" and "long"?

near and far don't just specify the physical size of the pointer - they
specify that pointer arithmetic must be done a certain way.  A near
pointer is 16 bits only, and uses the implicit data segment register.  A
far pointer specifies both the segment and offset values.  Addresses on
the x86 are 20 bits, and calculated as 16 * segment + offset.  You can't
do 32 bit arithmetic on them.

--
#include <standard.disclaimer>
 _
Kevin D Quitt  USA 91351-4454           96.37% of all statistics are made up
Per the FCA, this email address may not be added to any commercial mail list
--



Sat, 01 Feb 2003 03:00:00 GMT  
 Why (non-std) near and far keywords?

Quote:
> Several (all?) C compilers for i8086 have keywords "near" and "far",
> which are used with pointers:

> void far *far_ptr; // sizeof far_ptr == 4
> void near *near_ptr;       // sizeof near_ptr == 2

> Why were new keywords reserved, when the same thing could have been
> done with the preexisting "short" and "long"?

The pointer attributes 'far', 'near' and 'huge' are artifacts of the
i8086 hardware; confusing them with the integer types 'long' and 'short'
would have been detrimental.

The 8086 processors stored pointers in a segment:offset format, using two
bytes each. This format is also known as 'far' pointers. For optimized
memory operations, the processor allowed to set 'segment' values for code
and data accesses, allowing shorter 'near' pointers consisting of just
the offset information. And since one memory location could be equally
addressed using with different segment:offset value pairs, some compilers
invented the 'huge' pointer which was just the absolute memory address.
Using 'huge' pointers however reduced the performance because internally
they had to be converted into the segment:offset format.

 -- Lars has spend far too much time with assembly programming.
--

              http://www.bearnip.com/
--



Sat, 01 Feb 2003 03:00:00 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. far and near instruction for C functions

2. near, huge and far pointers

3. C near and far pointer declarations

4. need convertion from char far* to char near *?

5. far and near pointers

6. near and far in MSC

7. Types (about linkers optimizing near/far branches)

8. near pointer conversion to far <HELP!>

9. Far and Near Question

10. Conversions: near and far pointers

11. NEAR and FAR pointers!

12. FAR and NEAR types?

 

 
Powered by phpBB® Forum Software