Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.arch
Subject: Re: 80286 protected mode
Date: Wed, 9 Oct 2024 10:24:34 +0200
Organization: A noiseless patient Spider
Lines: 75
Message-ID: <ve5ek3$2jamt$1@dont-email.me>
References: <2024Oct6.150415@mips.complang.tuwien.ac.at>
 <memo.20241006163428.19028W@jgd.cix.co.uk>
 <2024Oct7.093314@mips.complang.tuwien.ac.at>
 <7c8e5c75ce0f1e7c95ec3ae4bdbc9249@www.novabbs.org>
 <2024Oct8.092821@mips.complang.tuwien.ac.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 09 Oct 2024 10:24:36 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="4ad84ebeba927b1850d052c9a649762c";
	logging-data="2730717"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX181Sjc5WPBYvq8246v2w0tc07KTzg6O8wo="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:DOTqgtGxDA3OTVhirxuVmM9iIco=
In-Reply-To: <2024Oct8.092821@mips.complang.tuwien.ac.at>
Content-Language: en-GB
Bytes: 4971

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.