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 <already5chosen@yahoo.com>
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>
	<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>
	<35cb536e6310a38f0269788881cffdaf@www.novabbs.org>
	<veb4j5$3kjt3$2@dont-email.me>
	<ab65eba51e4d4adc988e54df4a5fc7eb@www.novabbs.org>
	<vec79o$3qmbc$1@dont-email.me>
	<bbd2567ea1b9673fca27e3e51f19da9f@www.novabbs.org>
	<vee3st$6uoe$1@dont-email.me>
	<veefdd$96k9$1@dont-email.me>
	<ln1bb5Fi8gmU1@mid.individual.net>
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 <niklas.holsti@tidorum.invalid> wrote:

> On 2024-10-12 21:33, Brett wrote:
> > David Brown <david.brown@hesbynett.no> 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.