• Please review our updated Terms and Rules here

PUniBone: A PDP-11 processor card test bed

Now that is a very nice test tool! Normally I'm debugging the boards in the actual machine, but this could speed up the fault finding process a lot. Any plans to make the hardware available as well?

Regards, Roland
 
Joerg has very kindly hosted (on retrocmp.com) my short article about a PDP-11 related project I am working on.
It is a derivative of the UniBone, used for testing processor cards from the KD11 family (/04 and /34A currently).
www.retrocmp.com/stories/punibone-pdp-11-processor-test-bed
On that page, you write "My ultimate goal is to create a follow-on KD11 CPU card using technology that might have been available in the mid to late 1980s had the transition to LSI / microprocessors not occurred."

It would be interesting to see what could have happened if DEC went with Am29xx-family components as an evolution of the 74x181 based ALUs. That is what Data General did with the Nova 4 / Eclipse S/140 (essentially the same hardware, just different microcode). As we know, DEC went with the J11 microprocessor and Harris Semiconductor / Intersil. Once there was a large pile of J11 CPU chips (of varying degrees of functionality) on hand, there was no incentive to do anything further wirh discrete CPUs.

It is interesting that the PDP-11 group used a microprocessor to extend their product line at the high end, while the VAX group used microprocessors to make cost-reduced midrange and low-end systems.Perhaps the VAX teams took the "internal competition" thing too far - it should have been obvious well before the VAX 9000 shipped that the NVAX was going to be able to outperform the 9000 by any reasonable metric.I wonder if it was ego / pride (within the group and also from Ken) that kept the 9000 project going long after it should have been cancelled. Of course, that group likely felt they had something to prove, having the 86x0 (which missed its original performance target badly) and Jupiter as their previous projects.
 
On that page, you write "My ultimate goal is to create a follow-on KD11 CPU card using technology that might have been available in the mid to late 1980s had the transition to LSI / microprocessors not occurred."

It would be interesting to see what could have happened if DEC went with Am29xx-family components as an evolution of the 74x181 based ALUs. That is what Data General did with the Nova 4 / Eclipse S/140 (essentially the same hardware, just different microcode). As we know, DEC went with the J11 microprocessor and Harris Semiconductor / Intersil. Once there was a large pile of J11 CPU chips (of varying degrees of functionality) on hand, there was no incentive to do anything further with discrete CPUs.

Well, there is the CMU-11. Bit sliced, but using Intel 3000 components; look up "Using LSI processor bit-slices to build a PDP-11.pdf".
 
On that page, you write "My ultimate goal is to create a follow-on KD11 CPU card using technology that might have been available in the mid to late 1980s had the transition to LSI / microprocessors not occurred."

It would be interesting to see what could have happened if DEC went with Am29xx-family components as an evolution of the 74x181 based ALUs. That is what Data General did with the Nova 4 / Eclipse S/140 (essentially the same hardware, just different microcode). As we know, DEC went with the J11 microprocessor and Harris Semiconductor / Intersil. Once there was a large pile of J11 CPU chips (of varying degrees of functionality) on hand, there was no incentive to do anything further wirh discrete CPUs.

It is interesting that the PDP-11 group used a microprocessor to extend their product line at the high end, while the VAX group used microprocessors to make cost-reduced midrange and low-end systems.Perhaps the VAX teams took the "internal competition" thing too far - it should have been obvious well before the VAX 9000 shipped that the NVAX was going to be able to outperform the 9000 by any reasonable metric.I wonder if it was ego / pride (within the group and also from Ken) that kept the 9000 project going long after it should have been cancelled. Of course, that group likely felt they had something to prove, having the 86x0 (which missed its original performance target badly) and Jupiter as their previous projects.

Well, DEC did things with the Am29xx-family, just no complete PDP-11 CPU. Which, considering they got the J11, makes sense.

