Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.arch
Subject: Re: 80286 protected mode
Date: Sun, 13 Oct 2024 12:00:48 +0300
Organization: A noiseless patient Spider
Lines: 57
Message-ID: <20241013120048.00007915@yahoo.com>
References: <2024Oct6.150415@mips.complang.tuwien.ac.at>
	<memo.20241006163428.19028W@jgd.cix.co.uk>
	<2024Oct7.093314@mips.complang.tuwien.ac.at>
	<7c8e5c75ce0f1e7c95ec3ae4bdbc9249@www.novabbs.org>
	<2024Oct8.092821@mips.complang.tuwien.ac.at>
	<ve5ek3$2jamt$1@dont-email.me>
	<ve6gv4$2o2cj$1@dont-email.me>
	<ve6olo$2pag3$2@dont-email.me>
	<73e776d6becb377b484c5dcc72b526dc@www.novabbs.org>
	<ve7sco$31tgt$1@dont-email.me>
	<2b31e1343b1f3fadd55ad6b87d879b78@www.novabbs.org>
	<ve99fg$38kta$1@dont-email.me>
	<ve9gd4$3a9n8$1@dont-email.me>
	<veb2kv$3kjt3$1@dont-email.me>
	<20241011151317.00005594@yahoo.com>
	<vebe6l$3mog5$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 13 Oct 2024 11:00:15 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="892c1d91ddc3c98c5e442b7e028c5cd9";
	logging-data="3378373"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/7uufyw+6oZwxIPinP/9tSueLTHMPfyn8="
Cancel-Lock: sha1:YOj2NZmL8Tf/IxQfDKAMnhoEesY=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 3738

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.