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 •
[email protected] • 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:[email protected]]
> On Behalf Of Alan Altmark
> Sent: Wednesday, November 28, 2012 12:54 PM
> To: [email protected]
> Subject: Re: Usefullness (or not) of STOC/LOC instructions?
>
> On Tue, 27 Nov 2012 14:55:16 -0600, Paul Gilmartin
> <[email protected]> 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 [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
