* TYPEing
&LABEL DC 0F,A(BUFF_LEN+7) Get The Charles Constant...
The type of the LABEL is "F" not "A" and you got what you needed.
yes?
This is typically done for certain "ASSIST" type macros that I've
used in the past where they check what the label is (IF, DO,
DOWHILE, SELECT, etc.).
Meanwhile, I'm thinking a bit about c and learning it. I still
remember that c's pointers are about as obtuse as they get... But
I'm told once you get past that, c becomes easy.... :)
Regards,
Steve Thompson
On 07/18/2018 01:42 PM, Charles Mills wrote:
It *does* get alignment right. CDSECT's output does not depend on "inherent"
C alignment. Char[8] and uint64_t both end up in the same place. It
constructs the struct using the SYSADATA offsets. It inserts its own padding
where necessary. It emits #pragma pack(packed).
Going from structs to DSECTs would make a lot of sense except that there is
no C equivalent of SYSADATA, so the utility would have to have its own
built-in (partial) C compiler. Going from PL/X to DSECTs (or C headers!)
makes a lot of (technical) sense.
I fail to see how &ptr32 is any clearer than A, unless you happen to be
coming from a C-only background. Neither one is clear if you don't know what
it means. A means "32-bit pointer."
Generally. Of course HLASM is all but untyped. A might mean an integer
constant, especially since A supports expressions while F somewhat
inexplicably does not. You can code A(BUFF_LEN+7) but not F'BUFF_LEN+7'.
Charles
-----Original Message-----
From: IBM Mainframe Assembler List [mailto:[email protected]]
On Behalf Of Paul Gilmartin
Sent: Wednesday, July 18, 2018 10:10 AM
To: [email protected]
Subject: Re: New Metal C standalone product for z/OS
On 2018-07-17, at 18:04:14, Charles Mills wrote:
One annoying thing also is that it is non-trivial to use a text editor to
find and convert all
char foo[8];
to
uint64_t foo;
It would be easier if the c syntax were char[8] foo; then getting to
uint64_t foo; would be trivial.
It seems the designers were fixated on making declarators look
like member references.
-----Original Message-----
From: Charles Mills
Sent: Tuesday, July 17, 2018 4:57 PM
Well, the problem of course is that assembler is not strongly typed. You
can code
BUFFADDR DS CL4 (or even 4C) and it works just fine for assembler, but
what is poor CDSECT supposed to do.
Last I knew, it did all FD and AD as char[8] which IMHO is pretty d@mned
stupid. But it is syntactically valid and the storage layout is correct.
Subject to bouldary alignment.
A more useful design would code the data area descriptions initially
as C structs and supply an ASTRUCT utility to convert to DSECTS.
I believe I'd name it DESTRUCT.
Or, an assembler programmer with foresight could have employed SETC
symbols such as:
&__ptr32 SETC A
POINTER DC &__ptr32(symbol)
...
Providing some guidance for a CDSECT utility and clarity for the
reader of the source. (IMO, "&__ptr32" conveys better information
than "A". I'm not advocating Hungarian Notation.)
(This solves nothing for legacy source code.)
-- gil
