Re: Charles Murray "The Plan" ends poverty

On Mon, 2 Apr 2007, Islander wrote:

Alvin E. Toda wrote:

On Sun, 1 Apr 2007, Islander wrote:

Alvin E. Toda wrote:

On Sat, 31 Mar 2007, Islander wrote:

Alvin E. Toda wrote:

On Fri, 30 Mar 2007, Islander wrote:

Alvin E. Toda wrote:

On Thu, 29 Mar 2007, Islander wrote:

Alvin E. Toda wrote:

On Thu, 29 Mar 2007, Islander wrote:




I had forgotten the sequence of acquisitions. According to Wikipedia, this is how it happened: "Apollo was acquired by Hewlett-Packard in 1989 for US $476 million, and gradually closed down over the period 1990-1997. DEC was acquired by Compaq in June 1998, which subsequently merged with Hewlett-Packard in May 2002."

So, HP eventually ate everyone who came out of the workstation marketplace of the '80s. I think that they are still a good company, but it is getting to be very difficult to compete in this market.

A few historical notes:

I did my Master's thesis on a PDP-1 with a graphics display in 1964. They were WAY ahead of their time.

Dan Dobberpuhl who designed the ALPHA processor for DEC worked for me in the early '70s. He is one heck of a smart guy!

In 1980, five major research universities sent a proposal to DEC with the behind-the-scenes encouragement and funding from DARPA. The proposal basically predicted the emergence of networked personal computers and described the role that the universities would play in developing software for that environment. Literally hundreds of VAX750s in 5-pac configurations were sold at deep discount to universities across the country and played a major role in the development of a wide spectrum of software applications.






Thanx for the nostalgic trip. I was using main frame and key punch machines as a physics and astronomy grad student before the PDPs came out. There weren't dumb terminals either. All programs on the main frame were run in batch. I could never understand why anyone would want to be a programmer even after interning a summer where I "green sheeted" some stuff to process some data. You had to wait for data entry to process your hand-written green sheets before you could get any results. This was all done in Fortran-- BTW IIRC Backus, the inventor, has passed away at 82.

I remember reading about the Alpha chip. Your colleague is a fantastic designer. IIRC it can also execute the PDP instructions as a subset. I participated in another company with the reverse engineering of the PDP chip that failed. Problem is that it's kind of kludgy with some asynchronous logic designed to switch on both edges of the clock. This kind of logic is usually some fix for an odd problem that hardly ever occurs. And I converted the logic in those portions clock edge for clock edge. Otherwise, we followed the standard conversion procedure for synchornous logic.

I was more concerned about the synchronization of the data path and the control portion that in the original PDPs were separated and had a special circuit to synchronize them at after reset and power up. The guys who did the control broke that logic and felt that the data path should just respond to the micro code it was issued. I was worried that it could slip synchronozation after reset by a cycle or half-cycle after reset. Even did an alternate simulation to show slight differences appearing after reset. Other members of the team accused me of being alarmist-- I am. Don't like to take gambles-- so I bite my tongue. In the end we didn't have enough patterns to validate all the logic, or even a test board to run some programs for debugging. But I understand that the chip did show some life, so it was a good first effort. We probably should have simulated the design in an environment with some code, but if we had tried to do that at that time, we would have never completed the project. But it's not that much-- just one or two instructions. That might have been enough to bring out a problem that we overlooked.


I never got into General Purpose (GP) design. For the first decade of my career I was building special purpose machines -- very high performance, highly parallel machines used primarily to attack foreign cyphers. It was a great place to learn. We built a 10 MHz machine in the mid 60s that included multiple pipelined processing units. All built out of hybrid thin film circuits. Way ahead of the SoA. The special purpose machine had a GP attached to it to feed it data and to post process the results. A colleague wrote a fault detection and isolation program on the GP which allowed us to quickly isolate faulty hardware in the SP machine. This was well before that approach saw the light of day in the commercial world.




That's very sophisticated. I guess even more than pipelined, the processing units could have been interconnected in many topologies-- a little like those hardware implementations of fast fourier transforms that I've heard about? When the processing needs to be done in real time, then no GP can keep up. The data flows into the circuit on one edge and the solution flows out on another edge. The neatest thing about a data path is how they weave the register stack and other elements together. I had been familiar in the actual silicon layout so that I was of some use in converting that logic. Sometimes the schematic of elements of a data path aren't obvious as to what logic is being accomplished because the schematic is mainly used to do hand layout of the design.

The functionality may be checked at a more abstract level. So at one time "transistor-level" simulators of datapaths were popular. You only had the time to validate a few instructions on the chip in terms of closeness to how the silicon would function. It was pretty close to a Spice simulation, but very inaccurate in comparison.




The seminal paper on pipelining was published by Wayne Cotton in the '60s. He pissed off a bunch of people at NSA who had been using pipelining for some time. They called it escalator logic.

The approach was rejuvenated in the early '80s as researchers attempted to build very high performance machines using VLSI chips. H.T. Kung at CMU did a lot of work in this area before abandoning the approach in favor of programmable structures. He felt that he had to invest too much time and effort in the hardware for it to pay off.




