Path: ...!feeds.phibee-telecom.net!2.eu.feeder.erje.net!feeder.erje.net!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: Thu, 10 Oct 2024 23:54:15 +0300
Organization: A noiseless patient Spider
Lines: 80
Message-ID: <20241010235415.00003ecd@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>
	<xnWNO.131617$WtV9.8243@fx10.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 10 Oct 2024 22:54:22 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="33a0c6c0cd6d993bf9d12efe2a2dae7e";
	logging-data="3458597"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/0TwsbSy4AOMk97ZUtbUlC1yNQc4Y/z8Y="
Cancel-Lock: sha1:rYrwBZ5ShdBLM66FtiXH+UigP7g=
X-Newsreader: Claws Mail 4.1.1 (GTK 3.24.34; x86_64-w64-mingw32)
Bytes: 4529

On Thu, 10 Oct 2024 20:00:29 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:

> David Brown <david.brown@hesbynett.no> writes:
> >On 10/10/2024 20:38, MitchAlsup1 wrote:  
> >> On Thu, 10 Oct 2024 6:31:52 +0000, David Brown wrote:
> >>   
> 
> >> 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.
> >
> >The use of wider register sizes can help to some extent, but not
> >once you have reached the width of the internal buses or cache
> >bandwidth.
> >
> >In general, there will be many aspects of a C compiler's code
> >generator, its run-time support library, and C standard libraries
> >that can work better if they are optimised for each new generation
> >of processor. Sometimes you just need to re-compile the library with
> >a newer compiler and appropriate flags, other times you need to
> >modify the library source code.  None of this is specific to
> >memmove().
> >
> >But it is true that you get an easier and more future-proof
> >memmove() and memcopy() if you have an ISA that supports scalable
> >vector processing of some kind, such as ARM and RISC-V have, rather
> >than explicitly sized SIMD registers.
> >  
> 
> Note that ARMv8 (via FEAT_MOPS) does offer instructions that handle
> memcpy and memset.
> 
> They're three-instruction sets;  prolog/body/epilog. There are
> separate sets for forward vs. forward-or-backward copies.
> 
> The prolog instruction preconditions the copy and copies
> an IMPDEF portion.
> 
> The body instruction performs an IMPDEF Portion and
> 
> the epilog instruction finalizes the copy.
> 
> The three instructions are issued consecutively.

People that have more clue about Arm Inc schedule than myself
expect Arm Cortex cores that implement these instructions to be
announced next May and to appear in actual [expensive] phones in 2026.
Which probably means 2027 at best for Neoverse cores. 

It's hard to make an educated guess about schedule of other Arm core
designers.