I remember the developer and I adding up machine cycles for
alternative routines for the IBM IUO RED editor. That's why
it out performed all the full screen editors of its day.
BTW, that 3360-30 probably only had 65k of memory (max) and
as a RAS programmer we had to write 4k modules!
Les
Jim Bohnsack wrote:
Also back in the "olden days", we did a lot of "bit twiddling" to
squeeze a little more performance out of the then slow processors. I
remember doing some performance studies or analyses and found that a
S360-30, many of which I supported, was about an 18 kip machine. That's
not a typo. 18,000 instructions per second. Now, who cares, at least
for commercial type of work.
Jim
On 1/8/2010 11:33 AM, Schuh, Richard wrote:
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 vio=
lation of boundary alignment caused a program check.=20
Regards,=20
Richard Schuh=20
=20
-----Original Message-----
From: The IBM z/VM Operating System=20
[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
=20
On Thursday, 01/07/2010 at 02:58 EST, Brian Nielsen=20
<bniel...@sco.idaho.gov> wrote:
You might try this:
=20
http://portal.acm.org/ft_gateway.cfm?id=3D29651&type=3Dpdf
=20
The above, "Mimic: A Fast System/370 Simulator", is also cited in=20
patent
=20
Not everyone has access to ACM's digital library, but the=20
only relevant point in the paper (I think) was that alignment=20
was a factor in the number of RISC operations required to=20
access an operand.
=20
The warning about alignment-dependent performance has been in=20
the book since time immemorial and the assembler has been=20
issuing warnings about it since Day 2. (I remember my=20
great-grandfather mentioning it to his pet dinosaur one=20
day....) Read the section in Chapter 5 on "Storage-Operand=20
Consistency" for some additional details.
=20
But remember that the Principles of Operations describes=20
*architecture*, not implementation. If you obey the=20
alignment rules, then the machine will provide the "block=20
consistency" it describes. For example: ST R1,R1VALUE. If=20
R1VALUE is on a fullword (S/390) or doubleword
(z/Architecture) boundary, the machine will ensure that all=20
relevant bytes in R1 will appear to have been stored as a=20
single unit. Likewise for fetch operations.
=20
The PoP does NOT say what happens if R1VALUE is NOT on an=20
integral boundary. The results are 'unspecified' and cannot=20
be depended upon.
=20
Alan Altmark
z/VM Development
IBM Endicott
=
.
