Tony Harminc wrote: > On 28 November 2012 13:54, Alan Altmark <[email protected]> wrote: > > 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. > > 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 [email protected] with the message: INFO IBM-MAIN
