Re: 80286 protected mode

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

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.

I certainly suggested that they have some advantages, yes.  I don't know nearly enough details about implementations and practical usage to know if scalable vector instructions are /always/ better than non-scalable SIMD with fixed-size registers, either from the viewpoint of their efficiency at runtime or their implementation in hardware.
It seems to me that if the compiler knows the size of a memcpy/memmove, then the best results would probably be achieved by the compiler inlining the copy using fixed size registers of a suitable size.  If it does not know the size, then I would expect (but I don't know for sure) that a hardware scalable vector instruction should be more efficient than using fixed-size registers.  If that were not the case, then I wonder why scalable vector hardware has become popular recently in ISAs.
If you - or someone else - knows enough to say more about this, then I'd be glad to learn about it.

 

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.
 

OK.

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.
 

So if I understand you correctly, your argument is that scalable vector instructions - at least for copying memory - is slow in hardware implementations, and thus it would be better to simply copy memory in a loop using larger fixed-size registers?  I would find that surprising, but as I said, I don't know the details of implementations.
(I do know that in the 68k family, the hardware division instruction was dropped for later devices after it was realised that a software division routine was faster than the hardware instruction.  So such strange things have happened.)