Path: ...!3.eu.feeder.erje.net!feeder.erje.net!news2.arglkargh.de!news.in-chemnitz.de!news.swapon.de!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: Sun, 13 Oct 2024 13:58:14 +0200
Organization: A noiseless patient Spider
Lines: 129
Message-ID: <vegckn$ltgv$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 13 Oct 2024 13:58:16 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="b54a20c64d8868b1fa849b5be136a660";
	logging-data="718367"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19a9wGmBgAqK9R3LizaPeQRzS7ucZU0ocA="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:/VnYiJweMhcOla0LYp68K4sByYM=
In-Reply-To: <veefdd$96k9$1@dont-email.me>
Content-Language: en-GB
Bytes: 7403

On 12/10/2024 20: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.
> 
> There are only two decisions to make in memcpy, are the copies less than
> copy sized aligned, and do the pointers overlap in copy size.
> 

Are you confused about memcpy() and memmove()?  If so, let's clear that 
one up from the start.  For memcpy(), there are no overlap issues - the 
person using it promises that the source and destination areas do not 
overlap, and no one cares what might happen if they do.  For memmove(), 
the areas /may/ overlap, and the copy is done as though the source were 
copied first to a temporary area, and then from the temporary area to 
the destination.

For memcpy(), there can be several issues to consider for efficient 
implementations that can be skipped for a simple loop copying byte for 
byte.  An efficient implementation will probably want to copy with 
larger sizes, such as using 32-bit, 64-bit, or bigger registers.  For 
some targets, that is only possible for aligned data (and for some, 
unaligned accesses may be allowed but emulated by traps, making them 
massively slower than byte-by-byte accesses).  The best choice of size 
will be implementation and target dependent, as will methods of 
determining alignment (if that is relevant).  I'm guessing that by your 
somewhat muddled phrase "are the copies less than copy sized aligned", 
you meant something on those lines.

For memmove(), you generally also need to decide if your copy loop 
should run upwards or downwards, and that must be done in an 
implementation-dependent manner.  It is conceivable that for a target 
with more complex memory setups - perhaps allowing the same memory to be 
accessible in different ways via different segments - that this is not 
enough.

> For hardware this simplifies down to perhaps two types of copies, easy and
> hard.

For most targets, yes.

> 
> If you make hard fast, and you will, then two versions is all you need, not
> the dozens of choices with 1k of code you need in C.
> 

That makes little sense.  What "1k of code" do you need in C? 
Implementations of memcpy() and memmove() are implementation and 
target-specific, not general portable standard C.  There is no single C 
implementation of these functions.

It is an obvious truism that if you have hardware instructions that can 
implement an efficient memcpy() and/or memmove() on a target, then the 
implementation-specific implementations of these functions on that 
target will be small, simple and efficient.

> Often you know which of the two you want at compile time from the pointer
> type.
> 
> In short your complaints are wrong headed in not understanding what
> hardware memcpy can do.
> 

What complaints?  I haven't made any complains about implementing these 
functions.