It's interesting to see an actual use case for C union and bit mapping. In
all these years, I've never seen these used in programs I've worked with
because of portability issues and not really providing useful functionality for
those products.
Thanks, Jon.
On Friday, September 20, 2019, 03:23:25 PM PDT, Gord Tomlin
<gt.ibm.li...@actionsoftware.com> wrote:
Some snippage and interspersed comments...
On 2019-09-20 17:11, Jon Perryman wrote:
> For instance, mapping to C does not support remapping, redefinition or
> re-declaring variables such as "org" in assembler.
Actually, it does, using unions, but the results are not very pretty.
Here's an example from IHAIPA.
Assembler macro snippet:
IPAHEAD DS CL96 Header section
ORG IPAHEAD
IPAID DS CL4 Eye-catcher
IPALEN DS H Length
IPASP DS X Subpool
IPAVER DS X Version number
IPAICTOD DS CL8 TOD at completion of system initialization
IPALPARM DS CL8 IPL load parameter
ORG IPALPARM
IPAIODFU DS CL4 IODF unit address
IPALOADS DS CL2 LOADxx suffix
IPAPROMT DS CL1 Operator prompt flag
IPANUCID DS CL1 Nucleus ID
IPANAMES DS CL24 System name values
ORG IPANAMES
IPAHWNAM DS CL8 HWNAME value
IPALPNAM DS CL8 LPARNAME value
IPAVMNAM DS CL8 VMUSERID value
IPALPDSN DS CL44 IPL load parameter dataset name
IPALPDDV DS CL4 IPL load parameter dataset device number
C header snippet, generated by EDCDSECT:
union {
unsigned char _ipahead[96];
struct {
unsigned char _ipaid[4];
short int _ipalen;
unsigned char _ipasp;
unsigned char _ipaver;
unsigned char _ipaictod[8];
unsigned char _ipalparm[8];
unsigned char _filler1[72];
} _ipa_struct1;
struct {
unsigned char _filler2[16];
unsigned char _ipaiodfu[4];
unsigned char _ipaloads[2];
unsigned char _ipapromt;
unsigned char _ipanucid;
unsigned char _ipanames[24];
unsigned char _filler3[48];
} _ipa_struct2;
struct {
unsigned char _filler4[24];
unsigned char _ipahwnam[8];
unsigned char _ipalpnam[8];
unsigned char _ipavmnam[8];
unsigned char _ipalpdsn[44];
unsigned char _ipalpddv[4];
} _ipa_struct3;
} _ipa_union1;
>
> 6. C does not support unaligned fields (e.g. AL2, AL3 or AL4). If variable -
> dsect is not aligned properly, then you will need special handling to support
> these properly in C. Maybe an inline function to deal with this.
It does.
Snippet from CVT:
CVTAQAVT DS 0A - ADDRESS OF THE FIRST WORD OF THE TCAM
* DISPATCHER WHICH CONTAINS THE ADDRESS OF
* THE ADDRESS VECTOR TABLE (AVT). IF ZERO,
* TCAM IS NOT STARTED.
CVTTCMFG DC X'00' - TCAM FLAGS
CVTTCRDY EQU X'80' - TCAM IS READY TO ACCEPT USERS
CVTLDEV EQU X'40' - LOCAL DEVICE ATTACHED TO TCAM
* (MDC357) @Z40XA9A
CVTNWTCM EQU X'20' - MULTIPLE TCAM FEATURE ACTIVE. @D1A
CVTAQAVB DC AL3(0) - SAME AS CVTAQAVT ABOVE
Snipped from C struct generated using EDCDSECT:
struct {
int _cvttcrdy : 1,
_cvtldev : 1,
_cvtnwtcm : 1,
: 5;
int _cvtaqavb : 24;
} cvtaqavt;
Also see the following for a description of the use of #pragma packed by
EDCDSECT:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.cbcux01/genstruct.htm
The same page documents how various Assembler definitions, including
fields that are unaligned due to specification of a length value.
>
> Compile a C program that displays the SIZEOF(struct_name) and verify it
> matches the assembler calculated size of the dsect.
Very good advice. Everyone should do that.
Having said all that, I can guarantee that you will like the macros
Peter has generated better than those generated by EDCDSECT.
--
Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
Support: https://actionsoftware.com/support/
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
