Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Vir Campestris <vir.campestris@invalid.invalid>
Newsgroups: comp.arch
Subject: Re: 80286 protected mode
Date: Sun, 20 Oct 2024 21:51:30 +0100
Organization: A noiseless patient Spider
Lines: 49
Message-ID: <vf3qgi$ijah$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>
 <veudt1$3ep62$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 20 Oct 2024 22:51:30 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="df514cdf0f2687bddaad985d2fb1ee99";
	logging-data="609617"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+wws5nyi5M1H0E8NIURd2ahAthzrGnH00="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:hQkuBJixrw4s56UlorpHPEEP9FU=
In-Reply-To: <veudt1$3ep62$1@dont-email.me>
Content-Language: en-GB
Bytes: 3699

On 18/10/2024 20:45, David Brown wrote:
> 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.)
> 
Ah, I see your point. Because some implementations will require 
communication with the OS there cannot be a truly portable malloc.

>> 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.
> 
It's a long time since I had to mistrust a compiler so much that I was 
pulling the assembler apart. It sounds as though they have got smarter 
in the meantime.

I just checked BTW, and you are correct.

Andy