Re: What does the 'end' address on a USING statement mean?
Ref: Your note of Thu, 6 Nov 2014 18:41:34 -0500 Tony H wrote: On 6 November 2014 17:20, Jonathan Scott jonathan_sc...@vnet.ibm.com wrote: When all else is equal a new dependent USING for a given location should supersede any older one for the same location and base USING. 1) This is not the way non-dependent USINGs work. There can be multiple right-parts (registers, =bases, in some sense) with at worst a warning. Why should this be different? There are existing rules about priority of USING which have to remain unchanged. That's why I said when all else is equal. Also, when I say same location I'm talking about alternative active USING statements which could be used to resolve the same name. 2) Having multiple overlapping dependent USINGs can be useful. For example: xCBAREA DS XL... ... USING IHADCB,xCBAREA USING IFGACB,xCBAREA ... MVC DCBDDNAM,some_ddname Works for DCB or ACB ... TMDCBOFLGS,DCBOPEN Works for DCB or ACB ... TMACBDSOR2,ACBDORGAIs this an ACB? JOHandle_ACB Go do ACB-only stuff ... DROP ??? I'm not claiming this is the right technique -- clearly there are other ways of doing it -- but it's a use case. Tony H. That's fine. The only case which might need a new rule is when the same name can be resolved using multiple USING statement and other USING priority rules (for example about smallest displacement or base register numbers) are not sufficient to make a definite choice. It is obviously necessary to ensure that any case which is already supported by HLASM should continue to be processed in exactly the same way for complete compatibility. Jonathan Scott IBM Hursley, UK
Re: What does the 'end' address on a USING statement mean?
On 2014-11-07, at 02:15, Jonathan Scott wrote: It is obviously necessary to ensure that any case which is already supported by HLASM should continue to be processed in exactly the same way for complete compatibility. I disagree. I believe that one case in which HLASM produces an algebraically incorrect base-displacement resolution (but perhaps this should be considered not support but defect) should result in could not be resolved. -- gil
Re: What does the 'end' address on a USING statement mean?
Ref: Your note of Fri, 7 Nov 2014 06:12:17 -0700 On 2014-11-07, at 02:15, Jonathan Scott wrote: It is obviously necessary to ensure that any case which is already supported by HLASM should continue to be processed in exactly the same way for complete compatibility. I disagree. I believe that one case in which HLASM produces an algebraically incorrect base-displacement resolution (but perhaps this should be considered not support but defect) should result in could not be resolved. -- gil If a product does something which is not consistent with its own documentation, then that's clearly not supported. The solution in such cases depends on consideration of the potential impact of any change, and may involve either changing the code or the documentation (or a bit of both). Although there are well known defects in the area of overflow or wrap relating to HLASM address calculations, I don't recall ever hearing of any customer problem report being submitted for this. In this particular case, it's a bit tricky anyway. HLASM fails to detect overflow and wrap in certain cases, but as always there are cases where intermediate results could wrap but the final result could be correct. As the addressability calculations are implicit, the user does not have direct control over the expression evaluation. Perhaps a workable general rule would be to make it work as if HLASM did addressability calculations using longer arithmetic then only checked for overflow when mapping the final result back to 31-bit signed. Jonathan Scott IBM Hursley, UK
Re: What does the 'end' address on a USING statement mean?
At 09:42 -0700 on 11/05/2014, Paul Gilmartin wrote about Re: What does the 'end' address on a USING statement mean?: On 2014-11-05, at 03:07, Sharuff Morsa3 wrote: USING ought to be as helpful as possible. HLASM - like other products can be driven by user requests. The more requests/votes we have - the higher up the list the requirement goes. If the community feels this change is important/useful/desirable then please raise a requirement and vote for it. It will certainly get my vote. see http://www.ibm.com/support/docview.wss?uid=swg21577670 That RFE or a similar one should also request support for a lower bound on the range since HLASM now supports negative displacements. I can see a use for both the start and end in a USING to be useful. Note that there can be an issue if the low end is before the start of the CSECT or the High end being past the end of the CSECT. If the assembly is a multi-CSECT one what happens if the high end of a Long Displacement points into the next CSECT (which then moved to another displacement from the first by the Binder). This would cause the instruction to point to the wrong place in the Program Object. The assembler can only enforce the low and high limits of the USING if they are in the same CSECT or DSECT. It would also need to toss an error if the LONG instruction attempts to address outside the USING range. Date:Tue, 4 Nov 2014 08:41:10 -0700 From:Paul Gilmartin paulgboul...@aim.com Subject: Re: What does the 'end' address on a USING statement mean? It seems to me to be even more important to enforce END with long displacements because in many cases base register combinations which produce unique resolutions with 12-bit displacements may produce ambiguous resolutions with long displacements. Thanks, gil
Re: What does the 'end' address on a USING statement mean?
Ref: Your note of Wed, 5 Nov 2014 23:42:24 -0500 The purpose of an RFE is primarily for IBM to determine requirements and priorities. You do not need to specify the solution in detail, only the overall requirement. HLASM is already aware of three specific requirements in the USING/DROP area, all of which I discussed with John Ehrman some years ago. We came up with suggested solutions too, so if these areas are considered sufficiently high priority in future, there is already a provisional solution defined (although there is of course no guarantee that HLASM will actually do it that way, if at all). 1. Dependent USING support for long displacements For 20-bit displacement support, a dependent USING should be able to be defined anywhere within the 20-bit addressable range of an existing base register. (This was also discussed on the mailing list some time ago). The suggested solution is that if the OPTABLE specifies an instruction set which includes 20-bit displacement support, the base address of a dependent USING will be considered valid if it is addressable using a 20-bit displacement, otherwise it must be addressable using a 12-bit displacement as at present. Obviously, if a dependent USING was accepted as being addressable only using 20-bit support but was then used to resolve a 12-bit addressable reference, this would still give an error as usual, but only on the reference, not on the USING. 2. USING support for long displacement limits USING needs additional support for lower and upper limits for 20-bit displacements. The suggested solution is to extend the first parameter of the USING statement to the following form with two new optional subparameters: USING (base,limit,lower,upper),... The first limit field only applies to 12-bit displacements, for total compatibility with existing code. The base also effectively acts as a lower limit for 12-bit displacements. The new lower and upper limits apply to both 12-bit and 20-bit displacements. For a 12-bit displacement, a location is only addressable if it lies within both sets of limits. Note that the lower limit may be greater than the base, to limit the addressability to an area which does not include the base address. If a location is outside the range limits, this does not directly cause an error, but merely means that it is not addressable via that USING statement, as at present. The above change for USING limits also allows the same base registers to be used to address multiple discontiguous parts of the same section, for example as follows: USING (codebase,,code,code_end),R3,R4,R5 USING (codebase,,static,static_end),codebase USING (codebase,,literals,literals_end),codebase There is a complication that the USING map part of the listing would need enhancement to reflect the new information, and there now seems to be too much information to fit on a single line for each USING, so the layout of that section might need to change somewhat. 3. DROP by address It would be more convenient to DROP a USING statement by reference to a location addressed via that USING statement rather than having to specify a base register or qualifier. For example, one could DROP the name of a DSECT rather than its base registers. The suggested solution is that if an operand to DROP is a relocatable expression rather than a register, it drops the USING statement that would be used to resolve the relevant address. This would also finally provide a method of dropping a dependent USING, which is another subject that was previously mentioned on the mailing list. John Ehrman has previously recorded customer requirements for all three of the above, but I think that only the first of these has also been recorded on the new RFE tool, so if you want to request either of the other enhancements mentioned above someone will need to create a new RFE. Jonathan Scott IBM Hursley, UK
Re: What does the 'end' address on a USING statement mean?
On 2014-11-06, at 04:24, Jonathan Scott wrote: 1. Dependent USING support for long displacements For 20-bit displacement support, a dependent USING should be able to be defined anywhere within the 20-bit addressable range of an existing base register. (This was also discussed on the mailing list some time ago). I would not impose the 20-bit limit. HLASM should immunize itself against potential hardware extensions. And consider: D-Loc Object CodeAddr1 Addr2 Stmt Source Statement 000 0 1 XDSECT 000 4 2 CCSECT R:C 0 3 USING C,R12 C 000 653601 0 4 USING X-9,C 00 4110 C001 653602 5 LAR1,X-8 6 * 7 * But: 8 USING X,C+9 ** ASMA307E No active USING for operand C+9 ** ASMA435I Record 8 in user.DEPUSING.JOB06303.D101.? on volume: Line 4 results in no messages, and the resolution at line 5 is algebraically correct. The programmer's objective is mysterious, but there's no reason to prohibit the behavior. The USING at line 8 is algebraically equivalent to that at line 4, but it it produces an error message. Why? I'd urge that there be no limit on the range at the definition of a USING other than that imposed by the 32-bit signed integer arithmetic uniformly used by HLASM. Discipline might require stronger overflow checking during base-displacement resolution. I can today demonstrate a case where HLASM generates an algebraically incorrect resolution, apparently because it ignores an overflow that occurs during the calculation. 2. USING support for long displacement limits USING needs additional support for lower and upper limits for 20-bit displacements. The suggested solution is to extend the first parameter of the USING statement to the following form with two new optional subparameters: USING (base,limit,lower,upper),... ... The above change for USING limits also allows the same base registers to be used to address multiple discontiguous parts of the same section, ... I question the value of this. It leads to the paradoxical situation that a certain address may be addressable with short displacement but not with long. I suspect that the design motivation is largely to avoid a syntactic anomaly introduct by alternatives such as: USING (base,upper)(Current syntax) But either extension: USING (base,upper,lower) (upper appears before lower) or: USING (base,lower,upper) (upper is 3rd positional parameter rather than second.) 3. DROP by address ... The suggested solution is that if an operand to DROP is a relocatable expression rather than a register, it drops the USING statement that would be used to resolve the relevant address. Are dependent USINGs referring to the same base register allowed to overlap? There should be no objection to this provided that they resolve to identical base and displacement regardless which USING is used. But this introduces an ambiguity in DROP by address when that address can be resolved, albeit equivalently, by either of two dependent USINGs. -- gil
Re: What does the 'end' address on a USING statement mean?
At 11:01 -0700 on 11/06/2014, Paul Gilmartin wrote about Re: What does the 'end' address on a USING statement mean?: Are dependent USINGs referring to the same base register allowed to overlap? There should be no objection to this provided that they resolve to identical base and displacement regardless which USING is used. But this introduces an ambiguity in DROP by address when that address can be resolved, albeit equivalently, by either of two dependent USINGs. How about allowing the use of an label on the Dependent USING and the DROP uses that label? That way you and identify the Dependent USING you are DROPing.
Re: What does the 'end' address on a USING statement mean?
Ref: Your note of Thu, 6 Nov 2014 11:01:48 -0700 Thanks for the comments! Paul Gilmartin wrote: On 2014-11-06, at 04:24, Jonathan Scott wrote: 1. Dependent USING support for long displacements ... I would not impose the 20-bit limit. HLASM should immunize itself against potential hardware extensions. ... If it can assume 20-bit displacements when OPTABLE includes the support, it could assume something different if anything new came along. Keeping the base value within range means that we can at least avoid one potential cause of wrap/overflow problems. 2. USING support for long displacement limits ... USING (base,limit,lower,upper),... ... The above change for USING limits also allows the same base registers to be used to address multiple discontiguous parts of the same section, ... I question the value of this. It leads to the paradoxical situation that a certain address may be addressable with short displacement but not with long. A 12-bit displacement has to satisfy both pairs of limits for the location to be addressable, so this problem cannot occur. The idea is to keep the existing 12-bit limit independent, as it is sometimes used to ensure a safe margin of addressability for future expansion, which could still be useful even when some instructions use 20-bit displacements. 3. DROP by address ... The suggested solution is that if an operand to DROP is a relocatable expression rather than a register, it drops the USING statement that would be used to resolve the relevant address. Are dependent USINGs referring to the same base register allowed to overlap? There should be no objection to this provided that they resolve to identical base and displacement regardless which USING is used. But this introduces an ambiguity in DROP by address when that address can be resolved, albeit equivalently, by either of two dependent USINGs. When all else is equal a new dependent USING for a given location should supersede any older one for the same location and base USING. Jonathan Scott IBM Hursley, UK
Re: What does the 'end' address on a USING statement mean?
On 6 November 2014 17:20, Jonathan Scott jonathan_sc...@vnet.ibm.com wrote: Paul Gilmartin wrote: Are dependent USINGs referring to the same base register allowed to overlap? There should be no objection to this provided that they resolve to identical base and displacement regardless which USING is used. But this introduces an ambiguity in DROP by address when that address can be resolved, albeit equivalently, by either of two dependent USINGs. When all else is equal a new dependent USING for a given location should supersede any older one for the same location and base USING. 1) This is not the way non-dependent USINGs work. There can be multiple right-parts (registers, =bases, in some sense) with at worst a warning. Why should this be different? 2) Having multiple overlapping dependent USINGs can be useful. For example: xCBAREA DS XL... ... USING IHADCB,xCBAREA USING IFGACB,xCBAREA ... MVC DCBDDNAM,some_ddname Works for DCB or ACB ... TMDCBOFLGS,DCBOPEN Works for DCB or ACB ... TMACBDSOR2,ACBDORGAIs this an ACB? JOHandle_ACB Go do ACB-only stuff ... DROP ??? I'm not claiming this is the right technique -- clearly there are other ways of doing it -- but it's a use case. Tony H.
Re: What does the 'end' address on a USING statement mean?
On 6 November 2014 17:02, Robert A. Rosenberg a...@rarpsl.com wrote: How about allowing the use of an label on the Dependent USING and the DROP uses that label? That way you and identify the Dependent USING you are DROPing. But then you'd have to use the label for each reference. Unless there's some new sort of label just for this purpose. Tony H.
Re: What does the 'end' address on a USING statement mean?
USING ought to be as helpful as possible. HLASM - like other products can be driven by user requests. The more requests/votes we have - the higher up the list the requirement goes. If the community feels this change is important/useful/desirable then please raise a requirement and vote for it. It will certainly get my vote. see http://www.ibm.com/support/docview.wss?uid=swg21577670 Sharuff Date:Tue, 4 Nov 2014 08:41:10 -0700 From:Paul Gilmartin paulgboul...@aim.com Subject: Re: What does the 'end' address on a USING statement mean? On 2014-11-04, at 05:54, Peter Relson wrote: Since the construct pre-dated long-displacement, it's quite possible that it means very little with respect to long displacement. Or perhaps, for long displacement, the end is to some extent ignored (although it might be used to select from among multiple choices). ... As opposed to USING (*,*+1000),RegA USING *+1000,RegB It seems to me to be even more important to enforce END with long displacements because in many cases base register combinations which produce unique resolutions with 12-bit displacements may produce ambiguous resolutions with long displacements. I suspect that HLASM development merely overlooked the design changes necessary to accommodate long displacements fully. -- gil Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: What does the 'end' address on a USING statement mean?
Since the construct pre-dated long-displacement, it's quite possible that it means very little with respect to long displacement. Or perhaps, for long displacement, the end is to some extent ignored (although it might be used to select from among multiple choices). I think that the main reason the construct was introduced was so that the coder could make it clear which register to use when there might be overlap if the entire 4K range was in play. For example, USING *,RegA USING *+1000,RegB Produces ambiguity when referencing anything in the offset range 1000 through 4095, which can result in ** ASMA303W Multiple address resolutions may result from this USING and the USING on statement number ... As opposed to USING (*,*+1000),RegA USING *+1000,RegB Has anyone not been burned (in particular, prior to that warning message) by having coded USING *,RegA USING *+4096,RegB ... * Failed to DROP * Some place where RegA,RegB does not have the right value BASR RegC,0 USING *,RegC ... Some reference that happened to be closer to RegA+x'1000' (i.e, RegB) than to RegC so that the assembler used RegB as the base reg Peter Relson z/OS Core Technology Design
Re: What does the 'end' address on a USING statement mean?
On 2014-11-04, at 05:54, Peter Relson wrote: Since the construct pre-dated long-displacement, it's quite possible that it means very little with respect to long displacement. Or perhaps, for long displacement, the end is to some extent ignored (although it might be used to select from among multiple choices). ... As opposed to USING (*,*+1000),RegA USING *+1000,RegB It seems to me to be even more important to enforce END with long displacements because in many cases base register combinations which produce unique resolutions with 12-bit displacements may produce ambiguous resolutions with long displacements. I suspect that HLASM development merely overlooked the design changes necessary to accommodate long displacements fully. -- gil
What does the 'end' address on a USING statement mean?
I recently started looking at the 'end' specification for the USING statement, something I've neglected for a long time. I *thought* it indicated the last location that could be assembled with that USING, but I'm not so sure any more. I have the following source file: dummycsect , using (dummy,dummy+6000),1 ceject 0 lg1,far1 lg1,far2 lg1,far3 lg1,far4 org dummy+4000 far1 dcad(1) org dummy+5000 far2 dcad(2) org dummy+6000 far3 dcad(3) org dummy+7000 far4 dcad(4) end , The relevant portion of the listing looks like this: LocObject Code Addr1Addr2Stmt Source Statement 1B60 1 dummycsect , R:1 2 using (dummy,dummy+6000),1 Active Usings: dummy(X'1770'),R1 LocObject Code Addr1Addr2Stmt Source Statement E310 1FA0 0004 0FA0 4 lg1,far1 0006 E310 1388 0104 1388 5 lg1,far2 000C E310 1770 0104 1770 6 lg1,far3 0012 E310 1B58 0104 1B58 7 lg1,far4 00180018 0FA0 9 org dummy+4000 0FA0 0001 10 far1 dcad(1) 0FA80FA8 1388 11 org dummy+5000 1388 0002 12 far2 dcad(2) 13901390 1770 13 org dummy+6000 1770 0003 14 far3 dcad(3) 17781778 1B58 15 org dummy+7000 1B58 0004 16 far4 dcad(4) 17 end , The last sentence of the description of the 'end' specification for an ordinary USING says, Thus USING base,reg is equivalent to USING (base,base+4096),reg. So, my thinking was as follows: - Since a default USING can only be used up to base+4095 (because the maximum 4K displacement is x'FFF'), I assume this means that the 'base+4096' points to the byte *past* the last valid USING location. - If the previous item is true then the Active Usings line that shows a range of x'1770' bytes for 'dummy' would mean that the last valid address that can use R1 as a base is dummy+5999. - If the previous item is true then the LG of FAR3 at location x'C' should not successfully assemble because FAR3 is at DUMMY+6000. - Even if there is a confusion between 1 byte prior to the specified end vs. the specified end, the LG for FAR4 at location x'12' should certainly fail. Since the LG of FAR4 didn't fail, my understanding of the function of the 'end' specification must be a misunderstanding. Can anyone offer any clarity? Thanks. - mb
Re: What does the 'end' address on a USING statement mean?
Mark, This may not clarify the issue, but isn't the offset in the LG instruction 20-bit? That would mean that it can address 0 to F, or 0 to 1,048,575, right? Using your last instruction as an example: 0012 E310 1B58 0104 1B58 7 lg1,far4 xxx xx The x are the displacement from register 1 so, that means you are addressing x'01B58' from register 1. Maybe try a L instruction and see if it holds up to what your interpretation is. If it does, then try an LY instruction. The LY has the same 20-bit displacement as the LG. Just a thought, not an explanation. Chuck Charles (Chuck) Hardee Senior Systems Engineer/Database Administration EAS Information Technology Thermo Fisher Scientific 300 Industry Drive | Pittsburgh, PA 15275 Phone +1 (724) 517-2633 | Mobile +1 (412) 877-2809 | FAX: +1 (412) 490-9230 chuck.har...@thermofisher.com | www.thermofisher.com WORLDWIDE CONFIDENTIALITY NOTE: Dissemination, distribution or copying of this e-mail or the information herein by anyone other than the intended recipient, or an employee or agent of a system responsible for delivering the message to the intended recipient, is prohibited. If you are not the intended recipient, please inform the sender and delete all copies. -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Mark Boonie Sent: Monday, November 03, 2014 1:57 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: What does the 'end' address on a USING statement mean? I recently started looking at the 'end' specification for the USING statement, something I've neglected for a long time. I *thought* it indicated the last location that could be assembled with that USING, but I'm not so sure any more. I have the following source file: dummycsect , using (dummy,dummy+6000),1 ceject 0 lg1,far1 lg1,far2 lg1,far3 lg1,far4 org dummy+4000 far1 dcad(1) org dummy+5000 far2 dcad(2) org dummy+6000 far3 dcad(3) org dummy+7000 far4 dcad(4) end , The relevant portion of the listing looks like this: LocObject Code Addr1Addr2Stmt Source Statement 1B60 1 dummycsect , R:1 2 using (dummy,dummy+6000),1 Active Usings: dummy(X'1770'),R1 LocObject Code Addr1Addr2Stmt Source Statement E310 1FA0 0004 0FA0 4 lg1,far1 0006 E310 1388 0104 1388 5 lg1,far2 000C E310 1770 0104 1770 6 lg1,far3 0012 E310 1B58 0104 1B58 7 lg1,far4 00180018 0FA0 9 org dummy+4000 0FA0 0001 10 far1 dcad(1) 0FA80FA8 1388 11 org dummy+5000 1388 0002 12 far2 dcad(2) 13901390 1770 13 org dummy+6000 1770 0003 14 far3 dcad(3) 17781778 1B58 15 org dummy+7000 1B58 0004 16 far4 dcad(4) 17 end , The last sentence of the description of the 'end' specification for an ordinary USING says, Thus USING base,reg is equivalent to USING (base,base+4096),reg. So, my thinking was as follows: - Since a default USING can only be used up to base+4095 (because the maximum 4K displacement is x'FFF'), I assume this means that the 'base+4096' points to the byte *past* the last valid USING location. - If the previous item is true then the Active Usings line that shows a range of x'1770' bytes for 'dummy' would mean that the last valid address that can use R1 as a base is dummy+5999. - If the previous item is true then the LG of FAR3 at location x'C' should not successfully assemble because FAR3 is at DUMMY+6000. - Even if there is a confusion between 1 byte prior to the specified end vs. the specified end, the LG for FAR4
Re: What does the 'end' address on a USING statement mean?
I believe the USING range limits are currently tested only for unsigned 12-bit displacements; you happen to have chosen a test case in which the LG instructions use signed 20-bit displacements. To see the effects of USING range limits, try dropping a zero from the ends of all the offsets, and change the LG instructions to L, which uses the 12-bit displacement. Regards... John
Re: What does the 'end' address on a USING statement mean?
On Mon, Nov 3, 2014 at 12:56 PM, Mark Boonie boo...@us.ibm.com wrote: I recently started looking at the 'end' specification for the USING statement, something I've neglected for a long time. I *thought* it indicated the last location that could be assembled with that USING, but I'm not so sure any more. I have the following source file: snip The last sentence of the description of the 'end' specification for an ordinary USING says, Thus USING base,reg is equivalent to USING (base,base+4096),reg. So, my thinking was as follows: - Since a default USING can only be used up to base+4095 (because the maximum 4K displacement is x'FFF'), I assume this means that the 'base+4096' points to the byte *past* the last valid USING location. False statement! What is confusing you is that some instructions, such as the LG you are using, don't use 12 bit offsets but use the new zArchitecture long displacement which uses 20 bit offsets. So, for long displacement instructions, the range is from -524,288 to +524,287 (1 megabyte) from the base. Page 1-16 of the -9 version of the PoPS goes into this. quote Long-Displacement Facility The long-displacement facility provides a 20-bit signed-displacement field in 69 previously existing instructions (by using a previously unused byte in the instructions) and 44 new instructions. A 20-bit signed displacement allows relative addressing of up to 524,287 bytes beyond the location designated by a base register or base-and-index-register pair and up to 524,288 bytes before that location. The enhanced previously existing instructions generally are ones that handle 64-bit binary integers. The new instructions generally are new versions of instructions for 32-bit binary integers. The new instructions also include (1) a LOAD BYTE instruction that sign-extends a byte from storage to form a 32-it or 64-bit result in a general register and (2) new floating-point LOAD and STORE instructions. The long-displacement facility provides register-constraint relief by reducing the need for base registers, code size reduction by allowing fewer instructions to be used, and additional improved performance through removal of possible address-generation interlocks. (June, 2003) quote - If the previous item is true then the Active Usings line that shows a range of x'1770' bytes for 'dummy' would mean that the last valid address that can use R1 as a base is dummy+5999. - If the previous item is true then the LG of FAR3 at location x'C' should not successfully assemble because FAR3 is at DUMMY+6000. - Even if there is a confusion between 1 byte prior to the specified end vs. the specified end, the LG for FAR4 at location x'12' should certainly fail. Since the LG of FAR4 didn't fail, my understanding of the function of the 'end' specification must be a misunderstanding. Can anyone offer any clarity? Thanks. Your understanding for the USING is absolutely correct. As mentioned above, your misunderstanding is (ignorance of?) the existence of the long displacement facility. - mb -- The temperature of the aqueous content of an unremittingly ogled culinary vessel will not achieve 100 degrees on the Celsius scale. Maranatha! John McKown
Re: What does the 'end' address on a USING statement mean?
This may not clarify the issue, but isn't the offset in the LG instruction 20-bit? That would mean that it can address 0 to F, or 0 to 1,048,575, right? Actually, Chuck, it's a signed displacement, so it can address -512K - 512K-1 from the address in the base and index registers. However, I thought it would be useful to limit the USING range so that attempts to address beyond the end of a DSECT would be flagged. After making the changes suggested by John E. (thanks, John), I find that an L instruction does get flagged as I suspected. However, neither L nor LY can be used as a substitute, since they only deal with 32-bit registers. What I need in this (contrived) example is a non-long-displacement 64-bit LOAD, which doesn't exist. I've often thought that HLASM has a few weaknesses when it comes to long displacements. For example, I can use the OPTABLE/MACHINE options to restrict the instruction set to eliminate the newer instructions, but I can't tell HLASM to avoid generating long-displacements for those instructions that were enhanced to use 20-bit displacements (e.g., LG). Apparently (and disappointingly), I can also only limit the range of a USING for non-long-displacement instructions. But, at least the behavior is explained. Thanks for your help. - mb IBM Mainframe Assembler List ASSEMBLER-LIST@LISTSERV.UGA.EDU wrote on 11/03/2014 02:24:53 PM: From: Hardee, Chuck chuck.har...@thermofisher.com To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Date: 11/03/2014 02:48 PM Subject: Re: What does the 'end' address on a USING statement mean? Sent by: IBM Mainframe Assembler List ASSEMBLER-LIST@LISTSERV.UGA.EDU Mark, This may not clarify the issue, but isn't the offset in the LG instruction 20-bit? That would mean that it can address 0 to F, or 0 to 1,048,575, right? Using your last instruction as an example: 0012 E310 1B58 0104 1B58 7 lg 1,far4 xxx xx The x are the displacement from register 1 so, that means you are addressing x'01B58' from register 1. Maybe try a L instruction and see if it holds up to what your interpretation is. If it does, then try an LY instruction. The LY has the same 20-bit displacement as the LG. Just a thought, not an explanation. Chuck Charles (Chuck) Hardee Senior Systems Engineer/Database Administration EAS Information Technology Thermo Fisher Scientific 300 Industry Drive | Pittsburgh, PA 15275 Phone +1 (724) 517-2633 | Mobile +1 (412) 877-2809 | FAX: +1 (412) 490-9230 chuck.har...@thermofisher.com | www.thermofisher.com
Re: What does the 'end' address on a USING statement mean?
Hum, I accept the desire while not understanding it. You could try: L Rx,DOUBLEWORD SLLG Rx,Rx,32 MOVE TO HIGH WORD, CC NOT DISTURBED L Rx,DOUBLEWORD+4 I can't find a single instruction alternative. What is wrong with the 20 bit displacement instructions? Just curious. On Mon, Nov 3, 2014 at 7:52 PM, Tony Harminc t...@harminc.com wrote: On 3 November 2014 15:17, Mark Boonie boo...@us.ibm.com wrote: However, I thought it would be useful to limit the USING range so that attempts to address beyond the end of a DSECT would be flagged. After making the changes suggested by John E. (thanks, John), I find that an L instruction does get flagged as I suspected. However, neither L nor LY can be used as a substitute, since they only deal with 32-bit registers. What I need in this (contrived) example is a non-long-displacement 64-bit LOAD, which doesn't exist. Depending on what you want to do with that 64-bit value (and just how contrived an example you want) you could use LD. Of course it'll be in the wrong register, but you can then store it somewhere else with STD. How about LMD? That has 12-bit displacements (two of them!), and you can jig it to effectively load a 64-bit general register from 8 bytes in storage. Then there's CSST. Not the most efficient way to load a register, but it too has 12-bit displacements. Unlike LMD, it does set the condition code. I think I should get back to work... Tony H. -- The temperature of the aqueous content of an unremittingly ogled culinary vessel will not achieve 100 degrees on the Celsius scale. Maranatha! John McKown
