Re: 80286 protected mode

On 20/10/2024 22:51, Vir Campestris wrote:

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.

Yes.
I think /every/ implementation will require communication with the OS, if there is an OS - otherwise it will need support from other parts of the toolchain (such as symbols created in a linker script to define the heap area - that's the typical implementation in small embedded systems).
The nearest you could get to a portable implementation would be using a local unsigned char array as the heap, but I don't believe that would be fully correct according to the effective type rules (or the "strict aliasing" or type-based aliasing rules, if you prefer those terms).  It would also not be good enough for the needs of many programs.
Of course, a fair amount of the code for malloc/free can written in fully portable C - and almost all of it can be written in a somewhat vaguely defined "widely portable C" where you can mask pointer bits to handle alignment, and other such conveniences.

 

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.
 

Looking at the generated assembly is usually not a matter of mistrusting the compiler.  One of the reasons I do so is to check that the compiler can generate efficient object code from my source code, in cases where I need maximal efficiency.  I'd rather not write assembly unless I really have to!