Re: 80286 protected mode

On 10/13/24 4:26 AM, Michael S wrote:

On Sun, 13 Oct 2024 10:31:49 +0300
Niklas Holsti <niklas.holsti@tidorum.invalid> wrote:
 

On 2024-10-12 21:33, Brett wrote:

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

On 12/10/2024 01:32, MitchAlsup1 wrote:

On Fri, 11 Oct 2024 22:02:32 +0000, David Brown wrote:
 

On 11/10/2024 20:55, MitchAlsup1 wrote:

On Fri, 11 Oct 2024 12:10:13 +0000, David Brown wrote:
 

>
Do you think you can just write this :
>
void * memmove(void * s1, const void  * s2, size_t n)
{
      return memmove(s1, s2, n);
}
>
in your library's source?

>
         .global memmove
memmove:
         MM     R2,R1,R3
         RET
>
sure !

>
You are either totally clueless, or you are trolling.  And I
know you are not clueless.
>
This discussion has become pointless.

>
The point is that there are a few things that may be hard to do
with {decode, pipeline, calculations, specifications...}; but
because they are so universally needed; these, too, should
"get into ISA".
>
One good reason to put them in ISA is to preserve the programmers
efforts over decades, so they don't have to re-write libc every-
time a new set of instructions come out.
>
Moving an arbitrary amount of memory from point a to point b
happens to fall into that universal need. Setting an arbitrary
amount of memory to a value also falls into that universal
need.

>
Again, I have to ask - do you bother to read the posts you reply
to? Are you interested in replying, and engaging in the
discussion?  Or are you just looking for a chance to promote your
own architecture, no matter how tenuous the connection might be to
other posts?
>
Again, let me say that I agree with what you are saying - I agree
that an ISA should have instructions that are efficient for what
people actually want to do.  I agree that it is a good thing to
have instructions that let performance scale with advances in
hardware ideally without needing changes in compiled binaries, and
at least without needing changes in source code.
>
I believe there is an interesting discussion to be had here, and I
would enjoy hearing about comparisons of different ways things
functions like memcpy() and memset() can be implemented in
different architectures and optimised for different sizes, or how
scalable vector instructions can work in comparison to fixed-size
SIMD instructions.
>
But at the moment, this potential is lost because you are posting
total shite about implementing memmove() in standard C.  It is
disappointing that someone with your extensive knowledge and
experience cannot see this.  I am finding it all very frustrating.
 

  

>
>
    [ snip discussion of HW ]
>
>

In short your complaints are wrong headed in not understanding what
hardware memcpy can do.

>
>
I think your reply proves David's complaint: you did not read, or did
not understand, what David is frustrated about. The true fact that
David is defending is that memmove() cannot be implemented
"efficiently" in /standard/ C source code, on /any/ HW, because it
would require comparing /C pointers/ that point to potentially
different /C objects/, which is not defined behavior in standard C,
whether compiled to machine code, or executed by an interpreter of C
code, or executed by a human programmer performing what was called
"desk testing" in the 1960s.
>
Obviously memmove() can be implemented efficently in non-standard C
where such pointers can be compared, or by sequences of ordinary ALU
instructions, or by dedicated instructions such as Mitch's MM, and
David is not disputing that. But Mitch seems not to understand or not
to see the issue about standard C vs memmove().
>

 Sufficiently advanced compiler can recognize patterns and replace them
with built-in sequences.
 In case of memmove() the most easily recognizable pattern in 100%
standard C99 appears to be:
 void *memmove( void *dest, const void *src, size_t count)
{
  if (count > 0) {
    char tmp[count];
    memcpy(tmp, src, count);
    memcpy(dest, tmp, count);
  }
  return dest;
}
 I don't suggest that real implementation in Brian's compiler is like
that. Much more likely his implementation uses non-standard C and looks
approximately like:
void *memmove(void *dest, const void *src, size_t count {
   return __builtin_memmove(dest, src, count);
}
 

Well, something like that.  Clang will generate LLVM IR which acts like
a builtin_memmove that the backend can match and emit the MM instruction.

However, implementing the first variant efficiently is well within
abilities of good compiler.