Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.arch
Subject: Re: 80286 protected mode
Date: Tue, 15 Oct 2024 14:22:46 +0300
Organization: A noiseless patient Spider
Lines: 64
Message-ID: <20241015142246.00001f24@yahoo.com>
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>
	<ve5ek3$2jamt$1@dont-email.me>
	<2024Oct13.174537@mips.complang.tuwien.ac.at>
	<vejbts$1772o$2@dont-email.me>
	<3e885f3c9d768541e2b07180d5821a1f@www.novabbs.org>
	<velgng$1lhfe$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Injection-Date: Tue, 15 Oct 2024 13:22:12 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="b82f3ff387ea9347e32983188b873679";
	logging-data="1720587"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+HAKW0Uj9WM8xLOpqqiLjCLEYCxnoFDnQ="
Cancel-Lock: sha1:QjTaWKBTEuH8yz3/Oh+UW2EP1zg=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 3436

On Tue, 15 Oct 2024 12:38:40 +0200
David Brown <david.brown@hesbynett.no> wrote:

> On 14/10/2024 21:02, MitchAlsup1 wrote:
> > On Mon, 14 Oct 2024 15:04:28 +0000, David Brown wrote:
> >  =20
> >> On 13/10/2024 17:45, Anton Ertl wrote: =20
> >  =20
> >> I do think it would be convenient if there were a fully standard
> >> way to compare independent pointers (other than just for
> >> equality).=C2=A0 Rarely needing something does not mean /never/ needing
> >> it. =20
> >=20
> > 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 ?? =20
>=20
>=20
> void * p =3D ...
> void * q =3D ...
>=20
> uintptr_t pu =3D (uintptr_t) p;
> uintptr_t qu =3D (uintptr_t) q;
>=20
> if (pu > qu) {
> 	...
> } else if (pu < qu) {
> 	...
> } else {
> 	...
> }
>=20
>=20
> If your comparison needs to actually match up with the real virtual=20
> addresses, then this will not work.  But does that actually matter?
>=20
> Think about using this comparison for memmove().
>=20
> Consider where these pointers come from.  Maybe they are pointers to=20
> 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=20
> 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.
>=20
> 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.
>=20
>=20
>=20

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!

---
* https://theretroweb.com/motherboards/s/compaq-deskpro-286e-p-n-001226