It is my understanding - from conversations with numerous IBM engineers and retirees - that ALDs are 'as-built' documents related to a particular machine and were indeed kept with the machine at the customer site. Otherwise, the poor CE would have to haul around a rack of ALDs for each machine being serviced! It's easy to underestimate the physical bulk of these documents when printed and in binders. -- Ian
On Tue, Jul 12, 2016 at 7:30 AM, Paul Koning <paulkon...@comcast.net> wrote: > > > On Jul 12, 2016, at 6:00 AM, Paul Birkel <pbir...@gmail.com> wrote: > > > > Principles of Operation, I believe. Example: > > > > > http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/360/princOps/A22-6821-0 > > _360PrincOps.pdf > > > > -----Original Message----- > > From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Curious > > Marc > > Sent: Tuesday, July 12, 2016 5:04 AM > > To: General Discussion: On-Topic and Off-Topic Posts > > Subject: Re: IBM 360/30 in verilog > > > > What's a POP? As long as it emulates all the registers connected to light > > and switches that might do for me, but I was assuming these would very > > specific to the CPU detailed innards. > > Marc > > > >> On Jul 12, 2016, at 5:14 PM, Dave Wade <dave.g4...@gmail.com> wrote: > >> > >> It actually might be easier to produce a generic S/360 clone in FPGA > >> using the POP rather than individual ALU's. > >> Having built a very simple CPU (in VHDL not Verilog) and planning to > >> start on a more complex (Ferranti Pegasus) Of course it wouldn't be > >> cycle accurate, but perhaps that wouldn't be important. > > It depends on what you're trying to emulate. If you want an instruction > level simulator, sort of a SIMH in silicon, then going from the POP or > analogous documents (processor reference manuals, computer family > architecture manuals such as DEC published for the PDP-11 and VAX) will do > nicely. Such an approach is not going to show you the peculiarities of a > particular implementation, details too deep for the sort of documentation > you're using, let alone implementation bugs. > > By way of analogy, if you build a CDC 6000 emulation using that approach, > it won't do the "zero written to memory at PC at deadstart time" property, > because that is nowhere documented or explained in any printed document I > have ever seen. But it's part of the unwritten lore of that machine. If > you build a gate level model from the engineering drawings, you can see it > clearly (and you can readily discover its cause). > > Building an accurate model from a POP requires a great deal of > intellectual effort, to understand all the critical details sufficiently to > model them in behavioral models. You can perhaps lift them from existing > software emulators (SIMH, Hercules) and get "close enough". Debugging > would be hard, especially if the documentation isn't quite accurate enough > to allow all the diagnostics to pass. > > A gate level model constructed from the engineering drawings is more > cumbersome in certain ways, almost certainly less efficient in FPGA > resources -- but it's much more a mechanical process. If the drawings are > accurate (that's an "if" indeed), then the model will be accurate. The > diagnostics should pass without major effort, serving more as confirmation > tools than as debugging aids. > > paul > > > -- Ian S. King, MSIS, MSCS, Ph.D. Candidate The Information School <http://ischool.uw.edu> Dissertation: "Why the Conversation Mattered: Constructing a Sociotechnical Narrative Through a Design Lens Archivist, Voices From the Rwanda Tribunal <http://tribunalvoices.org> Value Sensitive Design Research Lab <http://vsdesign.org> University of Washington There is an old Vulcan saying: "Only Nixon could go to China."
