Path: ...!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 Newsgroups: comp.arch Subject: Re: 80286 protected mode Date: Sun, 13 Oct 2024 12:26:22 +0300 Organization: A noiseless patient Spider Lines: 126 Message-ID: <20241013122622.000037d5@yahoo.com> References: <2024Oct6.150415@mips.complang.tuwien.ac.at> <2024Oct7.093314@mips.complang.tuwien.ac.at> <7c8e5c75ce0f1e7c95ec3ae4bdbc9249@www.novabbs.org> <2024Oct8.092821@mips.complang.tuwien.ac.at> <73e776d6becb377b484c5dcc72b526dc@www.novabbs.org> <2b31e1343b1f3fadd55ad6b87d879b78@www.novabbs.org> <35cb536e6310a38f0269788881cffdaf@www.novabbs.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Injection-Date: Sun, 13 Oct 2024 11:25:48 +0200 (CEST) Injection-Info: dont-email.me; posting-host="892c1d91ddc3c98c5e442b7e028c5cd9"; logging-data="3378373"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/dfqWr3RHXNcuhm+/2QHQwzD4dL5tlGTQ=" Cancel-Lock: sha1:VBeqQzaI77Mc838jNeaxbZ1248E= X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32) Bytes: 6879 On Sun, 13 Oct 2024 10:31:49 +0300 Niklas Holsti wrote: > On 2024-10-12 21:33, Brett wrote: > > David Brown wrote: =20 > >> On 12/10/2024 01:32, MitchAlsup1 wrote: =20 > >>> On Fri, 11 Oct 2024 22:02:32 +0000, David Brown wrote: > >>> =20 > >>>> On 11/10/2024 20:55, MitchAlsup1 wrote: =20 > >>>>> On Fri, 11 Oct 2024 12:10:13 +0000, David Brown wrote: > >>>>> =20 > >>>>>> > >>>>>> Do you think you can just write this : > >>>>>> > >>>>>> void * memmove(void * s1, const void=C2=A0 * s2, size_t n) > >>>>>> { > >>>>>> =C2=A0=C2=A0=C2=A0=C2=A0return memmove(s1, s2, n); > >>>>>> } > >>>>>> > >>>>>> in your library's source? =20 > >>>>> > >>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 .global memmove > >>>>> memmove: > >>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 MM=C2=A0=C2=A0=C2=A0=C2=A0 R2= ,R1,R3 > >>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RET > >>>>> > >>>>> sure ! =20 > >>>> > >>>> You are either totally clueless, or you are trolling.=C2=A0 And I > >>>> know you are not clueless. > >>>> > >>>> This discussion has become pointless. =20 > >>> > >>> 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. =20 > >> > >> 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. > >> =20 > > =20 >=20 >=20 > [ snip discussion of HW ] >=20 >=20 > > In short your complaints are wrong headed in not understanding what > > hardware memcpy can do. =20 >=20 >=20 > I think your reply proves David's complaint: you did not read, or did=20 > 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. >=20 > Obviously memmove() can be implemented efficently in non-standard C=20 > where such pointers can be compared, or by sequences of ordinary ALU=20 > 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(). >=20 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)=20 { 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 {=20 return __builtin_memmove(dest, src, count);=20 } However, implementing the first variant efficiently is well within abilities of good compiler.