The PDP-11 line also started with the microprocessor at the low end. So it really followed the same curve as the VAX later did. The LSI-11 was really the lowest end you could imagine. Then you had the T-11 and then F-11, at which point it started becoming interesting for more proper systems. And finally the J-11 which made any other implementation unattractive.

With the VAX, as you say, the 9000 was an expensive dead end, which probably should have been cancelled. The 86x0 was seriously delayed, but was in the end still rather successful. So I don't think it's so useful to bring that machine into the picture here (not sure they really felt that the 86x0 was that much of a failure). But my understanding was than Ken really wanted the 9000 to play with the big boys.
 
Any plans to make the hardware available as well?

Regards, Roland

No plans currently. Much more testing is needed. And I would like to get microcode stepping working if not a complete emulation of the M7859 console / diagnostics interface.

Someone already asked if the 11/05 could be supported . But that two board set requires a unique row CDEF interconnect, like the 11/34A, so would have to be a different PCB. Although you could contemplate a 4 slot PCB that supported all three: 11/04 /05 /34A. As mentioned in the article a 6-slot PCB for the 11/44 is in progress.
 
Well, DEC did things with the Am29xx-family, just no complete PDP-11 CPU. Which, considering they got the J11, makes sense.
Yes. I'm just brainstorming what might have happened had DEC not built the J11.

The fast FPU (M8188) for the 11/24 and the 11/44 (M7093) both had forests of Am29xx on-board. The M8188 is more of an accomplishment, IMHO, because it packs the FPU onto a quad board (suitable for Unibus or Q-bus) along with the microcode. Looking at the M7093, I don't see any place for the microcode - I suspect it lives in the CPU with the CPU microcode.

The 11/44 CIS (M7091/M7092) also used Am29xx parts for its ALU. Although the CIS was more about complexity than raw speed, so it had a narrower datapath than the FPU.

The fact that DEC called the 11/44 CPU the KD11-Z seems to imply they thought "Ok, we're done here". Although of course there were other Kx11 processors.

The PDP-11 line also started with the microprocessor at the low end. So it really followed the same curve as the VAX later did. The LSI-11 was really the lowest end you could imagine. Then you had the T-11 and then F-11, at which point it started becoming interesting for more proper systems. And finally the J-11 which made any other implementation unattractive.
It is interesting that the LSI-11 came from "outside" (Western Digital), although its history is unknown to me and apparently not recorded anywhere. If it was done solely as a contract job for DEC, it seems unlikely that we would have had the multiple variants (Alpha Micro, Pascal Microengine, various other embedded instruction sets). The F11 and T11 seem to have been pure DEC, with the J11 returning to a partnership with an outside supplier (Harris Semiconductor/Intersil), presumably because of their success with the 6100 family of PDP-8 microprocessors. As has been extensively documented (for example here and here), this was a project that could have gone better.

Data General also experimented with microprocessors at the low end (microNOVA), but went back to Am29xx parts for the Nova 4 / Eclipse S/140.

With the VAX, as you say, the 9000 was an expensive dead end, which probably should have been cancelled. The 86x0 was seriously delayed, but was in the end still rather successful. So I don't think it's so useful to bring that machine into the picture here (not sure they really felt that the 86x0 was that much of a failure). But my understanding was than Ken really wanted the 9000 to play with the big boys.
Remember, I LIKE the 86x0, having had 2 of them in production use back in the day. Like the J11 did for the complete PDP-11 product line, the 86x0 (originally 79x) was a fitting capstone to the "Classic VAX" implementation. However, the 8600 missed its design target badly and the decision was made to push it out the door rather than fixing it first. Which is probably the same decision I would have made, though I would have pressed for them to be released as "early adopter" units with a commitment to meet the original spec via in-cabinet upgrade when it became available.

The fact that the 8600 -> 8650 upgrade only replaced 2 boards in the entire system shows how close they came to getting it right.

