From athornton at gmail.com Fri May 15 03:37:08 2020 From: athornton at gmail.com (Adam Thornton) Date: Thu, 14 May 2020 10:37:08 -0700 Subject: [COFF] [TUHS] v7 K&R C In-Reply-To: <20200514173206.GJ20771@mcvoy.com> References: <20200511005745.GL17035@mcvoy.com> <357EFE54-BD94-4C10-8C43-C6735BF7D317@via.net> <20200511202555.GU17035@mcvoy.com> <20200514173206.GJ20771@mcvoy.com> Message-ID: On May 14, 2020, at 10:32 AM, Larry McVoy wrote: > I'm being a whiney grumpy old man, I’ve been one of those since I was, like, 20. I am finally growing into it. It’s kinda nice. Adam From lm at mcvoy.com Fri May 15 03:38:51 2020 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 14 May 2020 10:38:51 -0700 Subject: [COFF] [TUHS] v7 K&R C In-Reply-To: References: <357EFE54-BD94-4C10-8C43-C6735BF7D317@via.net> <20200511202555.GU17035@mcvoy.com> <20200514173206.GJ20771@mcvoy.com> Message-ID: <20200514173851.GL20771@mcvoy.com> On Thu, May 14, 2020 at 10:37:08AM -0700, Adam Thornton wrote: > > On May 14, 2020, at 10:32 AM, Larry McVoy wrote: > > I'm being a whiney grumpy old man, > > I???ve been one of those since I was, like, 20. I am finally growing into it. It???s kinda nice. Yeah, there are aspects that are quite pleasant. Mentoring people is fun. --lm From crossd at gmail.com Tue May 19 02:11:00 2020 From: crossd at gmail.com (Dan Cross) Date: Mon, 18 May 2020 12:11:00 -0400 Subject: [COFF] [TUHS] v7 K&R C In-Reply-To: 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> Message-ID: On Sun, May 17, 2020 at 12:24 PM Paul Winalski wrote: > On 5/16/20, Steffen Nurpmeso wrote: > > > > Why was there no byte or "mem" type? > > These days machine architecture has settled on the 8-bit byte as the > unit for addressing, but it wasn't always the case. The PDP-10 > addressed memory in 36-bit units. The character manipulating > instructions could deal with a variety of different byte lengths: you > could store six 6-bit BCD characters per machine word, Was this perhaps a typo for 9 4-bit BCD digits? I have heard that a reason for the 36-bit word size of computers of that era was that the main competition at the time was against mechanical calculator, which had 9-digit precision. 9*4=36, so 9 BCD digits could fit into a single word, for parity with the competition. 6x6-bit data would certainly hold BAUDOT data, and I thought the Univac/CDC machines supported a 6-bit character set? Does this live on in the Unisys 1100-series machines? I see some reference to FIELDATA online. I feel like this might be drifting into COFF territory now; Cc'ing there. or five ASCII > 7-bit characters (with a bit left over), or four 8-bit characters > (ASCII plus parity, with four bits left over), or four 9-bit > characters. > > Regarding a "mem" type, take a look at BLISS. The only data type that > language has is the machine word. > > > +getfield(buf) > > +char buf[]; > > +{ > > + int j; > > + char c; > > + > > + j = 0; > > + while((c = buf[j] = getc(iobuf)) >= 0) > > + if(c==':' || c=='\n') { > > + buf[j] =0; > > + return(1); > > + } else > > + j++; > > + return(0); > > +} > > > > so here the EOF was different and char was signed 7-bit it seems. > > That makes perfect sense if you're dealing with ASCII, which is a > 7-bit character set. To bring it back slightly to Unix, when Mary Ann and I were playing around with First Edition on the emulated PDP-7 at LCM+L during the Unix50 event last USENIX, I have a vague recollection that the B routine for reading a character from stdin was either `getchar` or `getc`. I had some impression that this did some magic necessary to extract a character from half of an 18-bit word (maybe it just zeroed the upper half of a word or something). If I had to guess, I imagine that the coincidence between "character" and "byte" in C is a quirk of this history, as opposed to any special hidden meaning regarding textual vs binary data, particularly since Unix makes no real distinction between the two: files are just unstructured bags of bytes, they're called 'char' because that was just the way things had always been. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue May 19 02:30:33 2020 From: clemc at ccc.com (Clem Cole) Date: Mon, 18 May 2020 12:30:33 -0400 Subject: [COFF] [TUHS] v7 K&R C In-Reply-To: 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> Message-ID: On Mon, May 18, 2020 at 12:12 PM Dan Cross wrote: > 6x6-bit data would certainly hold BAUDOT data, and I thought the > Univac/CDC machines supported a 6-bit character set? > BAUDOT is 5 bits. CDC used a 6-bit Display code - which there were a number of different versions. It was a PITA when you programmed it. The original Pascal compiler was a mess because of this. > Does this live on in the Unisys 1100-series machines? I see some > reference to FIELDATA online. > https://www.fourmilab.ch/documents/univac/fieldata.html Yes, it was officially a 7-bit code, but the first 1/2 of the code was non-printable. So the printable set was 6 bits. > they're called 'char' because that was just the way things had always > been. > Right Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Tue May 19 07:18:34 2020 From: ron at ronnatalie.com (ron at ronnatalie.com) Date: Mon, 18 May 2020 17:18:34 -0400 Subject: [COFF] [TUHS] v7 K&R C In-Reply-To: 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> Message-ID: <094d01d62d59$e4192240$ac4b66c0$@ronnatalie.com> 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…. 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. 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). 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. This caused a problem when we ported 4BSD to the thing. The Berkeley kernel (particularly in the I/O code) did what I called “conversion by union.” 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’d 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 “The Low Speed Bus” and that we’d 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’s ECL memory, the thing consisted of 32 individual DEC UNIBUSes. -------------- next part -------------- An HTML attachment was scrubbed... URL: From grog at lemis.com Tue May 19 14:00:08 2020 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Tue, 19 May 2020 14:00:08 +1000 Subject: [COFF] UNIVAC and other character sets (was: v7 K&R C) In-Reply-To: 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> Message-ID: <20200519040008.GK1670@eureka.lemis.com> On Monday, 18 May 2020 at 12:11:00 -0400, Dan Cross wrote: > On Sun, May 17, 2020 at 12:24 PM Paul Winalski > wrote: > >> On 5/16/20, Steffen Nurpmeso wrote: >>> >>> Why was there no byte or "mem" type? >> >> These days machine architecture has settled on the 8-bit byte as the >> unit for addressing, but it wasn't always the case. The PDP-10 >> addressed memory in 36-bit units. The character manipulating >> instructions could deal with a variety of different byte lengths: you >> could store six 6-bit BCD characters per machine word, > > Was this perhaps a typo for 9 4-bit BCD digits? No, I think it was intended to be 6 text characters. My recollection is that the older "scientific" machines didn't do BCD. Certainly the older UNIVAC 1100s and 490s didn't. > 6x6-bit data would certainly hold BAUDOT data, and I thought the > Univac/CDC machines supported a 6-bit character set? Does this live > on in the Unisys 1100-series machines? I see some reference to > FIELDATA online. Most machines of the day used a 6 bit character encoding. You're right with Fieldata, but I don't know if it's still used. Are the 1100s still in use? They date back 60 years. My guesswork from here on: > To bring it back slightly to Unix, when Mary Ann and I were playing > around with First Edition on the emulated PDP-7 at LCM+L during the > Unix50 event last USENIX, I have a vague recollection that the B > routine for reading a character from stdin was either `getchar` or > `getc`. I had some impression that this did some magic necessary to > extract a character from half of an 18-bit word (maybe it just > zeroed the upper half of a word or something). That would be extremely inefficient on such a small machine. This was ASCII, right? I'd guess that the PDP-7, like the PDP-8, was intended to use 6 bit characters, and that was probably the reason why it was 18 bits rather than 16 bits. > If I had to guess, I imagine that the coincidence between > "character" and "byte" in C is a quirk of this history, as opposed > to any special hidden meaning regarding textual vs binary data, > particularly since Unix makes no real distinction between the two: > files are just unstructured bags of bytes, they're called 'char' > because that was just the way things had always been. I was going to say "C doesn't talk about bytes", but I was wrong. But from K&R, 1st edition, page 126: The size is given in unspecified units called "bytes," which are the same size as a char. Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From wkt at tuhs.org Mon May 25 14:27:26 2020 From: wkt at tuhs.org (Warren Toomey) Date: Mon, 25 May 2020 14:27:26 +1000 Subject: [COFF] Pointers for maths routines in "assembly" Message-ID: <20200525042726.GA685@minnie.tuhs.org> Hi all, I have a strange question and I'm looking for pointers. Assume that you can multiply two 8-bit values in hardware and get a 16-bit result (e.g. ROM lookup table). It's straightforward to use this to multiply two 16-bit values: AABB * CCDD ---- PPPP = BB*DD QQQQ00 = BB*CC RRRR00 = AA*DD SSSS0000 = AA*CC -------- 32-bit result But if the hardware can only provide the low eight bits of the 8-bit by 8-bit multiply, is it still possible to do a 16-bit by 16-bit multiply? Next question, is it possible to do 16-bit division when the hardware can only do 8-bit divided by 8-bit. Ditto 16-bit modulo with only 8-bit modulo? Yes, I could sit down and nut it all out from scratch, but I assume that somewhere this has already been done and I could use the results. Thanks in advance for any pointers. Warren ** Back story. I'm designing an 8-bit TTL CPU which has 8-bit multiply, divide and modulo in a ROM table. I'd like to write subroutines to do 16-bit and 32-bit integer maths. From ralph at inputplus.co.uk Mon May 25 15:22:29 2020 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Mon, 25 May 2020 06:22:29 +0100 Subject: [COFF] Pointers for maths routines in "assembly" In-Reply-To: <20200525042726.GA685@minnie.tuhs.org> References: <20200525042726.GA685@minnie.tuhs.org> Message-ID: <20200525052229.037CC1FAA1@orac.inputplus.co.uk> Hi Warren, > Assume that you can multiply two 8-bit values in hardware and get a > 16-bit result (e.g. ROM lookup table). It's straightforward to use > this to multiply two 16-bit values: ... > But if the hardware can only provide the low eight bits of the 8-bit > by 8-bit multiply, is it still possible to do a 16-bit by 16-bit > multiply? Yes. Given hex 8-b numbers ab and cd, use your 8×8=8 hardware multiply to work out b × d = BD a × d = AD b × c = BC a × c = AC and then shift and add: BD + (AD << 4) + (BC << 4) + (AC << 8) > ** Back story. I'm designing an 8-bit TTL CPU which has 8-bit > multiply, divide and modulo in a ROM table. I'd like to write > subroutines to do 16-bit and 32-bit integer maths. That's quite an unusual mix. Eight-bit CPUs I can think of either have no hardware multiply of which to take advantage, e.g. http://6502org.wikidot.com/software-math-intmul, or have a 8×8=16. -- Cheers, Ralph. From dfawcus+lists-coff at employees.org Mon May 25 19:12:18 2020 From: dfawcus+lists-coff at employees.org (Derek Fawcus) Date: Mon, 25 May 2020 10:12:18 +0100 Subject: [COFF] Pointers for maths routines in "assembly" In-Reply-To: <20200525042726.GA685@minnie.tuhs.org> References: <20200525042726.GA685@minnie.tuhs.org> Message-ID: <20200525091218.GB85793@clarinet.employees.org> On Mon, May 25, 2020 at 02:27:26PM +1000, Warren Toomey wrote: > > Next question, is it possible to do 16-bit division when the hardware > can only do 8-bit divided by 8-bit. Ditto 16-bit modulo with only 8-bit > modulo? I believe so. I've seen code for a 68000 to do division of 32 bit values when the chip only provides for division of 16 bit values. So the same approach should apply for extending an 8 bit divide to provide 16 bit division. The book I have this in attributes the algorith to a Dr. Arthur Norman. See https://archive.org/stream/Programming_The_M68000_1983_Adn-Wesley_Publishing_Company/Programming_The_M68000_1983_Addison-Wesley_Publishing_Company_djvu.txt Section 5.8 & 5.9, page 99 in the actual printed book. DF From crossd at gmail.com Wed May 27 05:55:39 2020 From: crossd at gmail.com (Dan Cross) Date: Tue, 26 May 2020 15:55:39 -0400 Subject: [COFF] [TUHS] History of popularity of C In-Reply-To: References: <8a2e9b1b-8890-a783-5b53-c8480c070f2e@telegraphics.com.au> <9e5933a166ece32b4fb17c6bbb563873@firemail.de> Message-ID: Cc: to COFF, as this isn't so Unix-y anymore. On Tue, May 26, 2020 at 12:22 PM Christopher Browne wrote: > [snip] > The Modula family seemed like the better direction; those were still > Pascal-ish, but had nice intentional extensions so that they were not > nearly so "impotent." I recall it being quite popular, once upon a time, > to write code in Modula-2, and run it through a translator to mechanically > transform it into a compatible subset of Ada for those that needed DOD > compatibility. The Modula-2 compilers were wildly smaller and faster for > getting the code working, you'd only run the M2A part once in a while > (probably overnight!) > Wirth's languages (and books!!) are quite nice, and it always surprised and kind of saddened me that Oberon didn't catch on more. Of course Pascal was designed specifically for teaching. I learned it in high school (at the time, it was the language used for the US "AP Computer Science" course), but I was coming from C (with a little FORTRAN sprinkled in) and found it generally annoying; I missed Modula-2, but I thought Oberon was really slick. The default interface (which inspired Plan 9's 'acme') had this neat graphical sorting simulation: one could select different algorithms and vertical bars of varying height were sorted into ascending order to form a rough triangle; one could clearly see the inefficiency of e.g. Bubble sort vs Heapsort. I seem to recall there was a way to set up the (ordinarily randomized) initial conditions to trigger worst-case behavior for quick. I have a vague memory of showing it off in my high school CS class. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: