Re: Usefullness (or not) of STOC/LOC instructions?
- Original Message From: McKown, John john.mck...@healthmarkets.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wed, November 28, 2012 4:06:00 PM Subject: Re: Usefullness (or not) of STOC/LOC instructions? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Kirk Talman Sent: Wednesday, November 28, 2012 2:26 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Usefullness (or not) of STOC/LOC instructions? I guess, in my case, it is a combination of esthetics and being concerned about possible AR mode considerations. In AR mode: LR2,0(,R1) and LR2,0(R1) will likely result in greatly different values being loaded into R2 if the contents of AR1 primary address space. The latter can also run into issues in AMODE 64. The index register is always 32 bits, not 24, 31, or 64 depending upon AMODE. Waste the extra nano-second, use the comma. It is meaningful. Lloyd -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Usefullness (or not) of STOC/LOC instructions?
It's too complicated to explain here, and you wouldn't understand anyway And I'd add and since it is not part of the programming interface we would not explain it within the documentation anyway because if we did we might well have to maintain that behavior in the future for compatibility. This is why most new references do not say unpredictable but instead (for a register) say something like used as a work register. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Usefullness (or not) of STOC/LOC instructions?
On Thu, 29 Nov 2012 08:07:13 -0500, John P. Baker wrote: According to the z/Architecture Principles of Operation, SA22-7832-09, page 5-9, all 64 bits of the index register are used. Correct. And on the next page, quote In forming the intermediate sum, the base address and index are treated as 64-bit binary integers. A 12-bit displacement is treated as a 12-bit unsigned binary integer, and 52 zero bits are appended on the left. A 20-bit displacement is treated as a 20-bit signed binary integer, and 44 bits equal to the sign bit are appended on the left. The three are added as 64-bit binary numbers, ignoring overflow. The sum is always 64 bits long and is used as an intermediate value to form the generated address. /quote My interpretation is that it is not the AMODE, but the architectural mode that affects the interpretation of the index register. The AMODE determines how many bits of the 64-bit result of the address arithmetic. The address used is a 64-bit address with the high 33 bits set to zero in 31-bit more or the high 40 bits set to zero in 24-bit mode. On a z/Architecture-capable machine, in ESA mode, bits 0-31 of the index register are ignored, and bits 32-63 are used. Maybe, but if the POO says that, I don't see it. It seems to me that additional complexity would be required to implement that, and that there would be no benefit. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Usefullness (or not) of STOC/LOC instructions?
On Wed, 28 Nov 2012 16:21:05 -0800, Charles Mills charl...@mcn.org wrote: LOL. Ain't it the truth! Possibly even too much bother to explain to the tech writers or I don't have a precise enough logical grasp of it to translate its operation into English sentences. The Architects write the POO. They write what they mean and they mean what they write. They have to, since it is the specification to which the Engineers must conform. They do, on occasion, provide some guidance to the Engineers that can help reduce construction costs. Alan Altmark IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Usefullness (or not) of STOC/LOC instructions?
On Thu, 29 Nov 2012 04:29:25 -0800, Lloyd Fuller wrote: The latter can also run into issues in AMODE 64. The index register is always 32 bits, not 24, 31, or 64 depending upon AMODE. Waste the extra nano-second, use the comma. It is meaningful. I hadn't known that; I'm behind in my reading; thanks. Is it sign-extended, or unsigned? (The worst case was the 6502, which ignored carries out of the low half of the address, at least sometimes.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Usefullness (or not) of STOC/LOC instructions?
Alan, a thousand pardons. I was thinking of vendor manuals in general. IBM manuals are frankly IMHO among the best in the industry, and I have always thought the POO/PoOp/whatever was among the best of the IBM manuals. Related digression: why is that *hardware* manuals (any vendor) always seem to be so precise, whereas many (most?) *software* manuals are so soft and squishy? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Alan Altmark Sent: Thursday, November 29, 2012 6:26 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Usefullness (or not) of STOC/LOC instructions? On Wed, 28 Nov 2012 16:21:05 -0800, Charles Mills charl...@mcn.org wrote: LOL. Ain't it the truth! Possibly even too much bother to explain to the tech writers or I don't have a precise enough logical grasp of it to translate its operation into English sentences. The Architects write the POO. They write what they mean and they mean what they write. They have to, since it is the specification to which the Engineers must conform. They do, on occasion, provide some guidance to the Engineers that can help reduce construction costs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Usefullness (or not) of STOC/LOC instructions?
On 29 November 2012 07:29, Lloyd Fuller leful...@sbcglobal.net wrote: The latter can also run into issues in AMODE 64. The index register is always 32 bits, not 24, 31, or 64 depending upon AMODE. Waste the extra nano-second, use the comma. It is meaningful. I think you're muddling the index register (always 64 bits in zArch) with the access register (always 32 bits on 370/ESA through zArch). Or perhaps it was just a typo - 32 was meant to be 64? Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Usefullness (or not) of STOC/LOC instructions?
In article 6123004369926276.wa.paulgboulderaim@listserv.ua.edu you wrote: On Thu, 29 Nov 2012 04:29:25 -0800, Lloyd Fuller wrote: The latter can also run into issues in AMODE 64. The index register is always 32 bits, not 24, 31, or 64 depending upon AMODE. Waste the extra nano-second, use the comma. It is meaningful. I hadn't known that; I'm behind in my reading; thanks. Is it sign-extended, or unsigned? (The worst case was the 6502, which ignored carries out of the low half of the address, at least sometimes.) -- gil As others have already pointed out, this isn't true. The full 64 bits are always used in the addition and any overflow is ignored. The AMODE determines the memory address to be used, ignoring (when 24 or 31 bit) the high order bits. -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Usefullness (or not) of STOC/LOC instructions?
I was muddling. It is always 64 bit in zArch. My point still remains: save yourself and follow-on programmers time and effort - put in the comma. Lloyd - Original Message From: Tony Harminc t...@harminc.net To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thu, November 29, 2012 12:53:00 PM Subject: Re: Usefullness (or not) of STOC/LOC instructions? On 29 November 2012 07:29, Lloyd Fuller leful...@sbcglobal.net wrote: The latter can also run into issues in AMODE 64. The index register is always 32 bits, not 24, 31, or 64 depending upon AMODE. Waste the extra nano-second, use the comma. It is meaningful. I think you're muddling the index register (always 64 bits in zArch) with the access register (always 32 bits on 370/ESA through zArch). Or perhaps it was just a typo - 32 was meant to be 64? Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Usefullness (or not) of STOC/LOC instructions?
On Wed, 28 Nov 2012 15:39:56 -0500, John Gilmore jwgli...@gmail.com wrote: I must, however, add that unpredictable is sometimes in some IBM publications used as a polite euphemism for It's too complicated to explain here, and you wouldn't understand anyway. In my 30 years of creating, documenting, and using IBM APIs, I have never seen such usage. For a particular implementation, results are determinate and predictable to the engineers of the implementation. But between two different implementations, the results may be different. Consequently, the programmer may *observe* a particular behavior, but they should not attempt to *predict* any particular behavior, as the engineers are not obligated to maintain any particular result. The POO says [p.1-29] that compatibility is maintained (defined as 'identical results') as long as the program, among other things, does not depend on results or functions that are defined to be unpredictable or model-dependent or are identified as undefined. This includes the requirement that the program should not depend on the assignment of device numbers and CPU addresses. Alan Altmark IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Usefullness (or not) of STOC/LOC instructions?
On Wed, 28 Nov 2012 14:35:22 -0500, Tony Harminc t...@harminc.net wrote: It would be unforgivable if the architects baked in I'm sure this was going to say something interesting... Of course! Everything I say is interesting! (To me, anyway!) :-) I was going to say that it would be unforgivable if the architects baked a specific implementation into the architecture, as it would undermine a half century of effort. They are very experienced at knowing when to use a fine-point pen vs. a broad brush. Alan Altmark IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Usefullness (or not) of STOC/LOC instructions?
On Thu, 29 Nov 2012 11:09:39 -0600, Paul Gilmartin wrote: (The worst case was the 6502, which ignored carries out of the low half of the address, at least sometimes.) No, it didn't. You are talking about the conditional branch instructions. The branch offset is an 8-bit signed integer. When the branch is to be taken, the offset is added to the program counter. That is done in one cycle, at the end of which the resulting address is put on the address bus. If there is a carry, the data returned is ignored. The carry is added to the high byte of the address and the corrected address is placed on the address bus during the next cycle. The carry is not ignored. In the 6505, every clock cycle was a memory cycle. IIRC, this was the only case when a memory reference was ignored. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Usefullness (or not) of STOC/LOC instructions?
On 11/29/2012 2:52 PM, Alan Altmark wrote: They are very experienced at knowing when to use a fine-point pen vs. a broad brush. I don't want to start an argument, but I have pet peeves with some of the design. For example, the TRAP instructions cause an exception unless trapping is properly enabled. Let's say I have a weird problem where a module is working fine in testing, but causes errors when placed in LPA. If I place TRAPs into the module, all other users will bomb. Had the design specified TRAPs to act as (expensive) NOPs, this would be a non-issue. Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Usefullness (or not) of STOC/LOC instructions?
On 11/28/2012 12:39 PM, John Gilmore wrote: I must, however, add that unpredictable is sometimes in some IBM publications used as a polite euphemism for It's too complicated to explain here, and you wouldn't understand anyway. Sometimes they do that because they get pressured to retrofit a cool new instruction back to an older model and there is no way to make the older model work correctly. For example, it used to be undefined which space instructions were fetched from while in cross-memory mode. The logical choice was primary (and the hardware designers knew that) but they were unable to make it work on the older processor to which the function was being retrofit. We (software developers) suffered for at least a decade with that ugly restriction. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Usefullness (or not) of STOC/LOC instructions?
On 11/29/2012 4:29 AM, Lloyd Fuller wrote: The latter can also run into issues in AMODE 64. The index register is always 32 bits, not 24, 31, or 64 depending upon AMODE. Waste the extra nano-second, use the comma. It is meaningful. In forming the intermediate sum, the base address and index are treated as 64-bit binary integers.A 12-bit displacement is treated as a 12-bit unsigned binary integer, and 52 zero bits are appended on the left. A 20-bit displacement is treated as a 20-bit signed binary integer, and 44 bits equal to the sign bit are appended on the left. The three are added as 64-bit binary numbers, ignoring overflow. The sum is always 64 bits long and is used as an intermediate value to form the generated address. The bits of the intermediate value are numbered 0-63. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Usefullness (or not) of STOC/LOC instructions?
On Tue, 27 Nov 2012 14:55:16 -0600, Paul Gilmartin paulgboul...@aim.com wrote: But what plausible use do you envision that anyone or any group at IBM might have for the model dependent character? It requires that software developers test on every available and possible future system. Simply, it's irresponsible not to have made the behavior consistent across models. If it's going to fail on some models, it should be designed to fail likewise on all models. Perhaps with SIE? There is nothing new here, Paul. One of the original design points for S/360 was to separate machine behavior from the programming interface. You want to be able to change and optimize the machine behaviors over time without screwing up the interface. This is precisely why you see model-dependent in the documentation - so you DON'T build an expectation. And it's why you can still run programs written in 1965. Where conditional execution is involved, the machine often tries to avoid unnecessary work. This is what out-of-order execution and pipelining are all about. If the machine decides NOT to do something, then the machine MAY not detect certain conditions. Nonetheless, the instruction yields the expected result. See Sequence of Storage References in Ch. 5 of the POP, particularly Divisible instruction execution. Sometimes part of the instruction can be run while a data fetch is in progress. Note that most data reference (load or store) requires intermediate fetches to get ART and DAT entries, etc. Some of this parallelism is needed to counter the distance- and cache-related effects of accessing memory. As STOC Usage Note 2 states, if the store is skipped because of the condition code, the operand might not be fetched into cache. But it is a matter of implementation as to exactly when the circuitry triggers things like PER storage-alteration events or set the page change bit. As the machines get smarter, the accuracy of those events improves. While the machine may over-indicate (a false positive) an event, it will never under-indicate an event. It would be unforgivable if the architects baked in Alan Altmark IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Usefullness (or not) of STOC/LOC instructions?
I guess what Paul was really disappointed in, is that C uses binary zero as the NULL pointer. And it might be nice to be able to use the STOC command to store a value with: L R2,INTVAL LT R1,POINTER STOC R2,0(,R1),NZ instead of: LT R1,POINTER JZ AROUND L R2,INTVAL ST R2,0(,R1) AROUND DS 0H for the C construct: if (POINTER != NULL) *POINTER=INTVAL; I don't know what the C compiler actually generates for that particular code sequence. But the STOC almost seems made-to-order for it. But, given the OP's original message, this results in an S0C4-4, on zPDT, due to storage protection causing a PIC 004. I don't know how zPDT actually implements the zArch, but if it is totally software, I really don't understand why it generates a PIC 004. Unless it is designed to be the most restrictive and generate the least desirable model dependent operations so that the developer is force to write code which is most likely runnable on any zArch (of the appropriate level). If anybody wants to complain about model dependent behavior, read up on the ARM architecture. You almost need to target your code for each vendor's implementation. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets® 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® is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. –The Chesapeake Life Insurance Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Alan Altmark Sent: Wednesday, November 28, 2012 12:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Usefullness (or not) of STOC/LOC instructions? On Tue, 27 Nov 2012 14:55:16 -0600, Paul Gilmartin paulgboul...@aim.com wrote: But what plausible use do you envision that anyone or any group at IBM might have for the model dependent character? It requires that software developers test on every available and possible future system. Simply, it's irresponsible not to have made the behavior consistent across models. If it's going to fail on some models, it should be designed to fail likewise on all models. Perhaps with SIE? There is nothing new here, Paul. One of the original design points for S/360 was to separate machine behavior from the programming interface. You want to be able to change and optimize the machine behaviors over time without screwing up the interface. This is precisely why you see model-dependent in the documentation - so you DON'T build an expectation. And it's why you can still run programs written in 1965. Where conditional execution is involved, the machine often tries to avoid unnecessary work. This is what out-of-order execution and pipelining are all about. If the machine decides NOT to do something, then the machine MAY not detect certain conditions. Nonetheless, the instruction yields the expected result. See Sequence of Storage References in Ch. 5 of the POP, particularly Divisible instruction execution. Sometimes part of the instruction can be run while a data fetch is in progress. Note that most data reference (load or store) requires intermediate fetches to get ART and DAT entries, etc. Some of this parallelism is needed to counter the distance- and cache-related effects of accessing memory. As STOC Usage Note 2 states, if the store is skipped because of the condition code, the operand might not be fetched into cache. But it is a matter of implementation as to exactly when the circuitry triggers things like PER storage-alteration events or set the page change bit. As the machines get smarter, the accuracy of those events improves. While the machine may over-indicate (a false positive) an event, it will never under-indicate an event. It would be unforgivable if the architects baked in Alan Altmark IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Usefullness (or not) of STOC/LOC instructions?
On 28 November 2012 13:54, Alan Altmark alan_altm...@us.ibm.com wrote: On Tue, 27 Nov 2012 14:55:16 -0600, Paul Gilmartin paulgboul...@aim.com wrote: But what plausible use do you envision that anyone or any group at IBM might have for the model dependent character? It requires that software developers test on every available and possible future system. Simply, it's irresponsible not to have made the behavior consistent across models. If it's going to fail on some models, it should be designed to fail likewise on all models. Perhaps with SIE? There is nothing new here, Paul. One of the original design points for S/360 was to separate machine behavior from the programming interface. You want to be able to change and optimize the machine behaviors over time without screwing up the interface. This is precisely why you see model-dependent in the documentation - so you DON'T build an expectation. And it's why you can still run programs written in 1965. There are two terms used in the Principles of Operation - model dependent and unpredictable. It may be that the use of these terms has changed slightly, but I have always read the former as imposing a weaker constraint on the programmer than the latter. If a behaviour is model dependent it is presumably consistent on that model, and it would be possible, if fairly unlikely, that a program could discover the behaviour and exploit it. This is certainly not the case for unpredictable results, which can vary from one execution to the next. Regardless, I disagree strongly with Paul on this in general; I think the notion of not overspecifying behaviour is a very good one. IBM has historically done an amazing job of writing the Principle of Operation so that it specifies the required behaviour of the machine, and clarifies certain possible variations that should not be relied on. And they are very quick to correct errors and unclear writing on those few occasions it arises. As STOC Usage Note 2 states, if the store is skipped because of the condition code, the operand might not be fetched into cache. But it is a matter of implementation as to exactly when the circuitry triggers things like PER storage-alteration events or set the page change bit. As the machines get smarter, the accuracy of those events improves. While the machine may over-indicate (a false positive) an event, it will never under-indicate an event. I agree, though one must be careful with the notions of over and under. For example the change bit is never under set, but the reference bit may well be. I think Dave's original question was quite reasonable, though: what *are* these instructions good for in the real world (or rather, under what circumstances do they provide a performance advantage compared to BC + L or ST) if not for the sort of usage he suggests? It would be unforgivable if the architects baked in I'm sure this was going to say something interesting... Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Usefullness (or not) of STOC/LOC instructions?
On Tue, 27 Nov 2012 14:55:16 -0600, Paul Gilmartin paulgboul...@aim.com wrote: It requires that software developers test on every available and possible future system. Simply, it's irresponsible not to have made the behavior consistent across models. Think Java. The JVM can construct different instruction sequences (JIT compile) based on the the underlying hardware, determined when the JVM is started. Scott Fagen Chief Architect - Mainframe CA Technologies -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Usefullness (or not) of STOC/LOC instructions?
might a lurker ask questions? if one rearranges the code at bottom as this, is the load of R2 cheaper because it can be done in parallel w/the LT? is it worth doing if the JZ is taken? is 0(,R1) preferred to 0(R1) because of cost or esthetics? LT R1,POINTER L R2,INTVAL JZ AROUND ST R2,0(,R1) AROUND DS0H From: McKown, John john.mck...@healthmarkets.com L R2,INTVAL LT R1,POINTER STOC R2,0(,R1),NZ instead of: LT R1,POINTER JZ AROUND L R2,INTVAL ST R2,0(,R1) AROUND DS0H for the C construct: if (POINTER != NULL) *POINTER=INTVAL; - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Usefullness (or not) of STOC/LOC instructions?
FWIW, I agree with all of the spirit and almost all of the substance of Tony Harminc's post. I must, however, add that unpredictable is sometimes in some IBM publications used as a polite euphemism for It's too complicated to explain here, and you wouldn't understand anyway. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Usefullness (or not) of STOC/LOC instructions?
Tony Harminc wrote: On 28 November 2012 13:54, Alan Altmark alan_altm...@us.ibm.com wrote: On Tue, 27 Nov 2012 14:55:16 -0600, Paul Gilmartin paulgboul...@aim.com wrote: But what plausible use do you envision that anyone or any group at IBM might have for the model dependent character? It requires that software developers test on every available and possible future system. Simply, it's irresponsible not to have made the behavior consistent across models. If it's going to fail on some models, it should be designed to fail likewise on all models. Perhaps with SIE? There is nothing new here, Paul. One of the original design points for S/360 was to separate machine behavior from the programming interface. You want to be able to change and optimize the machine behaviors over time without screwing up the interface. This is precisely why you see model-dependent in the documentation - so you DON'T build an expectation. And it's why you can still run programs written in 1965. There are two terms used in the Principles of Operation - model dependent and unpredictable. It may be that the use of these terms has changed slightly, but I have always read the former as imposing a weaker constraint on the programmer than the latter. If a behaviour is model dependent it is presumably consistent on that model, and it would be possible, if fairly unlikely, that a program could discover the behaviour and exploit it. This is certainly not the case for unpredictable results, which can vary from one execution to the next. Regardless, I disagree strongly with Paul on this in general; I think the notion of not overspecifying behaviour is a very good one. IBM has historically done an amazing job of writing the Principle of Operation so that it specifies the required behaviour of the machine, and clarifies certain possible variations that should not be relied on. And they are very quick to correct errors and unclear writing on those few occasions it arises. As STOC Usage Note 2 states, if the store is skipped because of the condition code, the operand might not be fetched into cache. But it is a matter of implementation as to exactly when the circuitry triggers things like PER storage-alteration events or set the page change bit. As the machines get smarter, the accuracy of those events improves. While the machine may over-indicate (a false positive) an event, it will never under-indicate an event. I agree, though one must be careful with the notions of over and under. For example the change bit is never under set, but the reference bit may well be. I think Dave's original question was quite reasonable, though: what *are* these instructions good for in the real world (or rather, under what circumstances do they provide a performance advantage compared to BC + L or ST) if not for the sort of usage he suggests? I can easily think of many applications although not necessarily C. A lot of the newer facilities seem to be targeted at Java. Regards, Henry -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Usefullness (or not) of STOC/LOC instructions?
LOL. Ain't it the truth! Possibly even too much bother to explain to the tech writers or I don't have a precise enough logical grasp of it to translate its operation into English sentences. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Gilmore Sent: Wednesday, November 28, 2012 12:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Usefullness (or not) of STOC/LOC instructions? FWIW, I agree with all of the spirit and almost all of the substance of Tony Harminc's post. I must, however, add that unpredictable is sometimes in some IBM publications used as a polite euphemism for It's too complicated to explain here, and you wouldn't understand anyway. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Usefullness (or not) of STOC/LOC instructions?
We've been using the STOC/LOC (STORE/LOAD ON CONDITION) instructions for some time... But, we just noticed a few words in the Principles of Operations (I'm quoting from the STOC discussion): When the condition specified by the M3 field is not met (that is, store operation is not performed), it is model dependent whether any or all of the following occur for the second operand: (a) an access exception is recognized, (b) a PER storage-alteration event is recognized, (c) a PER zero-address-detection event is recognized, or (d) the change bit is set. Now - a rather common programming idiom is to store a result if a pointer is not NULL. So, it would seem that a comparision of a pointer to x'0' followed by a STOC would be a nice programming idiom. However, one of our recent tests (on a zPDT platform) blows up with this paradigm... getting an 0C4. Even though the condition in the STOC is not met and the store will not occur... The Principles of Operation also appear to be inconsistent, it makes this claim: For example, the following two instruction sequences are equivalent. STOCG 15,256(7),8 BC 7,SKIP STG 15,256(0,7) SKIP DS 0H But, according to the paragraph quoted above, the two sequences are not equivalent. The sequence on the right might not have the possibility of generating an access-exception, while the STOCG does have that possibility even though the store would not occur. I find these semantics a little baffling and wonder if that doesn't essentially make STOC/LOC pretty much unusable in all but the most restrictive situations? Thoughts/Opinions??? - Dave Rivers - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Usefullness (or not) of STOC/LOC instructions?
That is an interesting observation. And, like you, makes me really wonder why bother?. You mention testing for zero, but any address validity methodology is suspect when you can get an S0C4 (like PIC 11) if the actual address is invalid. Much safer to do the test/branch/modify. -- 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 Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Thomas David Rivers Sent: Tuesday, November 27, 2012 10:19 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Usefullness (or not) of STOC/LOC instructions? We've been using the STOC/LOC (STORE/LOAD ON CONDITION) instructions for some time... But, we just noticed a few words in the Principles of Operations (I'm quoting from the STOC discussion): When the condition specified by the M3 field is not met (that is, store operation is not performed), it is model dependent whether any or all of the following occur for the second operand: (a) an access exception is recognized, (b) a PER storage-alteration event is recognized, (c) a PER zero-address-detection event is recognized, or (d) the change bit is set. Now - a rather common programming idiom is to store a result if a pointer is not NULL. So, it would seem that a comparision of a pointer to x'0' followed by a STOC would be a nice programming idiom. However, one of our recent tests (on a zPDT platform) blows up with this paradigm... getting an 0C4. Even though the condition in the STOC is not met and the store will not occur... The Principles of Operation also appear to be inconsistent, it makes this claim: For example, the following two instruction sequences are equivalent. STOCG 15,256(7),8 BC 7,SKIP STG 15,256(0,7) SKIP DS 0H But, according to the paragraph quoted above, the two sequences are not equivalent. The sequence on the right might not have the possibility of generating an access-exception, while the STOCG does have that possibility even though the store would not occur. I find these semantics a little baffling and wonder if that doesn't essentially make STOC/LOC pretty much unusable in all but the most restrictive situations? Thoughts/Opinions??? - Dave Rivers - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Usefullness (or not) of STOC/LOC instructions?
On Tue, 27 Nov 2012 11:19:25 -0500, Thomas David Rivers wrote: The Principles of Operation also appear to be inconsistent, it makes this claim: For example, the following two instruction sequences are equivalent. STOCG 15,256(7),8 BC 7,SKIP STG 15,256(0,7) SKIP DS 0H But, according to the paragraph quoted above, the two sequences are not equivalent. The sequence on the right might not have the possibility of generating an access-exception, while the STOCG does have that possibility even though the store would not occur. I find these semantics a little baffling and wonder if that doesn't essentially make STOC/LOC pretty much unusable in all but the most restrictive situations? Thoughts/Opinions??? Someone in high level design had a Good Idea. At a lower engineering level it became apparent that implementation was complex and had performance implications. The address generation/validation module could not know early of an intended STore operation, so address validation could not performed in parallel. They made a bad compromise. The side effects might even be more likely on high-end, highly parallel processors than on low-end models. But hardware designers should be extremely conservative about introducing model dependencies; it greatly aggravates the difficulty of software testing. Is LOC at similar risk for access exceptions? The old Motorola 6800 at each cycle presented an address on its bus, a R/W bit, and one more: VMA (Valid Memory Address), which meant, Don't do it!. The look-slightly-alike 6502 had no VMA bit; it made a (read?) memory access at each cycle whether it intended to use the result or not. I'm also reminded of old magnetic core memories where reads were intrinsically destructive; the memory controller had to perform a rewrite after each read. But some CPUs could intercept the process and perform or-to-storage, and-to-storage, and increment-storage operations in a single memory cycle rather than two. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Usefullness (or not) of STOC/LOC instructions?
Thomas David Rivers wrote: We've been using the STOC/LOC (STORE/LOAD ON CONDITION) instructions for some time... But, we just noticed a few words in the Principles of Operations (I'm quoting from the STOC discussion): When the condition specified by the M3 field is not met (that is, store operation is not performed), it is model dependent whether any or all of the following occur for the second operand: (a) an access exception is recognized, (b) a PER storage-alteration event is recognized, (c) a PER zero-address-detection event is recognized, or (d) the change bit is set. Now - a rather common programming idiom is to store a result if a pointer is not NULL. So, it would seem that a comparision of a pointer to x'0' followed by a STOC would be a nice programming idiom. However, one of our recent tests (on a zPDT platform) blows up with this paradigm... getting an 0C4. Even though the condition in the STOC is not met and the store will not occur... The Principles of Operation also appear to be inconsistent, it makes this claim: For example, the following two instruction sequences are equivalent. STOCG 15,256(7),8 BC 7,SKIP STG 15,256(0,7) SKIP DS 0H But, according to the paragraph quoted above, the two sequences are not equivalent. The sequence on the right might not have the possibility of generating an access-exception, while the STOCG does have that possibility even though the store would not occur. I find these semantics a little baffling and wonder if that doesn't essentially make STOC/LOC pretty much unusable in all but the most restrictive situations? Thoughts/Opinions??? - Dave Rivers - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com It seems likely someone or some group at IBM have a use for this, or it would not have been added to the architecture. The purpose of these instructions is to remove the branch, which may or may not be reliably predictable and may stall the pipeline. Load/store/whatever on condition instructions are common on other architectures. A version of conditional execution is fundamental to Itanium and is present in ARM. I believe Sparc also has conditional execution of some instructions. Although not suitable for the idiom you describe, there is certainly a wide range of situations where this might be useful. Regards, Henry -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Usefullness (or not) of STOC/LOC instructions?
On Tue, 27 Nov 2012 10:01:17 -0800, Henry Willard wrote: Thomas David Rivers wrote: When the condition specified by the M3 field is not met (that is, store operation is not performed), it is model dependent ... It seems likely someone or some group at IBM have a use for this, or it would not have been added to the architecture. ... But what plausible use do you envision that anyone or any group at IBM might have for the model dependent character? It requires that software developers test on every available and possible future system. Simply, it's irresponsible not to have made the behavior consistent across models. If it's going to fail on some models, it should be designed to fail likewise on all models. Perhaps with SIE? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
