Path: ...!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: Tue, 15 Oct 2024 14:09:58 +0200 Organization: A noiseless patient Spider Lines: 74 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> <2024Oct13.174537@mips.complang.tuwien.ac.at> <3e885f3c9d768541e2b07180d5821a1f@www.novabbs.org> <20241015142246.00001f24@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Tue, 15 Oct 2024 14:09:58 +0200 (CEST) Injection-Info: dont-email.me; posting-host="47228e08c2736a5aef9f5441cfbf6fae"; logging-data="1754606"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/H1cSA2/px9I9mXGvy2JvEwB9bDXWuQ+4=" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Cancel-Lock: sha1:nOCeeutFeG+033mAvSInf+wG9Ts= Content-Language: en-GB In-Reply-To: <20241015142246.00001f24@yahoo.com> Bytes: 4147 On 15/10/2024 13:22, Michael S wrote: > On Tue, 15 Oct 2024 12:38:40 +0200 > David Brown wrote: > >> On 14/10/2024 21:02, MitchAlsup1 wrote: >>> On Mon, 14 Oct 2024 15:04:28 +0000, David Brown wrote: >>> >>>> On 13/10/2024 17:45, Anton Ertl wrote: >>> >>>> I do think it would be convenient if there were a fully standard >>>> way to compare independent pointers (other than just for >>>> equality).  Rarely needing something does not mean /never/ needing >>>> it. >>> >>> OK, take a segmented memory model with 16-bit pointers and a 24-bit >>> virtual address space. How do you actually compare to segmented >>> pointers ?? >> >> >> void * p = ... >> void * q = ... >> >> uintptr_t pu = (uintptr_t) p; >> uintptr_t qu = (uintptr_t) q; >> >> if (pu > qu) { >> ... >> } else if (pu < qu) { >> ... >> } else { >> ... >> } >> >> >> If your comparison needs to actually match up with the real virtual >> addresses, then this will not work. But does that actually matter? >> >> Think about using this comparison for memmove(). >> >> Consider where these pointers come from. Maybe they are pointers to >> statically allocated data. Then you would expect the segment to be >> the same in each case, and the uintptr_t comparison will be fine for >> memmove(). Maybe they come from malloc() and are in different >> segments. Then the comparison here might not give the same result as >> a full virtual address comparison - but that does not matter. If the >> pointers came from different mallocs, they could not overlap and >> memmove() can run either direction. >> >> The same applies to other uses, such as indexing in a binary search >> tree or a hash map - the comparison above will be correct when it >> matters. >> >> >> > > It's all fine for as long as there are no objects bigger than 64KB. > But with 16MB of virtual memory and with several* MB of physical memory > one does want objects that are bigger than 64KB! > I don't know how such objects would be allocated and addressed in such a system. (I didn't do much DOS/Win16 programming, and on the few occasions when I needed structures bigger than 64KB in total, they were structured in multiple levels.) But I would expect that in almost any practical system where you can use "p++" to step through big arrays, you can also convert the pointer to a uintptr_t and compare as shown above. The exceptions would be systems where pointers hold more than just addresses, such as access control information or bounds that mean they are larger than the largest integer type on the target.