Re: 80286 protected mode

On 09/10/2024 18:28, MitchAlsup1 wrote:

On Wed, 9 Oct 2024 8:24:34 +0000, David Brown wrote:
 

On 08/10/2024 09:28, Anton Ertl wrote:.
>
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.)

 Somebody has to write memmove() and they want to use C to do it.

They don't have to write it in standard, portable C.  Standard libraries will, sometimes, use "magic" - they can be in assembly, or use compiler extensions, or target-specific features, or "-fsecret-flag-for-std-lib" compiler flags, or implementation-dependent features, or whatever they want.
You will find that most implementations of memmove() are done by converting the pointers to a unsigned integer type and comparing those values.  The type chosen may be implementation-dependent, or it may be "uintptr_t" (even if you are using C90 for your code, the library writers can use C99 for theirs).
Such implementations will not be portable to all systems.  They won't work on a target that has some kind of "fat" pointers or segmented pointers that can't be translated properly to integers.
That's okay, of course.  For targets that have such complications, that standard library function will be written in a different way.
The avrlibc library used by gcc for the AVR has its memmove() implemented in assembly for speed, as does musl for some architectures.
There are lots of parts of the standard C library that cannot be written completely in portable standard C.  (How would you write a function that handles files?  You need non-portable OS calls.)  That's why these things are in the standard library in the first place.