Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.arch
Subject: Re: 80286 protected mode
Date: Fri, 11 Oct 2024 14:10:13 +0200
Organization: A noiseless patient Spider
Lines: 98
Message-ID: <veb4j5$3kjt3$2@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 11 Oct 2024 14:10:13 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="34c9fd498e28e7a360ed2c2136f69c93";
	logging-data="3821475"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18407deuYEosZZkBp32Z5FTAyQSjW7dG8w="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:IlBX9D3sjxo88I62xNyM5Xq1heQ=
Content-Language: en-GB
In-Reply-To: <35cb536e6310a38f0269788881cffdaf@www.novabbs.org>
Bytes: 5226

On 10/10/2024 23:30, MitchAlsup1 wrote:
> On Thu, 10 Oct 2024 19:21:20 +0000, David Brown wrote:
> 
>> On 10/10/2024 20:38, MitchAlsup1 wrote:
>>>>> This is more a symptom of bad ISA design/evolution than of libc
>>>>> writers needing superpowers.
>>>>
>>>> No, it is not.  It has absolutely /nothing/ to do with the ISA.
>>>
>>> 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.
> 
>        {
>             memmove( p, q, size );
>        }
> 

What is that circular reference supposed to do?  The whole discussion 
has been about the /fact/ that you cannot implement the "memmove" 
function in a C standard library using fully portable standard C code.

Do you think you can just write this :

void * memmove(void * s1, const void  * s2, size_t n)
{
	return memmove(s1, s2, n);
}

in your library's source?


You can implement "memcpy" in portable standard C, using a loop and 
array or pointer syntax (somewhat like your loop below, but with the 
correct type for the index).  But you cannot do so for memmove() because 
you cannot identify the direction you need to run your loop in an 
efficient and fully portable manner.

It does not matter what the target is - the target is totally irrelevant 
for /portable/ standard C code.  If the target made a difference, it 
would not be portable!

I can't understand why this is causing you difficulty.

Perhaps you simply didn't understand what you wrote a few posts back, 
when you claimed that the reason people writing portable standard C code 
cannot write an efficient memmove() implementation is "a symptom of bad 
ISA design".


> Where the compiler produces the MM instruction itself. Looks damn
> close to standard C to me !!
> OR
>        for( int i = 0, i < size; i++ )
>             p[i] = q[i];
> 
> Which gets compiled to memcpy()--also looks to be standard C.
> OR
> 
>        p_struct = q_struct;
> 
> gets compiled to::
> 
>        memmove( &p_struct, &q_struct, sizeof( q_struct ) );
> 
> also looks to be std C.


Those are standard C, yes.  And a good compiler will optimise such code. 
  And if the target has some kind of scalable vector support or other 
dedicated instructions for moving or copying memory, it can do a better 
job of optimising the code.

That has /nothing/ to do with the point under discussion.


I think you are simply confused about what you are talking about here. 
Either you don't know what is meant by writing portable standard C, or 
you don't know what is meant by implementing a C standard library, or 
you haven't actually been reading the posts you replied to.  You seem 
determined to make the point that /your/ ISA has useful and efficient 
instructions and features for memory copy functionality, while the x86 
ISA does not, and that means /your/ ISA is good design and the x86 ISA 
is bad design.

Now, I will fully agree with you that the x86 is not a good design.  The 
modern x86 processor devices are proof that you /can/ polish a turd. 
And I fully agree with you that instructions for arbitrary length vector 
instructions of various sorts (of which memory copying is the simplest 
operation) have many advantages over SIMD using fixed-size vector 
registers.  (ARM and RISC-V also agree with you there.)

But that is all irrelevant to the discussion.