In article <[email protected]> you
wrote:
> On Mon, 29 Aug 2016 07:51:19 -0700, Charles Mills <[email protected]> wrote:
> >Hmmm. To me, that strategy seems appropriate for a report program ("this
> >field is not relevant to this type of transaction so print blanks or
> >asterisks") but not for a dump program. Isn't a dump -- consider the name --
> >supposed to be "here it all is, as it all is, you figure out what is
> >relevant"?
> In XPLINK, a program does not necessarily save all of the registers, so the
> contents of the location in the save area that is designated for that
> register
> doesn't necessarily have any meaning. In any case, registers 0-3 are not
> saved,
> so it would have no meaning to display contents for those registers in the
> XPLINK (downstack) save area.
> Indeed, if a given XPLINK program were to save only registers 6-10, the
> contents
> of registers 4, 5, and 11-15 are meaningless. The unused parts of the save
> areas
> are not zeroed, and the residual data does not have any value. In particular,
> you
> cannot assume that the doubleword that is allocated for R11 contained an R11
> value from a previous call because of the way the stack frames are allocated.
> The reference for this information is the LE Vendor Interfaces manual.
> Yes, it is XPLINK-64. The only linkage that LE supports in AMODE 64 is
> XPLINK-64.
> And XPLINK is not anything like standard linkage. It is possible for an
> XPLINK-64
> program to call a non-XPLINK program that is not LE enabled, but AFAIK it can
> only call an AMODE 64 non-XPLINK program because the save area that is passed
> is a 144-byte save area within the XPLINK stack, and is above the bar. An
> assembler program would typically use F4SA format to save its caller's
> registers.
You can call non-XPLINK non-LE 31-bit code from assembler. Just make sure to
allocate
(if needed) a 72 byte save area below the bar and point R13 at it. Construct a
normal parm list below the bar as well and point R1 at that. All the storage
that
the 31-bit program is expected to access must also be below the bar. Make sure
to SAM31 before calling and SAM64 when you come back.
> For XPLINK-64 to call XPLINK may be possible, but it would require that a new
> enclave be established. Here I am at (or beyond) the limits of my knowledge.
> XPLINK and XPLINK-64 are not compatible. Part of the reason is that the
> Common Anchor Area (CAA) is a different format and the mappings for the two
> formats are not compatible. Just as one example, in in a 24/31-bit CAA the
> field
> CEECAAPCB is a 4-byte field at offset X'2F4'. In an XPLINK-64 CAA, CEECAAPCB
> is at offset X'390'. At offset X'390' in a 24/31-bit CAA is CEECAASIGNGPTR.
> One
> would have thought that they would have at least used different names, and
> locations that are unused in the older CAA. They didn't.
> And so, when Cobol and PL/I support AMODE 64, it will be only XPLINK-64, and
> you will only be able to use it if you don't need to mix AMODE 64 and AMODE
> 31
> Cobol and/or PL/I programs.
> And, by the way, the main reason for XPLINK is to save a few instructions on
> program linkage. But making a call to a non-XPLINK program requires rather
> more
> instructions than just using standard linkage. And one of the things that
> Cobol
> and PL/I programs typically do a lot of is I/O. Those I/O calls are standard
> linkage
> calls to, for example, GET and PUT. So the benefits of XPLINK evaporate.
> </soapbox>
> --
> Tom Marchant
--
Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive
[email protected] (919) 531-5637 Cary, NC 27513
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
