Re: 80286 protected mode

On 08/10/2024 09:28, Anton Ertl wrote:

mitchalsup@aol.com (MitchAlsup1) writes:

Whereas by the time 286 got out, everybody was wanting flat
memory ala C.

 It's interesting that, when C was standardized, the segmentation found
its way into it by disallowing subtracting and comparing between
addresses in different objects.

It is difficult to talk about the timing of features (either things that are allowed, or things explicitly disallowed) before the standardisation of C, as there was no single language "C".  Different variants supported by different compilers had different rules.

 This disallows performing certain
forms of induction variable elimination by hand.  So while flat memory
is C culture so much that you write "flat memory ala C", the
standardized subset of C (what standard C fanatics claim is the only
meaning of "C") actually specifies a segmented memory model.
 

No, the C standard does not in any sense specify a segmented memory model.  Nor does it specify a non-segmented or flat or contiguous memory.
The nearest it gets is the description of converting between pointers and integers, where it says that the conversion of a pointer to an integer might not fit in any integer type, in which case the conversions are undefined behaviour - but if they /are/ convertible, the intention is that the value (of type "uintptr_t") should be consistent with "the addressing structure of the execution environment".
The way C is specified is intended to be strong enough to allow programmers to do all they generally need to do using portable code (i.e., code that doesn't rely on anything other than standard behaviour), without unnecessarily restricting the kinds of systems that can implement C, and without unnecessarily restricting what people can write in non-portable code.
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.  (Standard library implementations don't need to be portable, and can rely on extensions or other compiler-specific features.)
In practice, on all but the most niche or specialised platforms, if you do feel you need to compare random pointers, you can cast them to uintptr_t and compare these.  That will generally work on segmented, non-contiguous or flat memories.

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.
A flat address model is almost certainly more /efficient/, for C, Forth and many other languages.  But that does not mean a particular model is /required/ or specified by the language.