Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: David Brown 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: References: <2024Oct6.150415@mips.complang.tuwien.ac.at> <2024Oct7.093314@mips.complang.tuwien.ac.at> <7c8e5c75ce0f1e7c95ec3ae4bdbc9249@www.novabbs.org> <2024Oct8.092821@mips.complang.tuwien.ac.at> <86y12uy8ku.fsf@linuxsc.com> 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: 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.