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
