Re: 80286 protected mode

On Fri, 11 Oct 2024 16:54:13 +0200
David Brown <david.brown@hesbynett.no> wrote:

On 11/10/2024 14:13, Michael S wrote:

On Fri, 11 Oct 2024 13:37:03 +0200
David Brown <david.brown@hesbynett.no> wrote:
 

On 10/10/2024 23:19, Brian G. Lucas wrote: 

>
Not applicable.
    

>
I don't understand what you mean by that.  /What/ is not applicable
to /what/ ?
 

 
Brian probably meant to say that that it is not applicable to his
my66k LLVM back end.
 
But I am pretty sure that what you suggest is applicable, but bad
idea for memcpy/memmove routine that targets Arm+SVE.
Dynamic dispatch based on concrete core features/identification,
i.e. exactly the same mechanism that is done on "non-scalable"
architectures, would provide better performance. And memcpy/memmove
is certainly sufficiently important to justify an additional
development effort.
 

 
That explanation helps a little, but only a little.  I wasn't
suggesting anything - or if I was, it was several posts ago and the
context has long since been snipped.

You suggested that "scalable" vector extension are preferable for
memcpy/memmove implementation over "non-scalable" SIMD.

Can you be more explicit about
what you think I was suggesting, and why it might not be a good idea
for targeting a "my66k" ISA?  (That is not a processor I have heard
of, so you'll have to give a brief summary of any particular features
that are relevant here.)
 

The proper spelling appears to be My 66000.
For starter, My 66000 has no SIMD. It does not even have dedicated FP
register file. Both FP and Int share common 32x64bit register space.

More importantly, it has dedicate instruction with exactly the same
semantics as memmove(). Pretty much the same as ARM64. In both cases
instruction is defined, but not yet implemented in production silicon.
The difference is that in case of ARM64 we can be reasonably sure that
eventually it will be implemented in production silicon. Which means
that in at least several out of multitude of implementations it will
suck.