Virtual-storage accessibility is an issue about which the Systems Architecture
team was often asked, by customers, ISVs, and IBM developers.
At a SHARE presentation in 2009, I dragged out my FrameMaker instruction
template and designed the IS IT SAFE (IIS) instruction in about 5 minutes. IIS
was a simple RXY-format instruction where the second operand designated a
storage location, and the first operand was ignored. The condition code was set
as follows:
CC0 Storage is accessible for both fetch and store.
CC1 Storage is accessible for fetch only
CC2 Storage is not accessible
The most important part of the instruction description was the programming note:
This instruction is absolutely useless!
Why? Because the CPU is clueless as to whether a dynamic-address-translation
(DAT) exception is due to the virtual address being paged out by the OS, or a
DAT exception is due to the virtual address being totally bogus. Only the OS
can tell you that correctly. I also recall that various OSes have service
routines to provide such information, but I don't recall what they are.
Part of the initial design criteria for transactional execution was to
efficiently provide a means by which a program could speculatively touch a
virtual address, and if the transaction aborted, then pretend you didn't mean
it (... my bad ... do over). Regrettably, in their finite wisdom, IBM has put
the coffin nail into nonconstrained TX.