However, both the difficult genesis of the 86x0 and it being later than planned meant that there was no "mid-life kicker" - the 8650 came out 12 months after the 8600 and there was little to no interest inside DEC for a hypothetical 8670 machine - instead, 2 months after the 8650 the world got the 8800, which was slightly slower than the 8650 as a uniprocessor, but since it was a 2-way SMP system, it was faster overall in many environments. Of course, we lost both the Unibus and the Massbus on the 8800, instead getting the loathed BI bus and the start of DEC's attempt to rein in the 3rd-party controller market.
 
Yes. I'm just brainstorming what might have happened had DEC not built the J11.
Ok. That's an interesting starting point. Agreed.
The fast FPU (M8188) for the 11/24 and the 11/44 (M7093) both had forests of Am29xx on-board. The M8188 is more of an accomplishment, IMHO, because it packs the FPU onto a quad board (suitable for Unibus or Q-bus) along with the microcode. Looking at the M7093, I don't see any place for the microcode - I suspect it lives in the CPU with the CPU microcode.

The 11/44 CIS (M7091/M7092) also used Am29xx parts for its ALU. Although the CIS was more about complexity than raw speed, so it had a narrower datapath than the FPU.

The fact that DEC called the 11/44 CPU the KD11-Z seems to imply they thought "Ok, we're done here". Although of course there were other Kx11 processors.
Right. That -Z suffix always intrigued me. And obviously, it also was the last reimplementation of the PDP-11 without using a microprocessor.
I assume they started seeing that that the microprocessor was the path to the future, and the 11/44 was just at a time when it wasn't yet there, but another two years, and it would be.
It is interesting that the LSI-11 came from "outside" (Western Digital), although its history is unknown to me and apparently not recorded anywhere. If it was done solely as a contract job for DEC, it seems unlikely that we would have had the multiple variants (Alpha Micro, Pascal Microengine, various other embedded instruction sets). The F11 and T11 seem to have been pure DEC, with the J11 returning to a partnership with an outside supplier (Harris Semiconductor/Intersil), presumably because of their success with the 6100 family of PDP-8 microprocessors. As has been extensively documented (for example here and here), this was a project that could have gone better.
Yeah. I would also assume that the relative success in their previous collaborations was one reason. Another was that they were probably a bit tied up with trying to get the VAX on a chip, so in order to make the PDP-11 happen they were more or less forced to find some external company that they could collaborate with. The VAX was a higher value and importance, so it would take priority when it came to using internal resources.
Data General also experimented with microprocessors at the low end (microNOVA), but went back to Am29xx parts for the Nova 4 / Eclipse S/140.
I think it was partly because DG didn't really have enough resources to go with developing a microprocessor. I bet they would have loved to do it.
Remember, I LIKE the 86x0, having had 2 of them in production use back in the day. Like the J11 did for the complete PDP-11 product line, the 86x0 (originally 79x) was a fitting capstone to the "Classic VAX" implementation. However, the 8600 missed its design target badly and the decision was made to push it out the door rather than fixing it first. Which is probably the same decision I would have made, though I would have pressed for them to be released as "early adopter" units with a commitment to meet the original spec via in-cabinet upgrade when it became available.

The fact that the 8600 -> 8650 upgrade only replaced 2 boards in the entire system shows how close they came to getting it right.

However, both the difficult genesis of the 86x0 and it being later than planned meant that there was no "mid-life kicker" - the 8650 came out 12 months after the 8600 and there was little to no interest inside DEC for a hypothetical 8670 machine - instead, 2 months after the 8650 the world got the 8800, which was slightly slower than the 8650 as a uniprocessor, but since it was a 2-way SMP system, it was faster overall in many environments. Of course, we lost both the Unibus and the Massbus on the 8800, instead getting the loathed BI bus and the start of DEC's attempt to rein in the 3rd-party controller market.
All true, and I agree with it.

