The subroutine that was originally posted didn't modify itself, but it
constructed a
little subroutine (one instruction and branch for return) in a working
area which was
provided as a parameter by the caller. So there is no reentrant problem
and no
flushing of the I-cache.
Thank you for posting this subroutine and thank you to Mr. Joel C. Ewing
for
the explanation.
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.
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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
