Jachym Holecek <freza@dspfpga.com> writes:

>> If so, I think I know what you're saying here, but I'd like to say that
>> I consider this use of volatile, while expedient, to be a problematic
>
> Why problematic?

Problematic because it prevents useful optimization; the values will
be re-fectched from memory more than necessary.

>> workaround for a deficient spl() implementation.
>
> How could be spl() implemented to avoid the need for volatiles?

As Jason mentioned, by making sure that they are both instruction
barriers and memory clobbers. Ordinary function calls satisfy this
constrtaint; macros and inline functions generally do not.

If you have those condtitions on your spl calls, and structure the
code so that the top half looks like:

... 
s = splfoo()
<work with memory region>
splx(s)
...

where it doesn't touch the memory region outside of the
spl()-protected block, then the compiler has enough information to
know that the contents of memory region A could change between one
spl-protected block and another, but that it won't change within the
block.

        - Nathan