On 13 Nov 2006 06:48:39 -0800, in bit.listserv.ibm-main you wrote: >-----Original Message----- >From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On >Behalf Of Clark Morris >Sent: Friday, November 10, 2006 4:47 PM >To: IBM-MAIN@BAMA.UA.EDU >Subject: Re: Assembler question > >On 7 Nov 2006 10:34:33 -0800, in bit.listserv.ibm-main you wrote: ><snip> > >Back in the 1980's or early 1990's, with the help of John Ehrman I >submitted a number of requirements at SHARE, on of which was for >optional flagging of all operand mismatches including length matches, >LH of a fullword, etc. Even though they were all rejected at the >time, many of them later made it into what became HLASM. Maybe it is >my COBOL background but the idea that the operation and the data >definition should match in most cases is one that the assembler should >encourage. In regard to another thread, the awkwardness of coding >reentrant code and the mediocre support for it means that for main >programs, I don't bother. I do for exits and subroutines. ><snip> > >I think what you are (or were) suggesting is strong typing for ALC (OK, >I can hear it coming now, that's why we always did it in UPPER CASE and >the like) and enforcement thereof. However, some of us have written code >that makes use of nuances that would cease to (1) assemble correctly, >and more importantly (2) not execute correctly. These nuances are not >wrong or illegal, but made use of generation capability of the assembler >and/or documented "side effects" of instructions. > >As an example, the idea of a LH against a fullword may be done because >in some case it is known that only the high order nibbles of a fullword >are valid for certain operations (logical or arithmetic). While you and >I might say that this should have been done with ICM, or the fullword >should have a secondary definition (using ORG perhaps), the code works >correctly using LH (perhaps it even required the high-order bit >propagation for negativity).
This is why I made the flagging optional based on a PARM. While some may have taken advantage of the nuances, I believe that making sure the operation and the data description match. The lack of IBM supplied macros that would automatically take into account the data description is in my opinion one of the shortcomings of the way IBM has provided Assembler. > >If you were to add strong typing to the assembler with enforcement of >typing, then that code will not assemble, or the assembler will presume >that a Load was meant -- look-out! > >We could continue this with various instructions. And yes, I've made the >rookie error of L instead of LA (and vice versa), MVC instead of MVI, >etc. But you learn and you think in ALC -- COBOL code that I have >written at times looked like someone trying to strangle the compiler to >get what they wanted. > >But as I said in a prior posting, ALC is a low level language. So >perhaps those of us that have programmed in it for years just think >quite differently (I started on S/360 machines). Don't get me wrong, I >am not interested in GATE/TEST coding -- Macrocode at Amdahl was close >enough to the bare metal. It may be low level, but does it also have to be brain-dead? > >Later, >Steve Thompson > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
