Re: 80286 protected mode

On Thu, 10 Oct 2024 19:21:20 +0000, David Brown wrote:

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

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.

       {
            memmove( p, q, size );
       }
Where the compiler produces the MM instruction itself. Looks damn
close to standard C to me !!
OR
       for( int i = 0, i < size; i++ )
            p[i] = q[i];
Which gets compiled to memcpy()--also looks to be standard C.
OR
       p_struct = q_struct;
gets compiled to::
       memmove( &p_struct, &q_struct, sizeof( q_struct ) );
also looks to be std C.
The thing is you are no longer writing memmove(), you are simply
teaching the compiler to recognizes its _use_ cases directly. In
addition, these will always be within spitting distance of as fast
as one can perform those activities.

                                       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.

Given that we are talking about GBOoO machines here, the several
AGEN units[1,2,3] have plenty of calculation BW to determine order
without wasting cycles getting started.
But given LBIO machine, the ability to process memory to memory moves
at cache port width is always an advantage except for cases needing
only 1 read or 1 write--if you build the HW with these in mind.

                                                    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.

In HW they should always be optimized.