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, 18 Oct 2024 21:45:37 +0200
Organization: A noiseless patient Spider
Lines: 39
Message-ID: <veudt1$3ep62$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>
 <be506ccef76d682d13205c69c761a086@www.novabbs.org>
 <ve6oiq$2pag3$1@dont-email.me> <ve6tv7$2q6d5$1@dont-email.me>
 <86y12uy8ku.fsf@linuxsc.com> <jwv34kx5afd.fsf-monnier+comp.arch@gnu.org>
 <venpin$241bk$2@dont-email.me> <veu2uv$3cluq$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 18 Oct 2024 21:45:37 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="1859693d85403534ddf05d6894436fe8";
	logging-data="3630274"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+85ss8BKs/lAP33Paj5NmvqfiT6kj1hD0="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:bPD8I9AuDZbXLNeN+koW+wlLlT8=
Content-Language: en-GB
In-Reply-To: <veu2uv$3cluq$1@dont-email.me>
Bytes: 3211

On 18/10/2024 18:38, Vir Campestris wrote:
> On 16/10/2024 08:21, David Brown wrote:
>>
>> I don't see an advantage in being able to implement them in standard 
>> C. I /do/ see an advantage in being able to do so well in 
>> non-standard, implementation-specific C.
>>
>> The reason why you might want your own special memmove, or your own 
>> special malloc, is that you are doing niche and specialised software. 
>> For example, you might be making real-time software and require 
>> specific time constraints on these functions.  In such cases, you are 
>> not interested in writing fully portable software - it will already 
>> contain many implementation-specific features or use compiler extensions.
>>
> I have a vague feeling that once upon a time I wrote a malloc for an 
> embedded system. Having only one process it had access to the entire 
> memory range, and didn't need to talk to the OS. Entirely C is quite 
> feasible there.
> 

Sure - but you are not writing portable standard C.  You are relying on 
implementation details, or writing code that is only suitable for a 
particular implementation (or set of implementations).  It is normal to 
write this kind of thing in C, but it is non-portable C.  (Or at least, 
not fully portable C.)

> But memmove? On an 80286 it will be using rep movsw, rather than a 
> software loop, to copy the memory contents to the new location.
> 
> _That_ does require assembler, or compiler extensions, not standard C.
> 

It would normally be written in C, and the compiler will generate the 
"rep" assembly.  The bit you can't write in fully portable standard C is 
the comparison of the pointers so you know which direction to do the 
copying.