Re: 80286 protected mode

On 10/10/2024 20:38, MitchAlsup1 wrote:

On Thu, 10 Oct 2024 6:31:52 +0000, David Brown wrote:
 

On 09/10/2024 23:37, MitchAlsup1 wrote:

On Wed, 9 Oct 2024 20:22:16 +0000, David Brown wrote:
>

On 09/10/2024 20:10, Thomas Koenig wrote:

David Brown <david.brown@hesbynett.no> schrieb:
>

When would you ever /need/ to compare pointers to different objects?
For almost all C programmers, the answer is "never".

>
Sometimes, it is handy to encode certain conditions in pointers,
rather than having only a valid pointer or NULL.  A compiler,
for example, might want to store the fact that an error occurred
while parsing a subexpression as a special pointer constant.
>
Compilers often have the unfair advantage, though, that they can
rely on what application programmers cannot, their implementation
details.  (Some do not, such as f2c).

>
Standard library authors have the same superpowers, so that they can
implement an efficient memmove() even though a pure standard C
programmer cannot (other than by simply calling the standard library
memmove() function!).

>
This is more a symptom of bad ISA design/evolution than of libc
writers needing superpowers.

>
No, it is not.  It has absolutely /nothing/ to do with the ISA.

 For example, if ISA contains an MM instruction which is the
embodiment of memmove() then absolutely no heroics are needed
of desired in the libc call.
 

The existence of a dedicated assembly instruction does not let you write an efficient memmove() in standard C.  That's why I said there was no connection between the two concepts.
For some targets, it can be helpful to write memmove() in assembly or using inline assembly, rather than in non-portable C (which is the common case).

Thus, it IS a symptom of ISA evolution that one has to rewrite
memmove() every time wider SIMD registers are available.

It is not that simple.
There can often be trade-offs between the speed of memmove() and memcpy() on large transfers, and the overhead in setting things up that is proportionally more costly for small transfers.  Often that can be eliminated when the compiler optimises the functions inline - when the compiler knows the size of the move/copy, it can optimise directly.
The use of wider register sizes can help to some extent, but not once you have reached the width of the internal buses or cache bandwidth.
In general, there will be many aspects of a C compiler's code generator, its run-time support library, and C standard libraries that can work better if they are optimised for each new generation of processor. Sometimes you just need to re-compile the library with a newer compiler and appropriate flags, other times you need to modify the library source code.  None of this is specific to memmove().
But it is true that you get an easier and more future-proof memmove() and memcopy() if you have an ISA that supports scalable vector processing of some kind, such as ARM and RISC-V have, rather than explicitly sized SIMD registers.