Re: 80286 protected mode

On 10/10/24 2:21 PM, David Brown wrote:
[ SNIP]

 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.
 

If the compiler generates the memmove instruction, then one doesn't
have to write memmove() is C - it is never called/used.

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.
>

Not applicable.