I think the interesting discussions would be more about the 9000. The 86x0, while delayed, and initially underperforming was still successful. The big reason no 8670 came about was really that DEC had started to want to lock down the buses, and the 86x0 just didn't fit in that scheme. The BI bus obviously became like a mantra after the 8600. So the 8650 was allowed to be done, since the effort was rather small (as you observe), but by then DEC was transforming into a company that really wasn't that interested in being an engineering company anymore, but which wanted to be IBM. And in that picture, something like Unibus, Massbus and SBI just was not what they wanted.

The 9000, when it came out, was only a few months ahead of the NVAX. And the first iteration of the 9000 was not as fast as the revised one, if I remember right. And considering the size and price of it, it should have been obvious that they were only ever going to sell few of them. And microprocessors were increasing in performance so fast it was only a question of time before they would catch up and surpass.

But I really do look at the PDP-11 and VAX going through the same evolution from discrete implementations to microprocessors, starting with at the low performance side, and moving up. But while the PDP-11 stopped the discrete variants with the 11/44, which relatively speaking was about mid-life of the PDP-11, the 9000 came a bit later in the VAX curve. Which again suggests that it should probably not have been done.

To make another comparison between the PDP-11 and the VAX. The 86x0 was in some sense similar to the 11/60 on the PDP-11 side. It had issues, were late, and never realized its full potential. And came about the same time through the curve of the product. Admittedly, the 11/60 was in the end much less successful than the 86x0. Maybe just because it became much more crippled compared to the high end PDP-11s than the 86x0, which was closed to bleeding edge in performance.
 
That -Z suffix always intrigued me. And obviously, it also was the last reimplementation of the PDP-11 without using a microprocessor.
I assume they started seeing that that the microprocessor was the path to the future, and the 11/44 was just at a time when it wasn't yet there, but another two years, and it would be.
They needed to get something out there that fit in a corporate cabinet, had decent performance, and was reasonably inexpensive. They were still selling 11/70 systems although they didn't particularly want to by that point (having done the DECdatasystem 570 because PDP-11 was a dirty word in some parts of the company and user base). The 11/34A didn't have the memory expandability and the 11/24 was stretched to the limit, performance-wise.

Another was that they were probably a bit tied up with trying to get the VAX on a chip, so in order to make the PDP-11 happen they were more or less forced to find some external company that they could collaborate with. The VAX was a higher value and importance, so it would take priority when it came to using internal resources.
I expect there was some internal horse-trading of the form "We'll let you do the design work for the J11 if somebody else does the fab work, if you let us use your FPA design".

I think it was partly because DG didn't really have enough resources to go with developing a microprocessor. I bet they would have loved to do it.
Although I was well "out of the loop" by the time the S/140 came along, I was surprised because the earlier Eclipsen were all '181-based and shared a mostly-compatible WCS implementation. I expect that the S/140 either didn't have a WCS option or it wasn't even "culturally compatible" with earlier models. But as I mention below, WCS was always a niche product.

DG was more interested in chasing the desktop/deskside segment at one end (MPT/100 and MP/100 originally), and the "big box" at the other end (like the C/330 and M/600). They seemed perfectly happy to continue to sell the existing midrange with only secondary improvements like semiconductor memory and later the ALM communication chassis instead of serial ports in the processor chassis.

That did give them time to develop AOS which became the foundation for AOS/VS on the MV/8000 family machines. The MV/8000 series was a stopgap that eventually ended up carrying the company over until they could switch to Unix-derived systems.

I think the interesting discussions would be more about the 9000. The 86x0, while delayed, and initially underperforming was still successful. The big reason no 8670 came about was really that DEC had started to want to lock down the buses, and the 86x0 just didn't fit in that scheme. The BI bus obviously became like a mantra after the 8600. So the 8650 was allowed to be done, since the effort was rather small (as you observe), but by then DEC was transforming into a company that really wasn't that interested in being an engineering company anymore, but which wanted to be IBM. And in that picture, something like Unibus, Massbus and SBI just was not what they wanted.
Yes - the era of "Let's hire 10,000 IBM sales people". Who unfortunately were a lot better at convincing customers to buy IBM than DEC because they were more familiar with IBM products, despite handing out DEC business cards.

