Talk:Power 6/32

Speed info

(The spammers constantly delete this page. I frankly cannot keep up.)

The Power 6/32 was the famous Tahoe machine of 4.3 BSD fame, made by Computer Consoles Inc

All that I can find out about them is this table from http://www.dunnington.u-net.com/public/dhrystone.c

 *----------------DHRYSTONE VERSION 1.0 RESULTS BEGIN--------------------------
 *
 * MACHINE      MICROPROCESSOR  OPERATING       COMPILER        DHRYSTONES/SEC.
 * TYPE                         SYSTEM                          NO REG  REGS
 * --------------------------   ------------    -----------     ---------------
 * CCI POWER 6/32               COS(SV+4.2)     cc              7500    7800
 * CCI POWER 6/32               POWER 6 UNIX/V  cc              8236    8498
 * CCI POWER 6/32               4.2 Rel. 1.2b   cc              8963    9544
 * VAX 11/780   -               UNIX 5.2        cc              1515    1562
 * VAX 11/780   -               UNIX 4.3bsd     cc              1646    1662

Which may give some indication on the initial reasons why the Power 6/32 was chosen as the sucessor to the VAX by CSRG. Neozeed (talk) 17:01, 10 February 2009‎

More info coming

Working on obtaining some images and background information on Tahoe from one of the designers. Stay tuned. Retrev (talk) 18:02, 1 May 2018

It would be interesting to hear what "Retrev" was able to find out. Larsbrinkhoff (talk) 09:09, 10 August 2023 (CEST)

Well, that was the only thing they ever posted here. I'll send them email, using the send email link - assuming the email address they had back then still works. Jnc (talk) 00:46, 11 August 2023 (CEST)

Our own User:Neozeed may already be on the case? (Read bottom comments.) Jnc (talk) 01:37, 11 August 2023 (CEST)

Oh, good catch! Let's hope so, but also try the email to Retrev.

Many tidbits in magazines can be found here: https://www.google.com/search?q=%22computer+consoles+inc%22+site:bitsavers.org (Not suggesting anyone should pick this up right away.)

I emailed Ed Scott.

Larsbrinkhoff (talk) 07:31, 11 August 2023 (CEST)

I checked with neozeed, but he was sworn to secrecy regarding the info he received. Larsbrinkhoff (talk)

Pity. In this, I found little, but did find this:

"I read some of their manuals. The instruction set of the cpu was tailored to running C programs. There was a *single* instruction that did what strlen() did... it took an address from a register and read down memory until it found a null byte. It returned the byte count of the string in another register."

about the HCX-5. Pity none of those manuals appears to be extant! Jnc (talk) 18:21, 22 December 2023 (CET)

I surmise it would be possible to reverse engineer the instruction set and other hardware from BSD source code and compiler toolchain. I also found a copy of Harri's HCX Unix which might be helpful in such an endeavor. At the end of the day, it would just be another also-ran running another Unix port same as all others, so I don't see much point. Larsbrinkhoff (talk) 18:41, 22 December 2023 (CET)

Workstation?

Was it a workstation? Larsbrinkhoff (talk) 08:13, 22 December 2023 (CET)

Ooh, good catch! Looking at the image of one in the Harris HCX-5 ad that neozeed found, it looked like one, but when I read the copy, probably not! "costs from $124,500", and, even more tellingly, "supports up to 128 users"! Definitely supports its classification as a 'super-mini'! I'll fix that, and upgrade he article a bit at the same time.

I was just trying to empty all the random machines out of Category:Computers; I'll have to check and see if I made any other errors! :-) Jnc (talk) 13:25, 22 December 2023 (CET)

I asked neozeed, and he replied "from what I know its def a super mini. the image looks like a full rack, and the stories I heard about their use is that they weren't exactly something you could take home in a car." Larsbrinkhoff (talk) 16:09, 22 December 2023 (CET)

"We can infer a lot"

User:Jonathanjo wrote: "We can infer a lot from the 4.3BSD-tahoe source file [...]" I haven't checked, but I was assuming there is a complete toolchain. And perhaps even binaries? I kind of suppose there is enough information to make a Tahoe emulator running 4.3BSD. Also, as Yoda points out, there is another source: Harris HCX/UX. Unfortunately it can't be made public, but certainly a lot can be learned.

Now, clearly the end result would very much like running 4.3BSD on a VAX, so it's more hack value than actual utility. Larsbrinkhoff (talk) 16:43, 20 December 2024 (CET)

There does seem to be a complete toolchain (much of it in the Reno release). If you go to the top-level page (here), and enter 'tahoe', and do a search, you get a long list of stuff - including the PCC and assembler. I don't see a linker, but maybe there's nothing CPU-specific in that?

