There is no architectural restriction about not modifying instructions "on the fly". The z does not have the concept of "data" versus "instruction" storage. But, IMO, it is an abomination. There are two major reasons and one minor one. First, it causes a flush of the I (and D?) cache. This impacts performance quite a bit. Second, it makes the code not reentrant. And a minor point, due to not being reentrant, is that the code cannot be placed in read-only memory. Rather than modifying an instruction on the fly, I either use an EX of the instruction, when possible; or I move a the template of the instruction into a data area and EX that. <reflection> Reminds me of an interesting facet of the Xerox Sigma architecture. All instructions were a full word in length. And the registers could be address similar to the way the z does; but were also mapped into memory locations 0..15 . So if you referenced memory location 0, you actually accessed register 0. So you could construct an instruction in register "n" <15 and then put a branch in register "n+1" (like a BR 15). You then did a branch to subroutine to register "n" to execute the instruction. The Sigma didn't have an equivalent of the EX as I recall. Kind of makes me wish that the z had an EXG which would EX a single instruction created in single 64 bit Grande register. That would work for _most_ instructions. Might even be more interesting if the EXG looked at the opcode to determine if the instruction was in the specified register or was in a Grande register (even-odd?) pair. </reflection>
On Mon, Apr 29, 2013 at 10:06 AM, Paul Gilmartin <[email protected]> wrote: > On Mon, 29 Apr 2013 10:50:25 -0400, John Gilmore wrote: > >>It is not at all a bad subroutine. In many contexts the form of the >>second argument would be gratuitously clumsy, but this routine was >>(almost certainly) intended to be called from COBOL, and eight '0' or >>'1' characters is appropriate for COBOL. >> >>I would not myself have used assembler mnemonics, whicjh are not very >>perspicuous for COBOL programmers, to identify which operation is to >>be performed,;and linear search is not the best way to identify which >>of them has been supplied; but these are quibbles. >> > I might have avoided the search entirely by providing separate entry > points for the various functions. It seems unlikely to me that a > programmer would want to choose at runtime which function to > perform. > > Has the z nowadays any memory protection mode that forbids fetching > instructions from data storage? (Many other processors have such.) > > But what's the break-even between linear search and binary search? > I suspect that it's at about a handful. And linear search is probably > friendlier to branch prediction logic than binary search. > > -- gil > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN -- This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
