On Wed, 2005-11-23 at 11:41, Robert Dewar wrote:
> Richard Earnshaw wrote:
>
> > This restriction rules out, for example, using a volatile value as an
> > input in many floating point operations (since the operations may trap
> > depending on the values read).
>
> I don't see this at all. If you have a volatile variable that traps
> in this situation, then that's just fine, you get the trap. The trap
> cannot occur unless the program is wandering into undefined areas in
> any case. Please give an exact scenario here, and explain why you
> think the standard or useful pragmatic considerations demand the
> treatment you suggest above.
> >
> > R.
Consider a non-load/store machine that has a floating-point operation that
can add a value in memory to another register:
fadd Rd, Rs, (mem) // Rd = Rs + (mem)
Now if (mem) is volatile and the value returned is a signalling NaN then
the trap handler has no way to recover that value except by
dereferencing (mem) again. That means we access (mem) twice.
Or consider any type of 3-operand instruction where both source operands
come from memory. If the first access is volatile and the second not
(but it page-faults) then, unless the machine has some way to cache the
first access, it will have to be repeated when the page fault handler
returns.
Finally, but probably less likely, consider a machine instruction that
can read multiple values from memory (ARM has one -- ldm). If an
address in the list is volatile and the list crosses a page boundary,
the instruction may trap part way through execution. In that case the
OS may have to unwind part of the instruction and retry it -- it can't
safely do that if there is a volatile access in the list.
R.