And DEC completely ignored the lesson of the benefit of a thriving plug-compatible ecosystem for the IBM products. Without which DEC would hever have had the RP07 and TU7x peripherals.

The 86x0 came with a way-overspecified 60A Russelstoll plug so customers could "just" unplug and wheel out their 370-architecture systems and roll in a VAX 86x0. Never mind that everything else - hardware / software / operations were completely incompatible and different. The closed thing to compatibility was that IBM and DEC both offered a RPG II compiler.

The 9000, when it came out, was only a few months ahead of the NVAX. And the first iteration of the 9000 was not as fast as the revised one, if I remember right. And considering the size and price of it, it should have been obvious that they were only ever going to sell few of them. And microprocessors were increasing in performance so fast it was only a question of time before they would catch up and surpass.
I don't know if it was the sunk cost fallacy, ego, or total ignorance/disbelief of where microprocessors were headed that perpetuated the 9000 long after it should have been killed off.

To make another comparison between the PDP-11 and the VAX. The 86x0 was in some sense similar to the 11/60 on the PDP-11 side. It had issues, were late, and never realized its full potential. And came about the same time through the curve of the product. Admittedly, the 11/60 was in the end much less successful than the 86x0. Maybe just because it became much more crippled compared to the high end PDP-11s than the 86x0, which was closed to bleeding edge in performance.
The VAX architecture had the benefit of being fully specified. Later models had the ability to subset it (like the MicroVAX II) but actual architectural extensions were rare. There was VAX Vector supplemental instructions, for example. I don't remember if SMP introduced any new instructions at all, likewise for VAXft. Whereas the PDP-11 architecture was the Wild West by comparison. That meant that machine-specific extensions could be tried and if unsuccessful, omitted from future models. Extended addressing, I&D space, supervisor mode, cache, WCS, CIS, etc. Some of these caught on and showed up in future models, some were architectural dead ends. Unfortunately the 11/60 was late enough that other machines (like the 11/70 and to a lesser extent the 11/34A) beat it to market and stole a lot of the thunder the 11/60 group apparently expected. Aside from WCS, it seems to have been an evolutionary dead end. And WCS was only of interest to a very small percentage of customers, particularly when it became obvious that it was a model-specific feature unlikely to be available on subsequent models.
 
The VAX architecture had the benefit of being fully specified. Later models had the ability to subset it (like the MicroVAX II) but actual architectural extensions were rare. There was VAX Vector supplemental instructions, for example. I don't remember if SMP introduced any new instructions at all, likewise for VAXft. Whereas the PDP-11 architecture was the Wild West by comparison. That meant that machine-specific extensions could be tried and if unsuccessful, omitted from future models. Extended addressing, I&D space, supervisor mode, cache, WCS, CIS, etc. Some of these caught on and showed up in future models, some were architectural dead ends. Unfortunately the 11/60 was late enough that other machines (like the 11/70 and to a lesser extent the 11/34A) beat it to market and stole a lot of the thunder the 11/60 group apparently expected. Aside from WCS, it seems to have been an evolutionary dead end. And WCS was only of interest to a very small percentage of customers, particularly when it became obvious that it was a model-specific feature unlikely to be available on subsequent models.

The more proper, formal definition of the VAX definitely helped it. But looking at the 11/60, it is really a mystery why they decided to only do 18-bit addressing, skip I/D space and supervisor mode, which had already been done on the 11/70, and software was already starting to take advantage of.
Not having these things on the 11/60 pretty much doomed it. It meant it was just a little faster 11/34 type system, but being physically much larger and more expensive. WCS was really niche, and the only other thing was that the 11/60 hade FPP as standard, and an optional FPP accelerator making it a good number cruncher. But if someone was interested in performance, then the 11/70 would still be the better option, at not that much higher price.
You have to ask what really was the target group of customers for the 11/60? The only thing to really make the 11/60 stand out, or be something to consider, was the WCS.
 
