IBM Mainframe Discussion List <[email protected]> wrote on 04/29/2013 06:47:16 PM:
> From: Bernd Oppolzer <[email protected]> > Another story: > I once had a hard time to understand a (very old) assembler module. It > searched > strings in another string, and the string to look for was specified > together with a > search direction (from left, from right) and a comparison operand > (equal, not equal, > less, greater than). Looked like this: > > L=JOHN - search string from left, look for string equal to JOHN > R^* - search from right, look for string that is not equal to * > L<A - search first substring (from left) that is lower than A > > etc. etc. > > The problem for me, why I didn't understand the module first, was: > > the comparison operand =, ^, >, < was translated using some bit operations > giving the mask of the BC instruction following the CLC. But: there was > no check, if the comparison operand was valid. There was simply some > logic which I don't recall in detail, which translated the four possible > "legal" > comparison operands, yielding the four corresponding masks for the BC. > (It was not a TR table, the original author of the routine probably would > have considered this a waste of 256 bytes). It also did some mystery > to other possible comparison operands which are not supported > (and not checked). > > I first had no idea, how the one and only CLC in the module does > all those different searches and comparisons ... > > Kind regards > > Bernd > > > > > Am 29.04.2013 17:42, schrieb John McKown: > > 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. > >>> A number of features of the original 360 instruction set came from the 7094 (and related machines), e.g. BXH & BXLE. I was given at one point the Assembler source of the fast Fourier transform, which I wanted to port to the 360. I had to read the 94 PoOp several times before I caught on that the EX instruction on the 94 ORed the register (can't remember which one but I remember only one 36-bit accumulator and 7 18-bit index registors) with the entire instruction. The code processed the input both forward and backward and changed the opcodes for each direction. I quickly gave up. ----------------------------------------- The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
