I can't remember the specifics, but back when I could read VM source
code, I recall CP modules passed condition codes back when returning to
the caller using some scheme like you describe. I thought it was cool
and esoteric, but now I realize that even testing a condition code a
couple of instructions after it's set needs strong documentation so I'll
remember what I was doing when I look at my code a couple months later.
Regards, Gary
Gary Weinhold
Senior Application Architect
DATAKINETICS | Data Performance & Optimization
Phone +1.613.523.5500 x216
Email: [email protected]
Visit us online at www.DKL.com
E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
__________
On 2015-10-15 13:16, Paul Gilmartin wrote:
On 2015-10-15, at 10:45, John McKown wrote:
I had some "weird" assembler code which "optimized" something like that
long ago. I did a complicated series of test and ended with a CC for ==0 or
<0 or >0. I then used the IPM instruction to save the CC in a general
register. Later, I did an SPM in a number of places afterwards to restore
the CC before doing a branch.
It can't be too long ago. I recall struggling to backport some code
which used IPM...SPM to older hardware that lacked those instructions.
I refractured the intervening code so it never changed CC. In doing
so, I replaced:
SH Rx,=H(8)
by
LH Ry,=H(-4096)
LA Rx,4088(Rx,Ry)
My colleagues still sometimes argue, "That can't work!" Well, it
does work if you need only 24-bit or 31-bit range.
Incidentally, I tried:
LH Ry,=H(-4096)
USING -4096,Ry
LA Rx,-8(Rx)
... which also works. An old Bitsavers Assembler manual says the
range of a USING is limited to -x'FFFFFF' to +x'FFFFFF' (24-bits).
HLASM says, "non-negative" but reports no error. Is this a deliberate
restriction of the specification, with an oversight in implementation?
Tachyon reports the error.
And I have one outré case, not violating the current specification
of USING, where HLASM generates manifestly incorrect code. As I
envision the OCO logic, base-displacement resolution must have
encountered and ignored a 32-bit integer overflow.
-- gil
