dave@visual2.jhuapl.edu (Dave Weintraub) (03/09/91)
At SHARE 76 (last week), the Assembler H Committee of the Languages Project (of which I am Project Manager) completed review of a survey to be sent to all SHARE membership sites. This survey is being produced at the suggestion of IBM, to prove the "business case" for IBM to "open up" Assembler H, add the SLAC mods and other long overdue enhancements, and perhaps improve the Assemble debugging environment (specifically under MVS). In August of 89, we met with IBM Language Product management, to discuss the refusal of IBM to incorporate the SLAC mods into the Assembler H Program Product. These mods increase diagnostic reporting and programming flexibility, often free-up registers unnecessarily tied up for USINGs to map DSECTS imbedded in other DSECTs, and increase assembler speed and efficiency. IBM agreed that all of this would be nice, but stated that the general trend was toward decreasing Assembler development, and that there was no real case for what amounts to a major modification of Assembler H. We agreed to conduct a representative survey, to determine the need (or lack there of) for a modern Assembler product. IBM was not convinced by two side arguments: 1 The SLAC mods (specifically, flagging overlapping USINGs) allow detection of bugs in existing code (eg, there were bugs found in JES2 and JES3 simply by re-assembling these). 2 The SLAC mods allow Assembler H to run more efficiently; since PLS compiles into Assembler H, IBM would save their own machine cycles by incorporating the mods. SHARE and IBM agreed that the Assembler H Committee would help to determine the usage level of Assembler among SHARE sites, and submit a suite of (about 4 dozen) SHARE requirements for improving the product. John Ehrman suggested that, if IBM were going to modify the Assembler, this would be an "all-or-nothing" deal, so we added requirements to support all labels and such in an integrated TEST environment, replacing TSO test, perhaps extending the INSPECT product to support Assembler H code as well as C and PL/I. All suggestions, comments, and volunteers to review the SHARE requirements we are writing (or to word some of the as-of-yet-unwritten ones) are welcome!
news@ucf1vm.BITNET (03/09/91)
At SHARE 76 (last week), the Assembler H Committee of the
Languages Project (of which I am Project Manager) completed
review of a survey to be sent to all SHARE membership sites.
This survey is being produced at the suggestion of IBM,
to prove the "business case" for IBM to "open up" Assembler H,
add the SLAC mods and other long overdue enhancements,
and perhaps improve the Assemble debugging environment
(specifically under MVS).
In August of 89, we met with IBM Language Product management,
to discuss the refusal of IBM to incorporate the SLAC mods
into the Assembler H Program Product. These mods increase
diagnostic reporting and programming flexibility,
often free-up registers unnecessarily tied up for USINGs
to map DSECTS imbedded in other DSECTs, and increase
assembler speed and efficiency. IBM agreed that all of this
would be nice, but stated that the general trend was toward
decreasing Assembler development, and that there was no real case
for what amounts to a major modification of Assembler H.
We agreed to conduct a representative survey, to determine
the need (or lack there of) for a modern Assembler product.
IBM was not convinced by two side arguments:
1 The SLAC mods (specifically, flagging overlapping USINGs)
allow detection of bugs in existing code (eg, there were
bugs found in JES2 and JES3 simply by re-assembling these).
2 The SLAC mods allow Assembler H to run more efficiently;
since PLS compiles into Assembler H, IBM would save their own
machine cycles by incorporating the mods.
SHARE and IBM agreed that the Assembler H Committee would help
to determine the usage level of Assembler among SHARE sites,
and submit a suite of (about 4 dozen) SHARE requirements
for improving the product.
John Ehrman suggested that, if IBM were going to modify the Assembler,
this would be an "all-or-nothing" deal, so we added requirements
to support all labels and such in an integrated TEST environment,
replacing TSO test, perhaps extending the INSPECT product to
support Assembler H code as well as C and PL/I.
All suggestions, comments, and volunteers to review the SHARE requirements
we are writing (or to word some of the as-of-yet-unwritten ones)
are welcome!CDRNI@CUNYVM.BITNET ("George N. Reeke Jr.") (03/11/91)
This is a reply to the person, who did not identify him/herself, who
requested suggestions on this list for requirements for Assembler H
updates.
Please ignore if this feature is already in Assembler H, as I am
mostly stuck with Assembler F, but the suggestion applies to
any S/370 Assembler.
The suggestion refers to the "scaling" (S') and "integer" (I')
attributes, which are (in my experience) restricted to use
only in macro instructions and not in open code, and are
further restricted to apply only to DC constants (not DS
variables).
I have wished for many years, as would anyone who uses
fixed point arithmetic, that these restrictions would
be removed. I can think of no incompatibility with the
rest of the language that would occur if they were.
The point is to be able to refer to the scale of a fixed-
point variable when coding arithmetic instructions in open
code so that the scale of a variable can be changed without
recoding all the arithmetic that operates on it. A nonsense
example of what is desired follows:
L RX,X
SLA RX,S'Y-S'X
A RX,Y
...
X DS FS4
Y DS FS8
...
I would be very grateful if the appropriate parties could pass
this on to the SHARE people for consideration.
Thanks, George Reeke
Rockefeller Universitydandrews@bilver.uucp (Dave Andrews) (03/14/91)
In article <9103110028.AA24890@ucbvax.Berkeley.EDU> IBM 370 Assembly Programming Discussion List <ASM370@OHSTVMA.BITNET> writes: >This is a reply to the person, who did not identify him/herself, who >requested suggestions on this list for requirements for Assembler H >updates. I'm David Andrews, the nominal chairman of the requirements committee that Dave Weintraub referred to earlier. I'll take your requirements. You can find me at tarpit!bilver!dandrews -or- 407-365-2153 (fax: 2148)
dandrews@bilver.UUCP (Dave Andrews) (03/14/91)
In article <9103110028.AA24890@ucbvax.Berkeley.EDU> IBM 370 Assembly Programming Discussion List <ASM370@OHSTVMA.BITNET> writes: >This is a reply to the person, who did not identify him/herself, who >requested suggestions on this list for requirements for Assembler H >updates. I'm David Andrews, the nominal chairman of the requirements committee that Dave Weintraub referred to earlier. I'll take your requirements. You can find me at tarpit!bilver!dandrews -or- 407-365-2153 (fax: 2148)