But looking at the 11/60, it is really a mystery why they decided to only do 18-bit addressing, skip I/D space and supervisor mode, which had already been done on the 11/70, and software was already starting to take advantage of.
There's the old joke that everything Dave Cutler does looks like RSX. Apparently the 11/20, 11/35, 11/40 and 11/60 designs were all led by the same designer. But that doesn't explain how it got the funding to be an actual product - the 11/60 must have had some sort of sales projections that justified the effort, even if they were just fantasy.

You have to ask what really was the target group of customers for the 11/60? The only thing to really make the 11/60 stand out, or be something to consider, was the WCS.
Exactly. And being a one-off branch of the PDP-11 family, anyone who needed WCS was looking at either more 11/60 systems or re-doing everything for some other microarchitecture.

The 11/44 could probably have had WCS if it was needed - the microcode address space is there, though I don't know if you could fit a SRAM and glue logic on the uncommitted pads on the board - a socket for another microcode PROM would have been easy.

Given that the oldest known 11/44 microcode is from 1976:
Code:
;REV E -15 SEP 76 - 1144 FUNCTIONALITY
it seems pretty certain that the design (including the proposed model designation) and feature set was known within DEC before the 11/60 was released, which makes this all the more perplexing.
 
I worked at DEC from '75 thru '82 and came on board on the 11/60 project doing diagnostic software at first (floating point macrodiagnostics) and then later the DCS (diagnostic control store) module that was a special version of the 4KW ECS (extended control store) module. There was also the mentioned 1KW WCS (writable control store module).

Indeed the original 11/20 design engineer James O'Loughlin went on to lead the 11/40 design team, and as project leader (not a designer per se) on the 11/60.

As I remember, marketing told engineering they needed an 11/40 follow-on, and the 11/60 was spec'ed to do that. Engineering wanted to push to 11/70 compatibility for full 4MW memory support, but marketing said no would add too much cost based on projections. By the time the 11/60 was announced in 1978 we knew it was going to be a dud because of the 256KW memory limit.

In niche applications though the 11/60 did have the highest performance PDP-11 floating point option in the FP11-E. So it did find some application in that space, along with WCS for some targeted users.

Ultimately the 11/44 was put forth to fix the 11/60 memory limit issue.
 
In niche applications though the 11/60 did have the highest performance PDP-11 floating point option in the FP11-E. So it did find some application in that space, along with WCS for some targeted users..

Sounds like a DSP possibility to me; fast MAC wrapped in a microcoded algorithm -- FFT seems like the obvious candidate.
 
I worked at DEC from '75 thru '82 and came on board on the 11/60 project doing diagnostic software at first (floating point macrodiagnostics) and then later the DCS (diagnostic control store) module that was a special version of the 4KW ECS (extended control store) module. There was also the mentioned 1KW WCS (writable control store module).

Indeed the original 11/20 design engineer James O'Loughlin went on to lead the 11/40 design team, and as project leader (not a designer per se) on the 11/60.

As I remember, marketing told engineering they needed an 11/40 follow-on, and the 11/60 was spec'ed to do that. Engineering wanted to push to 11/70 compatibility for full 4MW memory support, but marketing said no would add too much cost based on projections. By the time the 11/60 was announced in 1978 we knew it was going to be a dud because of the 256KW memory limit.

In niche applications though the 11/60 did have the highest performance PDP-11 floating point option in the FP11-E. So it did find some application in that space, along with WCS for some targeted users.

Ultimately the 11/44 was put forth to fix the 11/60 memory limit issue.

Thanks for the added info. Really nice to hear from someone close to the action.

