Re: Base registers
On Mon, Jun 4, 2012 at 2:45 AM, robin robi...@dodo.com.au wrote: There's no need to be scared of an odd value. It is, after all, the assembler that calculates displacements. If it bothers you, make it 4092. Still no extra instruction needed. Since most of the time you just new a few more bytes anyway ;-)
Re: Base registers
On 6/3/2012 8:52 AM, John Gilmore wrote: Gerhard's point is not so easily dismissed; but 1) it is self-defeating for the technology if pushed very far: it freezes software in a posture that is now more than fifteen years behind the state of the art; and 2) the market for even moderately-priced software among MVT-using hobbyists is very small. Still, seriously pursued dual-path software is is certainly viable. Supporting obsolete systems is a labor of love; I see no reason to impute financial objectives to their support. For example, Dave Cole has offered the MVS version of XDC for free, except no copy of this version of it has been found. As a now certified élitist, I am nevertheless unrepentent. Urgings about compatibility requirements and the like usually hide Luddite impulses, reluctance to accommodate the (not very) new, which account for a good many of the troubles that the mainframe community is experiencing. If I were responsible for a Fortune 500 company, I would be leery of making changes solely to avoid consideration as a Luddite. And for a mission critical business application, I certainly would prefer a machine optimized compiler over assembler (programmers should provide global optimization). My approach is pragmatic - use the appropriate tools best suited for the task at hand. If that means consciously deciding on old code reuse rather than new development, that may prove faster and cheaper in the long run. But I agree that old code should not be used simply because a programmer is not up to speed on new features. Gerhard Postpischil Bradford, VT
Re: Base registers
Odd (or nonconsecutive) Base registers Please- If there is ever a need to calculate a ZAP to this code with crossing the boundary between two registers- it will cause major headaches- The PLS compiler does it- but this is not an argument to do it. -- Martin Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE more at http://www.picapcpu.de
Re: Base registers
... said enough, maybe too much, about this topic Since the thread is still not dead- here is my point: Use of relative immediate feature is the way to go. The time it takes to convert a module from Bxx type to Jxxx is neglectable in comparison to finding an unused register (or restructuring to get one). The major roadblock is codealterations (switches in code) = not reentrant. Which I assume is not the case for a IRREVX01 exit (shudder: and sold as a part of a product). And to those refusing to use new techniques. How old has a feature to be to be usable for code? This is more than 17 years old (*). I have yet to find that VSE-customer that pays for Vendor-software and has no money for hardware or operating-system-software AND demands new features. (*) I have been bitten by a DR machine that did not have the feature some 17 years ago- it might be around longer. -- Martin Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE more at http://www.picapcpu.de
Re: Base registers
From: Rob van der Heij Sent: Monday, 4 June 2012 4:41 PM Since most of the time you just new a few more bytes anyway ;-) ?? Doesn't make sense.
Re: Base registers
From: Rob van der Heij Sent: Monday, 4 June 2012 4:41 PM On Mon, Jun 4, 2012 at 2:45 AM, robin robi...@dodo.com.au wrote: There's no need to be scared of an odd value. It is, after all, the assembler that calculates displacements. If it bothers you, make it 4092. Still no extra instruction needed. Since most of the time you just new a few more bytes anyway ;-) Even with the nonsense word changed a la Martin, your response still doesn't make sense.
Re: Base registers
On Mon, Jun 4, 2012 at 12:20 PM, robin robi...@dodo.com.au wrote: Even with the nonsense word changed a la Martin, your response still doesn't make sense. Sorry, as Martin noticed my head and fingers had disconnected... Typically I find the module just slightly extend the 4K after a small change... 4092 or 4094 is a lot compared to what you need at that moment. But for future debugging it is much more obvious when the two base registers are really 4K apart. Seems to me that saving that single instruction is not worth the trouble. Rob
Re: Base registers
I have yet to find that VSE-customer that pays for Vendor-software and has no money for hardware or operating-system-software AND demands new features. We have several that meet this requirement. Think about the VSE 2.6 on P390 ESL boxes. Tony Thigpen -Original Message - From: Martin Trübner Sent: 06/04/2012 03:27 AM ... said enough, maybe too much, about this topic Since the thread is still not dead- here is my point: Use of relative immediate feature is the way to go. The time it takes to convert a module from Bxx type to Jxxx is neglectable in comparison to finding an unused register (or restructuring to get one). The major roadblock is codealterations (switches in code) = not reentrant. Which I assume is not the case for a IRREVX01 exit (shudder: and sold as a part of a product). And to those refusing to use new techniques. How old has a feature to be to be usable for code? This is more than 17 years old (*). I have yet to find that VSE-customer that pays for Vendor-software and has no money for hardware or operating-system-software AND demands new features. (*) I have been bitten by a DR machine that did not have the feature some 17 years ago- it might be around longer. -- Martin Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE more at http://www.picapcpu.de
Re: Base registers
I think it may have been an parody of a joke: Question: How much money is enough? Answer: Just a little bit more. In assembler, it is how many bytes do you need to be resolvable to a valid offset? just a few more. It's why I (as a customer only), love doing baseless programming. I separate the code and data sections, using a base register only for the data section. I load the base register using an LAY (if contained in the same CSECT). I now also use pure coding techniques. In this case pure means that I never store into the CSECT itself. Actually, I use an RSECT. This is a requirement for writing DLLs in HLASM. Which I have successfully done (beause I can). -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of robin Sent: Monday, June 04, 2012 5:20 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base registers From: Rob van der Heij Sent: Monday, 4 June 2012 4:41 PM On Mon, Jun 4, 2012 at 2:45 AM, robin robi...@dodo.com.au wrote: There's no need to be scared of an odd value. It is, after all, the assembler that calculates displacements. If it bothers you, make it 4092. Still no extra instruction needed. Since most of the time you just new a few more bytes anyway ;-) Even with the nonsense word changed a la Martin, your response still doesn't make sense.
Re: Base registers
Tony, I have yet to find that VSE-customer that pays for Vendor-software and has no money for hardware or operating-system-software AND demands new features. We have several that meet this requirement. Think about the VSE 2.6 on P390 ESL boxes. I can imagine customers running that- but asking for new features? This is like asking for an aircondition in a Ford T. -- Martin Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE more at http://www.picapcpu.de
Re: Base registers
Martin, As the say options are like ...everyone had one...your entitled to yours Scott ford www.identityforge.com On Jun 4, 2012, at 8:27 AM, Martin Truebner mar...@pi-sysprog.de wrote: Tony, I have yet to find that VSE-customer that pays for Vendor-software and has no money for hardware or operating-system-software AND demands new features. We have several that meet this requirement. Think about the VSE 2.6 on P390 ESL boxes. I can imagine customers running that- but asking for new features? This is like asking for an aircondition in a Ford T. -- Martin Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE more at http://www.picapcpu.de
Re: Base registers
That was a typo, opinionsour customers usually dictate needs many times Scott ford www.identityforge.com On Jun 4, 2012, at 9:00 AM, Scott Ford scott_j_f...@yahoo.com wrote: Martin, As the say options are like ...everyone had one...your entitled to yours Scott ford www.identityforge.com On Jun 4, 2012, at 8:27 AM, Martin Truebner mar...@pi-sysprog.de wrote: Tony, I have yet to find that VSE-customer that pays for Vendor-software and has no money for hardware or operating-system-software AND demands new features. We have several that meet this requirement. Think about the VSE 2.6 on P390 ESL boxes. I can imagine customers running that- but asking for new features? This is like asking for an aircondition in a Ford T. -- Martin Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE more at http://www.picapcpu.de
Re: Base registers
Thanks Gerhard, I feel the same way, especially when you work for a small company and your the only one writing Assembler, with customers asking for changes Scott ford www.identityforge.com On Jun 4, 2012, at 2:49 AM, Gerhard Postpischil gerh...@valley.net wrote: On 6/3/2012 8:52 AM, John Gilmore wrote: Gerhard's point is not so easily dismissed; but 1) it is self-defeating for the technology if pushed very far: it freezes software in a posture that is now more than fifteen years behind the state of the art; and 2) the market for even moderately-priced software among MVT-using hobbyists is very small. Still, seriously pursued dual-path software is is certainly viable. Supporting obsolete systems is a labor of love; I see no reason to impute financial objectives to their support. For example, Dave Cole has offered the MVS version of XDC for free, except no copy of this version of it has been found. As a now certified élitist, I am nevertheless unrepentent. Urgings about compatibility requirements and the like usually hide Luddite impulses, reluctance to accommodate the (not very) new, which account for a good many of the troubles that the mainframe community is experiencing. If I were responsible for a Fortune 500 company, I would be leery of making changes solely to avoid consideration as a Luddite. And for a mission critical business application, I certainly would prefer a machine optimized compiler over assembler (programmers should provide global optimization). My approach is pragmatic - use the appropriate tools best suited for the task at hand. If that means consciously deciding on old code reuse rather than new development, that may prove faster and cheaper in the long run. But I agree that old code should not be used simply because a programmer is not up to speed on new features. Gerhard Postpischil Bradford, VT
Re: Base registers
I have seen many old IBM modules (in dumps, microfiche, etc.) in which the first few instructions are something like this: MODULE USING *,R15 LRR12,R15 LA R11,4095(,R12) DROP R15 USING MODULE,R12 USING MODULE+4095,R11 This allows 8,191 bytes of local addressability to be established with only two instructions for a total length of 6 bytes of executable code. This kind of code was state of the art long ago when each additional byte of storage was vastly more expensive than that same additional byte is today. Back in those days there was no real storage or virtual storage, just storage, and modules had to be as small as possible. And many modules written way back then are still alive and well inside z/whatever-its-latest-name-is. Yes, the odd offsets look weird, but the weird look does not prevent the DAT's ability to add the base register's contents to the displacement and generate the correct address. When one is writing new code, one is free to be elitist and exploit the latest and greatest instructions that are available on the processors on which the code is expected to run. When one is working with old code, or even new code written by Luddites, denigrating the technology used does not really help in understanding what the module is doing. Bill Fairchild Programmer Rocket Software 408 Chamberlain Park Lane * Franklin, TN 37069-2526 * USA t: +1.617.614.4503 * e: bfairch...@rocketsoftware.com * w: www.rocketsoftware.com -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of robin Sent: Sunday, June 03, 2012 7:45 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base registers From: Chuck Arney Sent: Sunday, 3 June 2012 6:53 AM I don't think you really want your base register pointing to an odd address. You need to add 1 more to make it right and that requires another instruction. There's no need to be scared of an odd value. It is, after all, the assembler that calculates displacements.
Re: Base registers
Bill, Amen, I first wrong BAL on a 360/20, didn't have the 1401 exposure ..man half words were real important Scott ford www.identityforge.com On Jun 4, 2012, at 11:15 AM, Bill Fairchild bfairch...@rocketsoftware.com wrote: I have seen many old IBM modules (in dumps, microfiche, etc.) in which the first few instructions are something like this: MODULE USING *,R15 LRR12,R15 LA R11,4095(,R12) DROP R15 USING MODULE,R12 USING MODULE+4095,R11 This allows 8,191 bytes of local addressability to be established with only two instructions for a total length of 6 bytes of executable code. This kind of code was state of the art long ago when each additional byte of storage was vastly more expensive than that same additional byte is today. Back in those days there was no real storage or virtual storage, just storage, and modules had to be as small as possible. And many modules written way back then are still alive and well inside z/whatever-its-latest-name-is. Yes, the odd offsets look weird, but the weird look does not prevent the DAT's ability to add the base register's contents to the displacement and generate the correct address. When one is writing new code, one is free to be elitist and exploit the latest and greatest instructions that are available on the processors on which the code is expected to run. When one is working with old code, or even new code written by Luddites, denigrating the technology used does not really help in understanding what the module is doing. Bill Fairchild Programmer Rocket Software 408 Chamberlain Park Lane * Franklin, TN 37069-2526 * USA t: +1.617.614.4503 * e: bfairch...@rocketsoftware.com * w: www.rocketsoftware.com -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of robin Sent: Sunday, June 03, 2012 7:45 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base registers From: Chuck Arney Sent: Sunday, 3 June 2012 6:53 AM I don't think you really want your base register pointing to an odd address. You need to add 1 more to make it right and that requires another instruction. There's no need to be scared of an odd value. It is, after all, the assembler that calculates displacements.
Re: Base registers
The code we use here at my job usually has very large modules and used several base registers. I have seen the following technique used: MYCSECT CSECT USING *,R15 B BYID ID DCC'module-name' BASESDCA(MYCSECT) DCA(MYCSECT+4096) DCA(MYCSECT+2*4096) DCA(MYCSECT+3*4096) BYID DS0H LMR9,R12,BASES DROP R15 USING MYCSECT,R9,R10,R11,R12 One CPU instruction to load all base registers. I don't really like dealing with such large programs but I can't do anything about it so I'll support it the way it it. John
anti 4095 base guys
i guess you guys would never set the base to he last byte of the program or dsect; having all negative displacements.
Re: anti 4095 base guys
No such thing as a negative displacement. A displacement is more like an unsigned immediate operand. From 0..4095 (0x000 to 0xFFF for a 12 bit displacement) or 0..1048575 (0x0 to 0xF for a 20 bit long displacement). -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Jan Ott Sent: Monday, June 04, 2012 2:14 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: anti 4095 base guys i guess you guys would never set the base to he last byte of the program or dsect; having all negative displacements.
Re: anti 4095 base guys
The displacement for A is treated as a 12-bit *unsigned* binary integer. The displacement for AY, AG, AGF, AGSI and ASI, is treated as a 20-bit *signed* binary integer. I contributed the asterisks. The rest is from the POps. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 On 2012-06-04 15:20, McKown, John wrote: No such thing as a negative displacement. A displacement is more like an unsigned immediate operand. From 0..4095 (0x000 to 0xFFF for a 12 bit displacement) or 0..1048575 (0x0 to 0xF for a 20 bit long displacement). -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Jan Ott Sent: Monday, June 04, 2012 2:14 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: anti 4095 base guys i guess you guys would never set the base to he last byte of the program or dsect; having all negative displacements.
Re: anti 4095 base guys
OOPS. Thanks for the correction! So you could use the 20 bit offset in a negative direction from the end of the module. Personally, I don't think that I'll try that! And I generally use baseless coding for things in the CSECT, anyway. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Gord Tomlin Sent: Monday, June 04, 2012 2:36 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: anti 4095 base guys The displacement for A is treated as a 12-bit *unsigned* binary integer. The displacement for AY, AG, AGF, AGSI and ASI, is treated as a 20-bit *signed* binary integer. I contributed the asterisks. The rest is from the POps. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 On 2012-06-04 15:20, McKown, John wrote: No such thing as a negative displacement. A displacement is more like an unsigned immediate operand. From 0..4095 (0x000 to 0xFFF for a 12 bit displacement) or 0..1048575 (0x0 to 0xF for a 20 bit long displacement). -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Jan Ott Sent: Monday, June 04, 2012 2:14 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: anti 4095 base guys i guess you guys would never set the base to he last byte of the program or dsect; having all negative displacements.
Re: anti 4095 base guys
On Mon, 4 Jun 2012 14:20:09 -0500 McKown, John john.mck...@healthmarkets.com wrote: :No such thing as a negative displacement. A displacement is more like an unsigned immediate operand. From 0..4095 (0x000 to 0xFFF for a 12 bit displacement) or 0..1048575 (0x0 to 0xF for a 20 bit long displacement). You may wish to look up the **Y instructions. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies.
Re: anti 4095 base guys
John McKown writes: begin extract No such thing as a negative displacement. A displacement is more like an unsigned immediate operand. From 0..4095 (0x000 to 0xFFF for a 12 bit displacement) or 0..1048575 (0x0 to 0xF for a 20 bit long displacement) /end extract This is is correct only for traditional System/360 instructions. As one of many counter-examples consider the GRASL instruction, about which the PrOp says: begin extract The contents of the I[2] field are a signed binary integer specifying the number of halfwords that is (sic) added to the address of the instruction to generate the branch address. /end extract In general the 12- and 20-bit displacements in the new instructions are signed. Le bon Dieu est dans le détail. --Gustave Flaubert John Gilmore, Ashland, MA 01721 - USA
more than one base register
Someone wrote: MYCSECT CSECT USING *,R15 B BYID ID DCC'module-name' BASESDCA(MYCSECT) DCA(MYCSECT+4096) DCA(MYCSECT+2*4096) DCA(MYCSECT+3*4096) BYID DS0H LMR9,R12,BASES DROP R15 USING MYCSECT,R9,R10,R11,R12 This looks more like compiler generated code than what I would expect from a person. Then again, my start on learning assembler was reading the LIST output from the compilers. When I saw the 4095 in the subject, I was expecting the old: L 12,4095(15) L 11,4095(12) L 10,4095(11) USING MYCSECT,15 USING MYCSECT+4095,12 USING MYCSECT+2*4095,11 USING MYCSECT+3*4095,10 The LM form seems to waste fewer bytes loading the base registers (including the A constants), especially if one already has the branch around the csect name. But, why the DS 0H instead of putting the label on the LM? -- glen
Re: more than one base register
snip But, why the DS 0H instead of putting the label on the LM? -- glen I do the same thing for labels to code. Why? Hum, I guess from reading the HASP code long ago. Also, it makes it easier to insert a new instruction at that logical point in the program without remembering to remove the label from the old instruction and move it to the new one. In addition, if you use SUPERC to compare the two sources (before after), then the old instruction does not show up an a delete and add. Only the new instruction shows up as an add. Remember the days of IEBUPDTE to update source. Fewer updated cards means fewer mistakes. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
Opinions? Syntax enhancement to numeric literals.
I don't see where this is possible in HLASM. But some languages all a _ character in numeric literals, and simply ignoring it. Often used in decimal literals to separate thousands, and in binary literals to separate into nybbles (4 bits). It is much easier to recognize 16_777_216 than 16777216. And know that B'0110_1001' is exactly one byte in length. Does anybody else think this might be useful? Given that it would be a simple change, I am wondering if I might be able to figure out how to make a change to FLOWASM to do this for me. John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
DS 0H
(snip, I wrote) But, why the DS 0H instead of putting the label on the LM? I do the same thing for labels to code. Why? Hum, I guess from reading the HASP code long ago. Also, it makes it easier to insert a new instruction at that logical point in the program without remembering to remove the label from the old instruction and move it to the new one. That I don't disagree with, but what is the probability of wanted to add new code between the B and the LM? I suppose one still has over 4000 bytes of code (not counting data references) before one needs the next base register, but, really, what else would you want to do there? Now that I write that, where is the STM 14,12,12(13)? Still, that isn't the kind of change I would plan ahead for. At the time, I was considering differences between compiler generated and human generated code. I suppose that one isn't a very good test, though. In addition, if you use SUPERC to compare the two sources (before after), then the old instruction does not show up an a delete and add. Only the new inst ruction shows up as an add. Remember the days of IEBUPDTE to update source. Fewer updated cards means fewer mistakes. Oh, yes, in the general case I agree. It just seemed unneeded in this specific case. -- glen
Re: Opinions? Syntax enhancement to numeric literals.
On Jun 4, 2012, at 15:31, John Ehrman wrote: Blank separators were introduced for quite-delimited numeric constants in HLASM R3. IOW they're permitted in DC, but not in EQU where they're not quite delimited. Sigh. -- gil
Re: Opinions? Syntax enhancement to numeric literals.
From: John Gilmore To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Sent: Tuesday, 5 June 2012 7:37 AM As an optional usage in coded-arithmetic and hexadecimal constants, where it is unambiguous, this is an excellent idea. It has been available in PL/I for a long time, where I may write Declare Fmax value(2_147_483_6747) signed binary fixed(31,0) ; or Declare Fmax signed binary fixed(31,0) static initial(2147483647) ; Declare Fmax initial(0111_______b) static binary fixed(31,0) ; as may be contextually convenient. I have found it useful there. It reduces the frequency of trivial errors, improves readability, and in in general labor-saving. There's always the exception that proves the rule, no? Declare Fmax value(2_147_483_6747) signed binary fixed(31,0) ;
Re: Opinions? Syntax enhancement to numeric literals.
I have taxed other people with not having mastered details, but I must admit that I did not know that | DCF'2 147 483 647' was licit. In the interests of coherence, it should be possible to write | DCF'2_147_483_647' if it is possible to write |FMAX EQU 2_147_483_647 John Gilmore, Ashland, MA 01721 - USA
