OSDev.org

rdos wrote:Of course, that only works with assembly code (or inline assembly).

Or a good compiler.

Octocontrabass wrote:

rdos wrote:Of course, that only works with assembly code (or inline assembly).

Or a good compiler.

The code is incomprehensible. It easy to understand that btr will set a bit and return the original value in CY. It's also easy to understand that by locking the instruction. you will have a lock-free "xchg" on the bit level. The C code is a hack that you have to analyse to understand what it actually does, and there is no guarantee it will be translated to lock-free code, if the atomic_fetch_and function even is supported.

My position is that if the C equivalent of some code is incomprehensible, and the assembly version is easy to understand, there is no reason to use the C version. I only use C when it's easier to understand than the corresponding assembly code.

Particularly with lock-free code, there is a need to understand how it operates and make sure it can handle all possible cases. If the code is incomprehensible, this analysis becomes impossible to.

rdos wrote:The code is incomprehensible.

Seriously? Seems to me the code is pretty explicit about what it is doing.

rdos wrote:It easy to understand that btr will set a bit and return the original value in CY.

Yes, if you read the CPU manual.

rdos wrote:The C code is a hack that you have to analyse to understand what it actually does,

Not if you read the spec on cppreference or anywhere else. So not all that different from your assembler code. It's just newer.

rdos wrote:and there is no guarantee it will be translated to lock-free code, if the atomic_fetch_and function even is supported.

Nothing is certain except death and taxes. However, anything claiming C11 support has a macro to test both of these questions (__STDC_NO_ATOMICS__ and ATOMIC_INT_LOCK_FREE, respectively). And I can guarantee that atomic_fetch_and runs on more platforms than your "btr" instruction. Oh, but it won't work with your beloved OpenWatcom, right? Well, not all of us hobble ourselves in this way.

rdos wrote:Particularly with lock-free code, there is a need to understand how it operates and make sure it can handle all possible cases. If the code is incomprehensible, this analysis becomes impossible to.

I'm sorry, but atomic_fetch_and() does exactly what it says on the tin. If it was the explicit version, and the programmer was messing about with memory orders, then I would understand your apprehension, but this is the bog-standard sequential consistency version. So you get the same semantics on a weakly ordered system as on x86.

nullplan wrote:Oh, but it won't work with your beloved OpenWatcom, right? Well, not all of us hobble ourselves in this way.

I've written the Rdos support myself for OpenWatcom, so I could create the function myself if I wanted to. However, I don't believe physical memory management or scheduling code should be written in C/C++.

rdos wrote:

nullplan wrote:Oh, but it won't work with your beloved OpenWatcom, right? Well, not all of us hobble ourselves in this way.

I've written the Rdos support myself for OpenWatcom, so I could create the function myself if I wanted to. However, I don't believe physical memory management or scheduling code should be written in C/C++.

There is nothing inherently CPU specific about physical memory management or scheduling.

A page frame is a page frame, regardless of its size or how the CPU maps it from virtual to physical address.

Or are you talking about the mechanism of mapping a virtual address to a physical page, and the mechanism of task switching, both of which may require some assembly?