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: Brett <ggtgp@yahoo.com>
Newsgroups: comp.arch
Subject: Re: 80286 protected mode
Date: Sun, 13 Oct 2024 19:36:04 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 66
Message-ID: <veh7f4$qapl$1@dont-email.me>
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>
 <veebg6$8if5$1@dont-email.me>
 <veg922$laau$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 13 Oct 2024 21:36:05 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="8cde5961b3f957604d1aa1c49a9c1719";
	logging-data="863029"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+9KOyU54QwTLu3L8Dx9TMn"
User-Agent: NewsTap/5.5 (iPad)
Cancel-Lock: sha1:r31dhK9BSzlQn240e42ikbkwGQc=
	sha1:MDFkhnb/HAh7c4uFFrlHba2HQg8=
Bytes: 4523

David Brown <david.brown@hesbynett.no> wrote:
> On 12/10/2024 19:26, Bernd Linsel wrote:
>> On 12.10.24 17:16, David Brown wrote:
>>> 
>>> 
>> [snip rant]
>>> 
>>> 
>> 
>> You are aware that this is c.arch, not c.lang.c?
>> 
> 
> Absolutely, yes.
> 
> But in a thread branch discussing C, details of C are relevant.
> 
> I don't expect any random regular here to know "language lawyer" details 
> of the C standards.  I don't expect people here to care about them. 
> People in comp.lang.c care about them - for people here, the main 
> interest in C is for programs to run on the computer architectures that 
> are the real interest.
> 
> 
> But if someone engages in a conversation about C, I /do/ expect them to 
> understand some basics, and I /do/ expect them to read and think about 
> what other posters write.  The point under discussion was that you 
> cannot implement an efficient "memmove()" function in fully portable 
> standard C.  That's a fact - it is a well-established fact.  Another 
> clear and inarguable fact is that particular ISAs or implementations are 
> completely irrelevant to fully portable standard C - that is both the 
> advantage and the disadvantage of writing code in portable standard C.
> 
> All I am asking Mitch to do is to understand this, and to stop saying 
> silly things (such as implementing memmove() by calling memmove(), or 
> that the /reason/ you can't implement memmove() efficiently in portable 
> standard C is weaknesses in the x86 ISA), so that we can clear up his 
> misunderstandings and move on to the more interesting computer 
> architecture discussions.

MemMove in C is fundamentally two void pointers and a count of bytes to
move.

C does not care what the alignment of those two void pointers is.

ALU’s are so cheap as to be free, a dedicated MM unit can have a shifter
and mask with a buffer, and happily copy aligned chunks from the source and
write aligned chunks to the dest, even though both are odd aligned in
different ways, and overlapping the same buffer.

Note that writes have byte enables, you can write 5 bytes in one go to
cache, to finish off the end of a series of aligned writes.

My 66000 only has one MM instruction because when you throw enough hardware
at the problem, one instruction is all you need.

And it also covers MemCopy, and yes there is a backwards copy version.

I detailed the hardware to do this several years ago on Real World Tech.
And such hardware has been available for many decades in DMA units.

The 6502 based GameBoy had a MemMove DMA unit as it was many times faster
copying bytes than the 6502 was, and doubled the overall performance of the
GameBoy.

One ring to rule them all.