Exactly. HLASM is inconsistent in conflating storage types (F, H, etc.)
and data types (B, X, C), which definitely adds to the confusion. C
(and its derivatives) makes more sense in this regard. OTOH, C does
have the interesting feature that the size of ints (and shorts and
longs) and pointers can vary. PL/I might have the best model, but I
haven't done any serious work with it in many years.
sas
On 2/25/2017 11:42, Charles Mills wrote:
Another way of looking at things is that X' serves two different roles in the
assembler syntax. I became aware of this when I moved from a long career
writing assembler to C++ as my primary language.
X' signifies (a.) that the constant that follows is in hexadecimal notation and
(b.) a unit of storage, a byte.
Thus you can say LHI 0,X'23' (role a.) or DC X'23' (roles a. and b.). Consider
the contrast with H' which is only a unit of storage. You can say DC H'23' but
you would not expect to be able to code LHI 0,H'23'. So, similarly, you can
code DC 2X'23' but not LHI 0,2X'23'
FWIW and OT, C/C++ separates the two functions. 0x23 represents only the
quantity 23 base 16, not a unit of storage. You can say foo = 0x23 (roughly
analogous to LHI) but if you want to define storage, you must explicitly state
the unit of storage that you are defining: char foo = 0x23 or short foo = 0x23
(roughly equivalent to FOO DC X'23' and FOO DC H'35' respectively).
Charles
