For the first 2 examples, those are not SIIS violations because no modification of storage takes place. The modification of the instruction happens in the core itself (I once heard it called the "instruction register" where this happens... I can't verify the validity of that statement).
In the 3rd example, it depends on where R5 is pointing as to whether or not that's a SIIS violation. If where R5 points to contains instructions "close by", then yes. If it's a data-only area, then it's not a SIIS violation. To be a SIIS violation, you have to modify storage in the same CPU cache line where instructions reside. If the 3rd example didn't use MF= and modified the parmlist generated inline by the macro, then yes, that would be a SIIS violation as you're modifying storage that's intermixed with instructions. ========================== Adam Johanson R&D Software Engineer [email protected] -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.
