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 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: References: <2024Oct6.150415@mips.complang.tuwien.ac.at> <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.