Re: 80286 protected mode

On Thu, 10 Oct 2024 20:00:29 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:

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

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

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

 

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.
 

 
Note that ARMv8 (via FEAT_MOPS) does offer instructions that handle
memcpy and memset.
 
They're three-instruction sets;  prolog/body/epilog. There are
separate sets for forward vs. forward-or-backward copies.
 
The prolog instruction preconditions the copy and copies
an IMPDEF portion.
 
The body instruction performs an IMPDEF Portion and
 
the epilog instruction finalizes the copy.
 
The three instructions are issued consecutively.

People that have more clue about Arm Inc schedule than myself
expect Arm Cortex cores that implement these instructions to be
announced next May and to appear in actual [expensive] phones in 2026.
Which probably means 2027 at best for Neoverse cores.

It's hard to make an educated guess about schedule of other Arm core
designers.