I know the FP11-E was good, but I wonder about absolute performance. The 11/60 itself wasn't as fast as the 11/70. If you look at the full package, would you really get more FP work done on the 11/60 than the 11/70? The FP11-C was pretty decent, and considering the better cache and shorter cycle time, I'm sortof curious if you did get more work done at the end of the day on the 11/60 than the 11/70, if you crunched numbers. I wouldn't think so, but I haven't looked deep enough into this question.
Sadly the processing handbook that I have that includes the 11/60 do not have timing information about FPP instructions.
 
Sadly the processing handbook that I have that includes the 11/60 do not have timing information about FPP instructions.

D'oh. Was looking in the wrong place. Found it now. The FP11-E is faster on additions, and much faster on multiplications, but way slower on divisions, compared to the FP11-C.
Interesting that division would have such poor performance.
 
Well worth a read is the 11/60 section of the "design tradeoffs" paper (chapter 14) of the Computer Engineering book (Bell et al,
http://www.bitsavers.org/pdf/dec/_Books/Bell-ComputerEngineering.pdf). IMO, there were a lot of neat ideas in that architecture besides the WCS. The shift tree, kind of a poor man's barrel shifter, is interesting. It's done with three levels of multiplexers and takes a single microcycle to shift-right 1 to 14 bits. Also interesting is the microcode subroutine capability allowing things like internal address processing to be handled in microcode saving a bunch of discrete logic.

The prior chapter (13) talks exclusively about design decisions for the 11/60.
 
D'oh. Was looking in the wrong place. Found it now. The FP11-E is faster on additions, and much faster on multiplications, but way slower on divisions, compared to the FP11-C.
Interesting that division would have such poor performance.

The FP11-E for the 11/60 used PROMs/ADDERS to build an 8b x 28b single cycle cycle multiplication table, so 28b x 28b single precision FP multiply could be developed in four CPU clocks. The earlier FP11 models for the 11/45/70 used the classic shift/add technique over 28b single precision (or 56b double precision) operands.

I believe the non-optimization of division was done because (1) it is really hard to optimize division and (2) software tried to replace divisions where-ever it could with multiply by reciprocal.

And yes the DEC Computer Engineering book referenced in the previous post has a pretty extensive discussion of the 11/60 CPU design tradeoffs.

PS

I have a complete 11/60 CPU board set, including the DCS diagnostic control store (no WCS, though), an 11/60 backplane, and an FP11-E board set, and an 11/60 console panel. Some day I was going to resurrect an 11/60 in something like a spare BA11K box I have, but I'm not sure someday will ever come. :-(
 
The FP11-E for the 11/60 used PROMs/ADDERS to build an 8b x 28b single cycle cycle multiplication table, so 28b x 28b single precision FP multiply could be developed in four CPU clocks. The earlier FP11 models for the 11/45/70 used the classic shift/add technique over 28b single precision (or 56b double precision) operands.

I believe the non-optimization of division was done because (1) it is really hard to optimize division and (2) software tried to replace divisions where-ever it could with multiply by reciprocal.

And yes the DEC Computer Engineering book referenced in the previous post has a pretty extensive discussion of the 11/60 CPU design tradeoffs.

PS

I have a complete 11/60 CPU board set, including the DCS diagnostic control store (no WCS, though), an 11/60 backplane, and an FP11-E board set, and an 11/60 console panel. Some day I was going to resurrect an 11/60 in something like a spare BA11K box I have, but I'm not sure someday will ever come. :-(

Funny. I actually have an 11/60 CPU board set as well. Once, many years ago, I was at a club where we had four 11/60 machines. They are long gone now, but one set of boards through strange paths ended up with me.

With regards to division, I know it's not that easy to optimize, but that it would be that much slower than the FP11-C surprised me a little. You could have expected it to atleast be similar in performance.
 
Does anyone happen to have an online copy (or not I guess) of the 11/60 microcode? I looked on all of the usual suspects, including the CHM, and found nothing. The fifth page of the FMPS says a paper version is available as DQMCA-D.
 
Back
Top