Your *+4 would be incorrect in more than 1 way.
Here's another case where more liberal immediate operands (LLILF
Rx,Q(CEExxxxx)) would come in handy.
sas
On 3/8/2017 10:23, Gary Weinhold wrote:
I think it is worth RFEing. Reentrant baseless code is a desirable
standard and IBM's own code should not be thwarting it. And over the
years my experience has been that LE has on occasion ignored HLASM
standards and trends. They should be reminded that they should
interface nicely with HLASM.
Gary Weinhold
Senior Application Architect
DATAKINETICS | Data Performance & Optimization
Phone: +1.613.523.5500 x216<tel:+1.613.523.5500%20x216>
Email: [email protected]<mailto:[email protected]>
[http://www.dkl.com/wp-content/uploads/2015/07/dkl_logo.png]<http://www.dkl.com/>
Visit us online at www.DKL.com<http://www.dkl.com/>
[http://www.dkl.com/wp-content/uploads/2015/08/banner.png]<http://www.dkl.com/mailsig>
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 2017-03-08 09:43, John McKown wrote:
This is likely not worth the bother, but I have a "problem" with the
CEEPCALL macro. Yes, I write LE enabled HLASM. Mainly so that I can
easily
inter-operate with C.
I like to use "baseless" coding techniques. One problem that I had, which
required a base register be used, is that I use the CEEPCALL macro
instead
of a CALL macro. CEEPCALL can invoke statically bound code (like CALL)
but
can also call DLL resident code. The code generated uses an "A" (add)
instruction with an in-stream constant, a QCON.
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.asma400/qcon.htm
. I have looked at the macro and there is no way to avoid this. The code
sequence looks like:
504+CEE0009F ALIAS C'CEE3INF'
505+ EXTRN CEE0009F
506+CEE0009F XATTR
SCOPE(IMPORT),REFERENCE(INDIRECT),REFERENCE(CODE)
...
0000009E 0700 521+ CNOP 0,4
000000A0 A7F4 0004 000000A8 522+ J CEE0009J
BRANCH AROUND QCON
000000A4 00000000 523+CEE0009Q DC Q(CEE0009F)
OFFSET TO DESCRIPTOR
000000A8 524+CEE0009J DS 0H
000000A8 58F0 C1F4 000001F4 525+ L 15,500(,12)
LOAD 15 WITH CEECAACRENT
000000AC 5AF0 B0A4 000000A4 526+ A 15,CEE0009Q
ADD OFFSET TO FUNC DESC @P0C
000000B0 0DEF 527+ BASR 14,15
This could "easily" be changed to something like:
CNOP 0,4
BRAS 15,CEE&SYSNDX.J or just *+4
DC Q(CEE&SYSNDX.F)
CEE&SYSNDX.J DS 0H
L 15,0(,15) LOAD OFFSET CONSTANT
A 15,0(,12) ADD IN CEECAACRENT
BASR 14,15
Note that I looked on a z/OS 2.2 system, and the above is true on that
system (I'm compiling on z/OS 1.12 at work, not 2.2 on a friend's
system).
Your opinions?
