From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 5426 invoked from network); 18 May 2020 21:19:05 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 18 May 2020 21:19:05 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 0D6AF9C1D9; Tue, 19 May 2020 07:19:04 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 4A4059C178; Tue, 19 May 2020 07:18:40 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (1024-bit key; secure) header.d=mxes.net header.i=@mxes.net header.b="Fb7rt/Le"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 2A40A9C178; Tue, 19 May 2020 07:18:38 +1000 (AEST) Received: from smtp-out-3.mxes.net (smtp-out-3.mxes.net [198.205.123.68]) by minnie.tuhs.org (Postfix) with ESMTPS id 42B069C15F for ; Tue, 19 May 2020 07:18:37 +1000 (AEST) Received: from Customer-MUA (mua.mxes.net [10.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D08307592E; Mon, 18 May 2020 17:18:34 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mxes.net; s=mta; t=1589836715; bh=l8r+fKi3t+c77AqpHTF53CwCw3vEO8xBW6IaY8qZNT0=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=Fb7rt/LeWhyTa0ZswZAd9P+PH/D6t7hp+84Un+lbcpB1FqBY38der5CUG36bM9d8c 1O2RTBfG5DSfQXxhpdp5nBWDZpz44CMwbL+JdGhHypSzpZCo+A+nlsqdr6BxcGrtfL 6j8/HI2ScamFqoC0dgRPCedcDWKORp/b3/qccLQk= From: To: "'Dan Cross'" , "'Paul Winalski'" References: <20200515213138.8E0F72D2D71E@macaroni.inf.ed.ac.uk> <077a01d62b08$e696bee0$b3c43ca0$@ronnatalie.com> <20200515233427.31Vab%steffen@sdaoden.eu> <5DB09C5A-F5DA-4375-AAA5-0711FC6FB1D9@ronnatalie.com> <20200516232607.nLiIx%steffen@sdaoden.eu> In-Reply-To: Date: Mon, 18 May 2020 17:18:34 -0400 Message-ID: <094d01d62d59$e4192240$ac4b66c0$@ronnatalie.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_094E_01D62D38.5D07F770" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLwRcJG/9QczLTc2cBhlW55PVtCnQI5Q21UAzy3KyAA3d1SRgNpGAGZAlAem8sBxBfWWQG6rA0Fpf3E70A= Content-Language: en-us X-Sent-To: Subject: Re: [TUHS] v7 K&R C X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: 'The Eunuchs Hysterical Society' , 'COFF' Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" This is a multipart message in MIME format. ------=_NextPart_000_094E_01D62D38.5D07F770 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable No typo. While BCD was a way of encoding digits, BCD was also used as = a character encoding. Often these were outgrowths of the digit+zone = punch encoding of IBM cards. IBM later extended their BCD making = into=E2=80=A6. The EXTENDED Binary Coded Decimal Interchange Code, = going from 6 to 8 bits in the process.l UNIVAC indeed have their own BCD-sih format called FIELDDATA. It was = notable in that the nul value printed as @. the PDP-10 and the UNVAC 1100 series were just the longest surviving = perhaps of the 36 bit computers, that also included the IBM 70XX series = and the GE 600 (Honewell 6000) series. Both the UNIVAC and the PDP-10 = did have the nice variable partial word mode, but all of these were = indeed word addressed machines. =20 The early Crays also were word addressed. The C compiler would = simulated byte addressing by putting the byte offsetinto the word in the = high order bits (the address resgisters themselves were pinned at 24 = bits). =20 Just to get this back on a UNIX history track, let me delve into more = trivia. Perhaps the real oddity was the Denelcor HEP. The HEP had two = addressing modes: One was byte addressed (as you expect), the other = was for all other data thpes (16-bit, 32-bit, and 64-bit portions of the = 64-bit word). The lower 3 bits of the memory address encoded the word = side. If it was 0 or 4, then it a 64 bit operand at the address = specified in the higher part of the pointer. If it was 2 or 6, then it = was either the upper or lower half word. If it was 1,3,5, or 7, it was = one of the respective quarter words. =20 This caused a problem when we ported 4BSD to the thing. The Berkeley = kernel (particularly in the I/O code) did what I called = =E2=80=9Cconversion by union.=E2=80=9D They would store a value in a = union using one type pointer and the retrieve it via a different type. = In our compiler, had they used a cast (or went via a void* = intermediary), everything would be fine. But doing this sort of = shenanigan (which is technically undefined behavior in C) led to = insidious bugs where you=E2=80=99d be doing pointer operations and the = WRONG size word would be referenced. I spent a few days hunting all these down and fixing them. It was about this time I realized that the code was setting up I/Os = using a feature aptly named =E2=80=9CThe Low Speed Bus=E2=80=9D and that = we=E2=80=99d never get any reasonable performance that way. HEP = designer Burton Smith and I redesigned the I/O system literally on = napkins from the Golden Corral in Aberdeen. We went back and built a = new I/O system out of spare parts we had on hand using an 11/34 as a = control processor. The HEP I/O system was kind of interesting in that = while it had a highspeed interface into he HEP=E2=80=99s ECL memory, the = thing consisted of 32 individual DEC UNIBUSes. =20 ------=_NextPart_000_094E_01D62D38.5D07F770 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

No typo.=C2=A0=C2=A0 While BCD = was a way of encoding digits, BCD was also used as a character = encoding.=C2=A0=C2=A0 Often these were outgrowths of the digit+zone = punch encoding of IBM cards. =C2=A0=C2=A0IBM later extended their BCD = making into=E2=80=A6.=C2=A0 The EXTENDED Binary Coded Decimal = Interchange Code, going from 6 to 8 bits in the process.l

UNIVAC = indeed have their own BCD-sih format called FIELDDATA.=C2=A0=C2=A0 It = was notable in that the nul value printed as @.

the PDP-10 and = the UNVAC 1100 series were just the longest surviving perhaps of the 36 = bit computers, that also included the IBM 70XX series and the GE 600 = (Honewell 6000) series.=C2=A0=C2=A0 Both the UNIVAC and the PDP-10 did = have the nice variable partial word mode, but all of these were indeed = word addressed machines.

 

The early = Crays also were word addressed.=C2=A0=C2=A0 The C compiler would = simulated byte addressing by putting the byte offsetinto the word in the = high order bits (the address resgisters =C2=A0themselves were pinned at = 24 bits).

 

Just to get this back on a UNIX history track, let me = delve into more trivia.

Perhaps the real oddity was the Denelcor = HEP.=C2=A0=C2=A0 The HEP had two addressing modes:=C2=A0=C2=A0 One was = byte addressed (as you expect), the other was for all other data thpes = (16-bit, 32-bit, and 64-bit portions of the 64-bit word).=C2=A0=C2=A0 = The lower 3 bits of the memory address encoded the word = side.=C2=A0=C2=A0 If it was 0 or 4, then it a 64 bit operand at the = address specified in the higher part of the pointer.=C2=A0=C2=A0 If it = was 2 or 6, then it was either the upper or lower half word.=C2=A0=C2=A0 = If it was 1,3,5, or 7, it was one of the respective quarter = words.

 

This caused a problem when we ported 4BSD to the = thing.=C2=A0=C2=A0=C2=A0 The Berkeley kernel (particularly in the I/O = code) did what I called =E2=80=9Cconversion by = union.=E2=80=9D=C2=A0=C2=A0 They would store a value in a union using = one type pointer and the retrieve it via a different type.=C2=A0=C2=A0 = =C2=A0In our compiler, had they used a cast (or went via a void* = intermediary), everything would be fine.=C2=A0=C2=A0 But doing this sort = of shenanigan (which is technically undefined behavior in C) led to = insidious bugs where you=E2=80=99d be doing pointer operations and the = WRONG size word would be referenced.

I spent a few days hunting = all these down and fixing them.

It was about this time I realized = that the code was setting up I/Os using a feature aptly named = =E2=80=9CThe Low Speed Bus=E2=80=9D and that we=E2=80=99d never get any = reasonable performance that way.=C2=A0=C2=A0 HEP designer Burton Smith = and I redesigned the I/O system literally on napkins from the Golden = Corral in Aberdeen.=C2=A0=C2=A0 We went back and built a new I/O system = out of spare parts we had on hand using an 11/34 as a control = processor.=C2=A0=C2=A0 The HEP I/O system was kind of interesting in = that while it had a highspeed interface into he HEP=E2=80=99s ECL = memory, the thing consisted of 32 individual DEC = UNIBUSes.

 

------=_NextPart_000_094E_01D62D38.5D07F770--