Path: ...!news.roellig-ltd.de!news.mb-net.net!open-news-network.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "Brian G. Lucas" <bagel99@gmail.com>
Newsgroups: comp.arch
Subject: Re: 80286 protected mode
Date: Sun, 13 Oct 2024 15:32:04 -0500
Organization: A noiseless patient Spider
Lines: 130
Message-ID: <vehao4$qp9r$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> <veefdd$96k9$1@dont-email.me>
 <ln1bb5Fi8gmU1@mid.individual.net> <20241013122622.000037d5@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 13 Oct 2024 22:32:05 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="2fd339f3735599786fa380b153ef08f4";
	logging-data="877883"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18qz60C+THf7QqtO7Rj6fwM"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:tUPK7znivsd5jp0Z1hxS/8Kt1ZM=
Content-Language: en-US
In-Reply-To: <20241013122622.000037d5@yahoo.com>
Bytes: 7048

On 10/13/24 4:26 AM, Michael S wrote:
> 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:
>>>> On 12/10/2024 01:32, MitchAlsup1 wrote:
>>>>> On Fri, 11 Oct 2024 22:02:32 +0000, David Brown wrote:
>>>>>   
>>>>>> On 11/10/2024 20:55, MitchAlsup1 wrote:
>>>>>>> On Fri, 11 Oct 2024 12:10:13 +0000, David Brown wrote:
>>>>>>>   
>>>>>>>>
>>>>>>>> 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?
>>>>>>>
>>>>>>>          .global memmove
>>>>>>> memmove:
>>>>>>>          MM     R2,R1,R3
>>>>>>>          RET
>>>>>>>
>>>>>>> sure !
>>>>>>
>>>>>> You are either totally clueless, or you are trolling.  And I
>>>>>> know you are not clueless.
>>>>>>
>>>>>> This discussion has become pointless.
>>>>>
>>>>> 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.
>>>>
>>>> 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.
>>>>   
>>>    
>>
>>
>>     [ snip discussion of HW ]
>>
>>
>>> In short your complaints are wrong headed in not understanding what
>>> hardware memcpy can do.
>>
>>
>> I think your reply proves David's complaint: you did not read, or did
>> 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.
>>
>> Obviously memmove() can be implemented efficently in non-standard C
>> where such pointers can be compared, or by sequences of ordinary ALU
>> 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().
>>
> 
> 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)
> {
>   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 {
>    return __builtin_memmove(dest, src, count);
> }
> 
Well, something like that.  Clang will generate LLVM IR which acts like
a builtin_memmove that the backend can match and emit the MM instruction.

> However, implementing the first variant efficiently is well within
> abilities of good compiler.
>