I disagree with many of your points, somewhere between mildly and 
vehemently.  :-)  One thing that should be kept uppermost in mind is that 
Principles of Operation is a description of an architecture, not an 
implementation.  As such, its descriptions are both complete and 
repetitive.  This may sometimes be annoying but cannot be eliminated.  If 
PrincOps were to be rewritten to eliminate a lot of this, it would cease 
to fulfill its primary function, and would simply necessitate the creation 
of something to take its place, namely a new Principles of Operation.

To address some of your points specifically:

- No more bunching:  Perhaps a reasonable suggestion.  Bear in mind, 
though, that it would increase the repetitive nature of the document. 
Also, the need to ensure that similar instructions were documented 
similarly as much as possible would necessitate extensive reorganization 
of the "internals" of the document so that similar descriptions were 
essentially invoked as subroutines, in order to ensure that a change to, 
say, ASI is exactly reflected in AGSI, AGFI, AFI, etc.  One of the 
hallmarks of PrincOps is a slavish devotion to consistency; do not break 
that.

- Two manuals:  A description of techniques does not belong in PrincOps. 
Suggested techniques, whether for performance or maintainability, belong 
in a new document, perhaps one that is implementation-specific.  Many such 
documents have been written, although perhaps not by IBM and perhaps not 
kept current.  Breaking out formats (numeric representation?  Instruction 
formats?  Something else?) doesn't seem to make sense, other than perhaps 
to make PrincOps shorter.  But in today's world, the size of the document 
hardly matters.  One book is more manageable than two, in my mind.  As for 
hyperlinks, PrincOps is already extensively hyperlinked, at least in the 
PDF format.

- Classification:  To me, instructions from chapters 10 (control 
instructions) and 14 (I/O instruction) do not belong in chapter 7 (general 
instructions).  Other than that, I wouldn't care much if you were to lump 
together everything in chapters 7, 8, 9, 18, 19, and 20 into one big 
chapter on general, decimal, and hexadecimal instructions.  Typically I 
find my instruction by clicking on the desired chapter link in the table 
of contents and then clicking on the instruction link in the 
chapter-specific table of contents.  If I somehow end up in the wrong 
chapter, I just go to Appendix B and find it there with a quick search. 
The existing classification never gave me too much trouble, but if others 
find it to be lacking, perhaps a reorganization would be in order. 
However, if the intent of reclassification is to make it easier for the 
reader to *learn* the architecture textbook-style (Boolean instructions, 
branching instructions, etc.), then I would suggest that the reader is 
misusing the document.

- An iPop app:  For me, the usefulness would be limited.  I downloaded 
PrincOps to my laptop, so I can't imagine where I be that I would be 
coding and not have PrincOps with me.  I do happen to have it on my phone, 
where I have in fact wished that it was easier to navigate, but that may 
be due to lack of function of the app I use rather than a shortcoming of 
PrincOps itself.  I've only used it on my phone to look up answers to idle 
questions that have occurred to me, but certainly not for any serious 
reading.

- A web app:  I would have little use for it, but I don't claim that 
others wouldn't.

In short, some of your suggestions may indicate the need for a new book, 
rather than a reworking of Principles of Operation to serve a new purpose. 
 But as far as wholesale changes, I don't see the need for it.

- mb

Reply via email to