> XLC has a DSECT conversion utility.
Surprisingly, I think I must have been the only one to generate IPCS mapping
automatically using assembler macro's. Less than 100 lines of simple code
greatly improved dump reading. As a product developer, I had to read a lot of
dumps and this saved a lot of time.
This same implementation would work for conversion to any language. The
problem is actually with the mapping to the destination language. For instance,
mapping to C does not support remapping, redefinition or re-declaring variables
such as "org" in assembler.
Here is the logic I would use for mapping to C. Sorry if I don't get something
quite right. It's been a very long time since I wrote these macro's and the
source is backed up somewhere. Output would be to syspunch.
Sadly, this would be a lot easier if C had a true macro language instead of
it's limited pre-processing language.
Macro called from assembler source file has a parm with the DSECT mapping macro
name:
1. Call dsect mapping macro.
2. OPSYN DSECT and CSECT to macro #DSECT. OPSYN DC and DS to macro #DS. OPSYN
ORG to macro #ORG. OPSYN EQU to macro #EQU.
3. Call dsect mapping macro.
4. call macro #END
Macro #DSECT simply closes the previous structure with a comment about struct
size and generate a new struct using the label.
Macro #END simply closes the previous structure with a comment about struct
size.
Macro #ORG simply exits. Remapping logic is in macro #DS.
Macro #EQU if n'syslist > 1 then call #DS macro passing &syslist otherwise this
is a flag. Maybe a C macro that matches the variable name that calls a specific
inline C function for this flag. Another possibility is test creating a C
struct with 8 bool variables to see if it is 1 byte long. If so, then you may
be able to use a C struct with bool variables. If there are multi bit flags,
then you may need to add C macro's to support the combination.
Macro #DS is the meat of the process.
1. T ' gives you the data type, L ' gives you the length of the data and
label-label gives you the offset.
2. Comments were not needed for IPCS, If they are needed, you will need to find
a solution.
3. Signed / unsigned is not defined in the dsect (instructions determine). You
might need macro options allowing you to specify unsigned fields.
4. For me, duplication factor or stacking was not used in any macro's I needed.
Duplication factor (e.g. DS 4A), can be calculated by using the next variable
minus this variable divided by variable length. For stacked data (e.g. DS
A(0,0,0),CL30), you can calculate overall length by using the next variable
minus this variable.
5. For assembler data types that have direct C equivalents (e.g. A, H, F, D),
you would create matching variables with the C equivalent.
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.
7. Probably everything else would be a byte array with the specified length.
Compile a C program that displays the SIZEOF(struct_name) and verify it matches
the assembler calculated size of the dsect.
Jon.
On Wednesday, September 18, 2019, 11:31:42 AM PDT, Steve Smith
<sasd...@gmail.com> wrote:
XLC has a DSECT conversion utility. Check the User's Guide. Many don't
like its output (probably including Peter Relson), but it can be useful,
maybe as a starting point.
sas
On Wed, Sep 18, 2019 at 1:26 PM Farley, Peter x23353 <
peter.far...@broadridge.com> wrote:
> Hmm-m-m. Interesting idea, but I can see complex language-dependent
> variable definition issues. Might be a real bear to implement in the
> compilers in any shared-code-among-languages way.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
