sigh - the PTE A&D bits cause traps they way they do so that software can implement them (if it needs them, and not if it doesn't), it's an old trick and very much a RISC thing - not wanting to burden the hardware with something that software can do
There's no reason to sigh, it is a pretty goofy thing to both specify the bits as separate from the permissions, and check them, but not fill them out.
Going through RISCS I've implemented MMU code for:
MIPS - Has what they call a Dirty bit, but no separate RO bit, the dirty bit is really the ~RO bit.
SH* - See MIPS (lol, that could be their tagline)
Sparc - Doesn't really specify an MMU, but the "Reference MMU" does specify that the Modified bit (AKA the Dirty bit) is filled in by the MMU
PowerPC - Referenced and Changed bits in the PTEs are updated by the MMU.
ARM - Doesn't specify any A&D like construct.
Am I missing any? I can't think of an arch off the top of my head that has separate A&D from RWX, and doesn't have the MMU fill them in for you. Well other than RISC-V, lol.
Vax's had modified bits, 68030s had both (dirty managed in software), 80x896s have both [an 'unnamed' risc architecture (I worked on) had both, managed in software]
The big advantage of handling this stuff in software is that any hardware doing this has to go through the system caches which is just really messy - better to use the existing coherent paths already provided and provide hardware support so you don't have to do this often
accessed and dirty (where a page has been accessed and whether it has been changed)
You need to know "dirty" to know whether a page needs to be written back to a swap file (or needs to be duplicated in lazy copying cases), you may want to know "accessed" if you want to do the accounting to push out less often used pages when memory gets short
