Re: Linkage Editor Include Order
> Is it possible to influence the order the linkage editor includes objects? I don't know about the linkage editor, but the Binder ;) has an ORDER statement that can be used. === Adam Johanson Broadcom Mainframe Software Division
Re: Avoiding SIIS - (Was Base-less macros)
Wendell wrote: > From Tony's explanation concerning moving the TR command to the data area via LOCTR, can I surmise that it might be counter-productive to do so--that leaving the TR and EX commands in consecutive memory is more efficient? My $0.02 is that I'm not so sure about the "do it once with length of 1, then do it for real with EX" approach, but what is mentioned in the Kevin Shum paper that Tony referenced is that you want the target of the EX instruction "close" to the EX itself, so that the target instruction might already be in the i-cache and won't have to be fetched. I usually try to place it like this: SUBROUTINE_1DS0H ... EXR2,EX_TARGET ... BRR14 . EX_TARGET MVC 0(*-*,R3),0(R4) . SUBROUTINE_2DS0H ... so that the EX target isn't in a data area, but is "close" to the EX itself. ====== Adam Johanson R Software Engineer adam.johan...@broadcom.com -- 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.
Re: Avoiding SIIS - (Was Base-less macros)
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 Software Engineer adam.johan...@broadcom.com -- 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.
Re: John Ehrman Assembler Text
There is also this page which indexes some presentations and other documents that he did. My favorite on here is the one on macros and conditional assembly... The examples and explanations are great. https://www.ibm.com/support/pages/node/735907 == Adam Johanson R Software Engineer adam.johan...@broadcom.com
