By "HLASM is not really typed" I mean that subject only to alignment L 0,FOO assembles without complaint whether FOO is a character, a halfword, a word, or a doubleword, and therefore it is hard for software to make guesses about the usage of FOO based on its declaration.
Yes, assembler has types. A macro that cares can tell the difference among FOO DS C, FOO DS A, and FOO DS F -- but few macros and fewer instructions care. The closest that HLASM comes to real typing is when you declare a register to be an AR or a GPR or whatever, and the assembler balks if you use it incorrectly. Charles -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Steve Thompson Sent: Wednesday, July 18, 2018 12:54 PM To: [email protected] Subject: Re: New Metal C standalone product for z/OS * 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 >
