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 [email protected] with the message: INFO IBM-MAIN