Kung had the right idea. The early processes had one or two layers of metal for routing. Which only left one layer for routing after dedicating the other two layers for power and ground. Polysilicon could be used for routing on short runs. We see with hybrid circuits, that about 6 layers of routing will result in a very dense hybrid with short lengths of routing-- including two layers for power and ground. Programmable hardware only became feasible when there were enough layers to connect the devices. In older designs, without extensive partitianing and planning, most designs might not have been routed. And even then, poor planning and late design changed caused havoc: you don't want to go cross town and then back, just to go next doof.



The truly creative designs minimized wiring by communicating with nearest neighbors. This was the really beautiful designs that came out of some work done at that time. It required an understanding of both the function to be implemented and the underlying technology. Most designers separate the two and focus on just the logic design.

I designed two chips that had this property. The first was the text search machine which consisted of a set of parallel registers with logic between them to implement the boolean search criteria. As data shifted through one register, the partial results advanced through a parallel register. The entire structure involved only neighbor to neighbor connections.

The second chip was a correlator which involved a two dimensional structure in which partial correlation functions passed across the structure to emerge at the opposite side. Once again, it only involved neighbor to neighbor connections.

There was some very nice work done at Cal Tech involving self-timed logic which used this approach coupled with logic to eliminate the need to distribute synchronization signals. It was based on earlier theory developed by Ivan Sutherland.


I came up with a novel design for a text search machine based on boolean search criteria in the late '60s, but did not patent it or publish the approach. It was reinvented at Univ Utah, almost exactly as I had envisioned it in the '80s.

One thing that I didn't mention about Dan Dobberpuhl was that he developed a circuit simulator while a 2nd Lt on duty at NSA in the late '60s. It was really quite an innovation at the time. I rewrote it in fortran using dynamic memory allocation and simple interfaces for including new models. I also designed software to extract the parasitics from the layout for direct input to the circuit simulator. That was one of my earliest publications. The programs were used at NSA for over 20 years.




This is great and wonderful work. I guess Dobberpuhl's simulator is The Spice simulator? I needed to model a problem of sub-harmonic generation from saturation of magnetic devices once and found that it wouldn't accept this kind of model (bascially a hysteresis loop). The mathematician in our department couldn't work with the equations either because they resulted in a singularity. He could not demostrate the subharmonic in a quantitative way. But we set up a laboratory model and just took a whole bunch of measurements and basically used a semiempirical model to project a solution into the singularity for a variety of configurations. It's a kind of engineering solution that old-timers remember.

It's also one that didn't come out of a computer. Seems to be basically hard to simulate what happens during an abrupt change in your model. A solution to the phenomena does exist and is predictable even if the mathmatical model says it does not exist and is unpredictable in theory.... That kind of resonance can destroy systems. So it needs to be understood well even if we only have an accurate empirical understanding of it's behavior.



No, Dan's work in the late '60s predated SPICE which was done in the early '70s IIRC and he implemented a very clever variable time step integration approach, something that the first version of SPICE did not include. It would basically dynamically adapt the time step to accommodate fast transitions and then gradually expand the time step again when things settled down. Very nice numerical integration.

Dan also had great engineering intuition. Much of the circuit design that he did at the time was done on a slide rule.

I used a semiempirical model in a circuit simulator that I wrote in '61. I basically digitized the transfer characteristics of a transistor and then simply solved the node equations. I implemented this on a Philco Transac 1000 computer, the very first transistorized digital computer. There were no compilers or assemblers and I coded it in octal. There was no secondary storage and no matter how I squeezed it, I couldn't fit the program and data into the 4K of core memory. I finally resorted to using punched paper tape as secondary storage with a massive pile of tape on the floor between the punch and the reader. I'm told that the computer is now in the Smithsonian. I still have one of the coding sheets in my collection of memorabilia.



His feature has been in comercial and proprietary versions of Spice for many years. It is often necessary to change the time step automatically in the simulation when there are rapid changes in the solution in order to get decent convergence on a solution.

I didn't realize people coded those paper tape computers in Octal. Did see one when I worked for the Navy. It is a major problem of the paper tape if the holes are loose or slightly off. And I am reminded why, at the time, I wanted to stay far away from these machines.


I don't blame you! The tape readers were reliable enough, but there was no opportunity to edit a mistake except to key in a change from the console. The tape had to be perfect. It is a good thing that memory was limited in those days or the size of programs would have been limited by how long one could type without error. Punched cards were a definite improvement.


BTW I'm reminded of something that we used in the late 60s-early seventy time frame called "SNAP". Thought that it was a proprietary version of SPICE, but could it be related to Dan's early simulator?

No. IIRC, there was an early network analysis program called SNAP, but it was not Dan's. I rewrote Dan's program in 1969, coupling it with features of another in-house simulator. This was called MOSTRAN and as far as I know it was never used outside NSA.

This is interesting history. I'm sure someone will write about it someday. But I guess the general interest will be nil-- outside of program developers and users. It's too "nerdy" a topic.
.

Quantcast