Re: 80286 protected mode

David Brown <david.brown@hesbynett.no> writes:

When would you ever /need/ to compare pointers to different objects?
For almost all C programmers, the answer is "never".  Pretty much the
only example people ever give of needing such comparisons is to
implement memmove() efficiently - but you don't need to implement
memmove(), because it is already in the standard library.

When you implements something like, say

vsum(double *a, double *b, double *c, size_t n);

where a, b, and c may point to arrays in different objects, or may
point to overlapping parts of the same object, and the result vector c
in the overlap case should be the same as in the no-overlap case
(similar to memmove()), being able to compare pointers to possibly
different objects also comes in handy.

Another example is when the programmer uses the address as a key in,
e.g., a binary search tree.  And, as you write, casting to intptr_t is
not guarenteed to work by the C standard, either.

An example that probably compares pointers to the same object as far
as the C standard is concerned, but feel like different objects to the
programmer, is logic variables (in, e.g., a Prolog implementation).
When you have two free variables, and you unify them, in the
implementation one variable points to the other one.  Now which should
point to which?  The younger variable should point to the older one,
because it will die sooner.  How do you know which variable is
younger?  You compare the addresses; the variables reside on a stack,
so the younger one is closer to the top.

If that stack is one object as far as the C standard is concerned,
there is no problem with that solution.  If the stack is implemented
as several objects (to make it easier growable; I don't know if there
is a Prolog implementation that does that), you first have to check in
which piece it is (maybe with a binary search), and then possibly
compare within the stack piece at hand.

An interesting case is the Forth standard.  It specifies "contiguous
regions", which correspond to objects in C, but in Forth each address
is a cell and can be added, subtracted, compared, etc. irrespective of
where it came from.  So Forth really has a flat-memory model.  It has
had that since its origins in the 1970s.  Some of the 8086
implementations had some extensions for dealing with more than 64KB,
but they were never standardized and are now mostly forgotten.
 

>
Forth does not require a flat memory model in the hardware, as far as I
am aware, any more than C does.  (I appreciate that your knowledge of
Forth is /vastly/ greater than mine.)  A Forth implementation could
interpret part of the address value as the segment or other memory block
identifier and part of it as an index into that block, just as a C
implementation can.

I.e., what you are saying is that one can simulate a flat-memory model
on a segmented memory model.  Certainly.  In the case of the 8086 (and
even more so on the 286) the costs of that are so high that no
widely-used Forth system went there.

One can also simulate segmented memory (a natural fit for many
programming languages) on flat memory.  In this case the cost is much
smaller, plus it gives the maximum flexibility about segment/object
sizes and numbers.  That is why flat memory has won.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
  Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>