I agree with the need to modernize the look and feel of the manual. It
still appears to be based in the 360 version, which was always used in
hardcopy, and could be easily paged through to find the instruction
(once you remembered which were decimal and which general so you looked
in the right chapter). The two column presentation is an anachronism in
a reference document that is, I suspect, rarely printed.
There already is a "How to use" section in appendix A. What I would
appreciate is more help with "When to use". To that extent grouping
instructions by function rather than alphabetically helps, so, for
example, all methods of moving memory into registers are introduced with
a general paragraph with links to the subgroups of different
instructions (loads, inserts, ...).
I would hope that, just as data in databases can be presented in various
ways, someone could come up with publishing techniques that would
present this reference data in a variety of ways depending on the needs
of the end user. For example, if I would like to drill down
alphabetically by mnemonic, instruction name, or opcode, each should be
available; Appendix A information should be optionally displayable when
I access the reference information for the instruction.
In an ideal world, the information would be packaged in a way that it
would make it relatively easy for the original poster in this thread to
create a front end that would transform it, with his own additions for
instructional purposes) into an appropriate document for a learner of
assembler language.
Gary Weinhold
Data Kinetics, Ltd.
On 2014-11-13 08:00, Binyamin Dissen wrote:
My opinion is that the reference should be a reference and not a how-to-use
guide (as would be used in programming classes).
I have no problem with a "How to write and assembler program" manual, but it
is outside the scope of the POPs.
On Thu, 13 Nov 2014 10:52:17 +0000 "Ward Able, Grant" <gwarda...@dtcc.com>
wrote:
:>I could not disagree more, Joey!
:>PRECISE yes, but it does not need to be concise. I have always believed that
it is too terse and could do with and upgrade. Mervyn's suggestions are a good
starting argument and I, for one, would really enjoy a much more modern POPS
manual, which has more verbose descriptions and examples.
:>
:>
:>
:>Regards - Grant.
:>Telephone Internal: 201496 (London)
:>Telephone External: +44 (0)207 650 1496
:>
:>
:>-----Original Message-----
:>From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Capps, Joey
:>Sent: 12 November 2014 22:15
:>To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
:>Subject: Re: Redesigning the Principles of Operation Manual
:>
:>Personally I don't think it's design was to save paper.
:>I think it was to 'be concise'.
:>And that is what I think it needs to be.
:>
:>As for reorganizing it into different chapters, that might be useful.
:>But we cannot afford to have it lose its concise nature.
:>
:>Joey
:>
:>
:>-----Original Message-----
:>From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Melvyn Maltz
:>Sent: Wednesday, November 12, 2014 4:04 PM
:>To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
:>Subject: Redesigning the Principles of Operation Manual
:>
:>One can see why the Principles of Operation manual (PoP) was designed in its
present format...to save paper.
:>
:>There is now no need to design this manual in a form that was suitable 30
years ago.
:>
:>Now that I've restarted teaching Assembler I realise that the PoP neither
serves the professional learning new instructions or techniques nor the student
learning for the first time.
:>
:>The suggestions below have been compiled by myself and contacts and are not
in any priority order. I offer these in order to stimulate discussion. I know IBM
monitor this forum as I see names that I know.
:>IBM can join in as well.
:>
:>1) Instruction descriptions
:> Every instruction must be individually described. No more bunching.
:>
:>2) Two Manuals
:> ---PoP1 describes formats and techniques
:> ---PoP2 describes instructions and examples
:>
:> Hyperlinks to similar instructions and examples.
:>
:>3) Classification
:> The current classification is inadequate, ie. CVD isn't a decimal
instruction...there are many others.
:>
:> If you have to classify, then here is a suggestion...
:> 1) Boolean...AND/OR/XOR
:> 2) Branch....BRANCH and PROGRAM
:> 3) Compare...COMPARE and TEST
:> a) Binary
:> b) Floating point
:> c) Decimal
:> 4) Conversion...CONVERT/TRANSLATE/UNPACK/EDIT/PACK
:> a) Character/Binary/Decimal
:> b) Floating point
:> 5) Cryptography...COMPRESSION/CIPHER/PERFORM
:> 6) I/O...CHANNEL
:> 7) Maths
:> a) Binary
:> b) Floating point
:> c) Decimal
:> 8) Move...PAGE/MOVE/LOAD/STORE/INSERT
:> 9) Trace..TRACE
:> 10) Transaction..TRANSACTION
:> 11) Trap...TRAP
:> 12) Others
:>
:>4) An iPoP app that can display an individual instruction with multiple
cross-references for local use.
:>
:>5) A Web app to do the same, but has the advantage of being international and
collective.
:> "People who looked up LG also looked up LLGF"
:>
:>Let the discourse begin.
:>DTCC DISCLAIMER: This email and any files transmitted with it are
confidential and intended solely for the use of the individual or entity to whom
they are addressed. If you have received this email in error, please notify us
immediately and delete the email and any attachments from your system. The
recipient should check this email and any attachments for the presence of viruses.
The company accepts no liability for any damage caused by any virus transmitted
by this email.
--
Binyamin Dissen <bdis...@dissensoftware.com>
http://www.dissensoftware.com
Director, Dissen Software, Bar & Grill - Israel
Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.
I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.
