CDC 6600 - Why so awesome?

[Swift Griggs]

On Wed, 22 Jun 2016, Rich Alderson wrote:
> We have one running at LCM, attached to an instance of dtCyber, the 
> 6000/Cyber simulator, via John Zabolitzky's Xilinx-based display 
> adapter.  We're in the process of refurbing the one that came with the 
> 6500, which we may attach to the system at some point.

Is that "Living Computer Museum" ? You are in Seattle, right? I'll stop by 
for sure if I'm in the area. I'm in Denver.

> Not a matter of "didn't bother with", but rather "were never allowed 
> to". You don't get to fuck with the console of a multimillion dollar 
> machine if you're not part of the operations or systems programming 
> staff.

Like I was saying with Chuck, I just wasn't thinking about that, but it 
makes total sense when you put the $$$ into perspective.

> For the same reason you do it in the PDP-6/PDP-10:  Data often comes in 
> the form of text characters, which are much smaller than the word size, 
> so it makes sense to pack them in.

I get it. I just wondered about the mechanics of it.

> On the 6/10, the common method was 7-bit ASCII packed 5 per word. [...] 

Everyone had some whack-a-doodle way to encode character sets back then 
(and now it's just as bad or worse with things like UTF-8). People who 
complain about twos-compliment being a weird hack should focus more on all 
the ways folks encoded their charset. That's a veritable cornucopia of the 
arbitrary.

> ADJBP (ADJust Byte Pointer, which can back up as well as move forward).  

I find that weird, but possibly useful once I figured out how to implement 
it. Did that morph into something else as the platform matured or newer 
microcode hit the deck?

> The networking code uses a lot of 8- and 16-bit byte pointers, to handle 
> the fields in IP datagrams.

Convenient in this case, for sure. Hehe, not as convenient as me calling 
bind(), connect(), and send(), but hey apples to oranges, I know. :-)

> Other I/O code uses other byte sizes, to pull out or set the relevant 
> parts of device register values.

Well, I'd think it'd be helpful with I/O related code to deal with the 
real-world constellation of block devices from different devices. You 
could ratchet up when you needed throughput, and back down when you needed 
lower latency and finesse.
 
> A quick example, which substitutes a space for a rubout in a text string 
> without having to copy it into a second:
> 
> txtptr: point 7,string          ; sets up to point to the non-existent byte
>                                 ; before string
> 
>         move  10,txtptr         ; initialize pointer in loop
> top:    ildb  11,10             ; increments pointer, copies byte into AC 11
>         skipn 11                ; non-null value?
>          jrst bottom            ; no, end of string, exit loop
>         caie  11,177            ; is it a rubout character
>          jrst top               ; no, get next character in string
>         movei 11,40             ; change a rubout to a space
>         dpb   11,10             ; deposit byte into same location it came from
>         jrst  top               ; and continue
> bottom: <whatever>

Ah. labels are grand, and yes no extra register or buffer needed!

> PDP-10 operating systems in general use null-terminated strings.

You mean the way $DIETY intended? :-)

> Hope that helps you with capital wrapping.

Har! These days folks let the MS Paper Clip do that!

-Swift