Installing and Operating 4.3BSD UNIX on the Tahoe shows that it used a VERSAbus. Jnc (talk) 18:02, 20 December 2024 (CET)

On further consideration, I am not sure there is enough information there to make a Tahoe emulator. I've been trying to work out, from the instruction decode stuff in the debugger, what Tahoe instructions look like (fields, etc). That I think we can accomplish: but that still doesn't tell you what all the instructions do. Some, e.g.:

pushl $1

are obvious enough, but others are a little more obscure. Take, for instance, the instruction:

callf $0,_syserr

Clearly some kind of subroutine call; but what, exactly (which, of course, one needs to know, to do the emulation correctly), does that do? Set up a frame of length zero? Push a zero argument and call the routine? Who knows!

Yes, if one has a simple C program ('cat.c', or something), and the binary for it, one can probably work out what the program does, and then look at the binary, and figure out what each of the instructions in it do. That's going to be a long slog, though. And the more obscure instructions, first one is going to have to search for a place that uses them, and only then can one try and work out what they do.

I think I'd try and see if anyone has a Taho "architecture reference manual" stored away in the back of a closet first! Jnc (talk) 17:59, 22 December 2024 (CET)

CPU or system?

Was the 'Power 6/32' just the CPU, or the whole system? In a related question, were the other companies with Tahoe machines (Harris, Unisys, etc) using boards from CCI (the CPU), or did they just license the design from CCI, and build their own physical CPUs? The CCI article mentioned here describes those 3 other companies as "OEMs" of CCI, which would seem to indicate they were using CPUs actually built by CCI. (Technically, I guess the 'Power 6/32' could be the name for the complete system, and the actual CPU boards out of it could be what the other vendors were using.)

Now, Installing and Operating 4.3BSD-tahoe UNIX on the Tahoe talks of it running on the "CCI Power 6/32 and similar machines", and says it is built around the VERSAbus. The Tahoe distribution includes a file HCX9LIST, which seems to indicate that they did later have it running on the Harris HCX-9: "Changes made to the 4.3BSD-tahoe distribution to support HCX9". That first document says it "can be booted on a CCI Power 6/32, Harris HCX-7, Unisys (Sperry) 7000/40, or ICL Clan 7 with any disks supported on the VERSAbus disk controllers".

Here we have a bit of a mystery. The ads for the HCX-5 and HCX-9 speak of it using the VMEbus. The VERSAbus, although electrically very similar to the VMEbus, is physically incompatible: the former uses pin-in-shell connectors, the latter uses etch lands (see board image). The setup document, above, however, speaks of the use of "VERSAbus adaptor[s]", but no further details on them are given; I guess it's possible the machines with VMEbuses could have been using VERSAbus adaptors. (If they were using CCI-built CPUs, this seems likely - unless CCI built a later variant that plugged into a VMEbus.)

Depending on the answers to all the above, that brings up two other questions:

1. - If the 'Power 6/32' is the whole system, what's the CPU called? Is 'Tahoe' the correct name for it? If not, what is it?
2. - How should we handle this - move the CPU-specific content to another page (Tahoe is currently just a redir to here, so could be used), and keep this page for the CCI-produced complete machine?

The 'instrs' file references "the architecture reference manual (1981 edition)"; that might answer some of these questions. I have looked for that online, but it didn't turn up. Maybe we'll eventually get lucky, and someone who worked with these machines back when has a copy gathering dust at the back of a closet. Jnc (talk) 22:13, 21 December 2024 (CET)

'Indexed' addressing mode

So, I don't think I've seen anything about how the 'indexed' addressing mode worked. I just had an idea on that pop into my head.

I wonder if it causes the contents of Rx (in the 'index' argument) to be added to the address from the next operand? I get the impression (although I have yet to confirm it, by looking at the instruction decoding/printing code from the debugger(s)) that the 'indexed addressing mode' argument contains only a 4-bit register number, and nothing else. So how can that produce a useful address? How is it any different from plain old (Ry)? All of those questions are answered if it does what 'indexing' did on some other machines - add several things together to provide an address. The suggested syntax ("[Rn]") makes sense too.

The only hitch is that the instruction would have to include another argument; e.g. a two-argument instruction would have to have three arguments if one of the two starts off with an indexed argument. opset.c does seem to back this up; the code for handling an indexed argument:

	adbprintf("[%s]", regname[r]);
	goto again;

where the jump to 'again:' processes and prints another argument.

The only question left is whether one can have more than one of these at a time;i.e. something like '[R1][R2](R3)+'? The argument decoding/printing code would definitely allow it; but I guess we'd really need to get ahold of the architecture reference manual to be sure. Jnc (talk) 09:04, 23 December 2024 (CET)