Re: 80286 protected mode

On Mon, 14 Oct 2024 17:19:40 +0200
David Brown <david.brown@hesbynett.no> wrote:

On 14/10/2024 16:40, Terje Mathisen wrote:

David Brown wrote: 

On 13/10/2024 21:21, Terje Mathisen wrote: 

David Brown wrote: 

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. 

>
What you are missing here David is the fact that Mitch's MM is a
single instruction which does the entire memmove() operation, and
has the inside knowledge about cache (residency at level x? width
in bytes)/memory ranges/access rights/etc needed to do so in a
very close to optimal manner, for both short and long transfers. 

>
I am not missing that at all.  And I agree that an advanced
hardware MM instruction could be a very efficient way to implement
both memcpy and memmove.  (For my own kind of work, I'd worry
about such looping instructions causing an unbounded increased in
interrupt latency, but that too is solvable given enough hardware
effort.)
>
And I agree that once you have an "MM" (or similar) instruction,
you don't need to re-write the implementation for your memmove()
and memcpy() library functions for every new generation of
processors of a given target family.
>
What I /don't/ agree with is the claim that you /do/ need to keep
re-writing your implementations all the time.  You will
/sometimes/ get benefits from doing so, but it is not as simple as
Mitch made out.

>
I.e. totally removing the need for compiler tricks or wide
register operations.
>
Also apropos the compiler library issue:
>
You start by teaching the compiler about the MM instruction, and
to recognize common patterns (just as most compilers already do
today), and then the memmove() calls will usually be inlined.
 

>
The original compile library issue was that it is impossible to
write an efficient memmove() implementation using pure portable
standard C. That is independent of any ISA, any specialist
instructions for memory moves, and any compiler optimisations.
And it is independent of the fact that some good compilers can
inline at least some calls to memcpy() and memmove() today, using
whatever instructions are most efficient for the target. 

 
David, you and Mitch are among my most cherished writers here on
c.arch, I really don't think any of us really disagree, it is just
that we have been discussing two (mostly) orthogonal issues. 

 
I agree.  It's a "god dag mann, økseskaft" situation.
 
I have a huge respect for Mitch, his knowledge and experience, and
his willingness to share that freely with others.  That's why I have
found this very frustrating.
 

 
a) memmove/memcpy are so important that people have been spending a
lot of time & effort trying to make it faster, with the
complication that in general it cannot be implemented in pure C
(which disallows direct comparison of arbitrary pointers).
 

 
Yes.
 
(Unlike memmov(), memcpy() can be implemented in standard C as a
simple byte-copy loop, without needing to compare pointers.  But an
implementation that copies in larger blocks than a byte requires
implementation dependent behaviour to determine alignments, or it
must rely on unaligned accesses being allowed by the implementation.)
 

b) Mitch have, like Andy ("Crazy") Glew many years before, realized
that if a cpu architecture actually has an instruction designed to
do this particular job, it behooves cpu architects to make sure
that it is in fact so fast that it obviates any need for tricky
coding to replace it.

 
Yes.
 

Ideally, it should be able to copy a single object, up to a cache
line in size, in the same or less time needed to do so manually
with a SIMD 512-bit load followed by a 512-bit store (both ops
masked to not touch anything it shouldn't)
 

 
Yes.
 

REP MOVSB on x86 does the canonical memcpy() operation, originally
by moving single bytes, and this was so slow that we also had REP
MOVSW (moving 16-bit entities) and then REP MOVSD on the 386 and
REP MOVSQ on 64-bit cpus.
 
With a suitable chunk of logic, the basic MOVSB operation could in
fact handle any kinds of alignments and sizes, while doing the
actual transfer at maximum bus speeds, i.e. at least one cache
line/cycle for things already in $L1.
 

 
I agree on all of that.
 
I am quite happy with the argument that suitable hardware can do
these basic operations faster than a software loop or the x86 "rep"
instructions. 

No, that's not true. And according to my understanding, that's not what
Terje wrote.
REP MOVSB _is_ almost ideal instruction for memcpy (modulo minor
details - fixed registers for src, dest, len and Direction flag in PSW
instead of being part of the opcode).
REP MOVSW/D/Q were introduced because back then processors were small
and stupid. When your processor is big and smart you don't need them
any longer. REP MOVSB is sufficient.
New Arm64 instruction that are hopefully coming next year are akin to
REP MOVSB rather than to MOVSW/D/Q.
Instructions for memmove, also defined by Arm and by Mitch, is the next
logical step. IMHO, the main gain here is not measurable improvement in
performance, but saving of code size when inlined.

Now, is all that a good idea? I am not 100% convinced.
One can argue that streaming alignment hardware that is necessary for
1st-class implementation of these instructions is useful not only for
memory copy.
So, may be, it makes sense to expose this hardware in more generic ways.
May be, via Load Multiple Register? It was present in Arm's A32/T32,
but didn't make it into ARM64. Or, may be, there are even better ways
that I was not thinking about.

And I fully agree that these would be useful features
in general-purpose processors.
 
My only point of contention is that the existence or lack of such
instructions does not make any difference to whether or not you can
write a good implementation of memcpy() or memmove() in portable
standard C.

You are moving a goalpost.
One does not need "good implementation" in a sense you have in mind.
All one needs is an implementation that pattern matching logic of
compiler unmistakably recognizes as memove/memcpy. That is very easily
done in standard C. For memmove, I had shown how to do it in one of the
posts below. For memcpy its very obvious, so no need to show.

They would make it easier to write efficient
implementations of these standard library functions for targets that
had such instructions - but that would be implementation-specific
code.  And that is one of the reasons that C standard library
implementations are tied to the specific compiler and target, and the
writers of these libraries have "superpowers" and are not limited to
standard C.