Just for historical purposes, back in the days of Alan's great grandfather, S/360's early days, there was a "byte oriented operand feature" that could be purchased if forcing alignment would cause you grief. Without it, a violation of boundary alignment caused a program check.
Regards, Richard Schuh > -----Original Message----- > From: The IBM z/VM Operating System > [mailto:ib...@listserv.uark.edu] On Behalf Of Alan Altmark > Sent: Thursday, January 07, 2010 9:30 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Fixed length field alignment degradation > > On Thursday, 01/07/2010 at 02:58 EST, Brian Nielsen > <bniel...@sco.idaho.gov> wrote: > > You might try this: > > > > http://portal.acm.org/ft_gateway.cfm?id=29651&type=pdf > > > > The above, "Mimic: A Fast System/370 Simulator", is also cited in > > patent > > Not everyone has access to ACM's digital library, but the > only relevant point in the paper (I think) was that alignment > was a factor in the number of RISC operations required to > access an operand. > > The warning about alignment-dependent performance has been in > the book since time immemorial and the assembler has been > issuing warnings about it since Day 2. (I remember my > great-grandfather mentioning it to his pet dinosaur one > day....) Read the section in Chapter 5 on "Storage-Operand > Consistency" for some additional details. > > But remember that the Principles of Operations describes > *architecture*, not implementation. If you obey the > alignment rules, then the machine will provide the "block > consistency" it describes. For example: ST R1,R1VALUE. If > R1VALUE is on a fullword (S/390) or doubleword > (z/Architecture) boundary, the machine will ensure that all > relevant bytes in R1 will appear to have been stored as a > single unit. Likewise for fetch operations. > > The PoP does NOT say what happens if R1VALUE is NOT on an > integral boundary. The results are 'unspecified' and cannot > be depended upon. > > Alan Altmark > z/VM Development > IBM Endicott >
