TUHS

tuhs@tuhs.org

12 participants
6534 discussions

by Richard Tobin

> Isn't it nonstandard (although I am aware of some compilers that do it) to > default the type of char to unsigned? No. "The implementation shall define char to have the same range, representation, and behavior as either signed char or unsigned char." - C99 (Technically it's a separate type from both of them.) -- Richard -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

5 years, 1 month

Chaos networking in 8th edition (and in 7th)

by Norman Wilson

Paul Ruizendaal: Was Chaos networking in use at the labs, or is it just an artifact present on the surviving tape? === I don't recall any use of Chaos in 1127. Possibly one of the nearby groups who also used the Research system needed it at some point, perhaps before my time (I arrived in August 1984). I certainly don't remember anyone raising objections to discarding it. Norman Wilson Toronto ON

5 years, 1 month

Re: [TUHS] v7 K&R C

by Doug McIlroy

> [A]lthough these days "byte" is synonymous with "8 bits", historically it > meant "the number of bits needed to store a single character". It depends upon what you mean by "historically". Originally "byte" was coined to refer to 8 bit addressable units on the IBM 7030 "Stretch" computer. The term was perpetuated for the 360 family of computers. Only later did people begin to attribute the meaning to non-addressable 6- or 9-bit units on 36- and 18-bit machines. Viewed over history, the latter usage was transient and colloquial. Doug

5 years, 1 month

Re: [TUHS] v7 K&R C

by Doug McIlroy

I should have checked my 7030 manual before asserting that the 8-bit byte came from there. The term did, but it meant an addressable unit of 1 to 8 bits depending on the instruction being executed. [The machine was addressable to the bit. It also had all 16 bitwise logical operators, and maintained counts of the 1 bits and leading 0 bits in a register. And it was BIG. I saw one with 17 memory boxes (each essentially identical with the total memory of a 7090) stretched across the immaculate hardwood floor of IBM's Poughkeepsie plant.] Doug

5 years, 1 month

Chaos networking in 8th edition (and in 7th)

by Paul Ruizendaal

The surviving 8th edition source has code for Chaos networking included: https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/sys <https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/sys> It does not appear to be included in the man pages. Was Chaos networking in use at the labs, or is it just an artifact present on the surviving tape? Related to that, I’m interested in the Chaosnet implementation for 7th edition. Dave Moon's Chaosnet memo includes this intriguing sentence when talking about the V7 implementation: “The NCP is entirely implemented in the kernel as a device driver”. I could not find that source code in the TUHS archive, nor on Kirk McKusick’s DVD. Does anybody happen to have it?

5 years, 1 month

Re: [TUHS] v7 K&R C

by Doug McIlroy

They are flagging non-portable usage.

5 years, 1 month

Re: [TUHS] v7 K&R C

by Nelson H. F. Beebe

Discussions today on the TUHS list about the signed/unsigned nature of the C char type led me to reexamine logs of my feature test package at http://www.math.utah.edu/pub/features/ I had 170 build logs for it from 2017.11.07, so I moved those aside and ran another set of builds in our current enlarged test farm. That generated another 361 fresh builds. Those tests are all with the C compiler named "cc". I did not explore what other C compilers did, but I strongly suspect that they all agree on any single platform. On all but THREE systems, the tests report that "char" is signed, with CHAR_MAX == +127. The three outliers have char unsigned with CHAR_MAX == +255, and are * ARM armv7l Linux 4.13.1 (2017) and 5.6.7 (2020) * SGI O2 R10000-SC (150 MHz) IRIX 6.5 (2017 and 2020) * IBM POWER8 CentOS Linux release 7.4.1708 (AltArch) (2017) So, while the ISO C Standards, and historical practice, leave it implementation dependent whether char is signed or unsigned, there is a strong majority for a signed type. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu - - 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------

5 years, 1 month

QED with Unicode support

by arnold＠skeeve.com

Hello All In case this is of interest: > Date: Sat, 16 May 2020 12:18:15 +0100 > Subject: qed-archive (Github) > To: arnold(a)skeeve.com > > Hi Arnold > > Apologies for an un-solicited email. > > I have ported Rob's UofT QED from your qed-archive/unix-1992 to Linux > (although I suspect anything with a Unix API will work), and have updated > it to work completely in UTF8/Unicode. This includes correct handling of > unicode codepoints in regexes, subs, etc. > > It's up on Github under phonologus/QED. I thought you might want to add it > to your list of QED-s in your README, as it may be of interest to the other > three connoisseurs out there...! > > I have also included typeset pdf-s of the tutorial and manpage. The > tutorial is fascinating. > > Also, there is no clear statement about copyright, or license, of the > unix-1992 tarball. I have attributed it to Rob, and I have noted that I > scavenged it from your Github repo, but was wondering if there is any > definitive statement on ownership/authorship that I could include in my > repo? > > Best wishes

5 years, 1 month

Re: [TUHS] v7 K&R C [really lexers]

by Nelson H. F. Beebe

Brantley Coile <brantley(a)coraid.com> wrote on Sun, 17 May 2020 01:36:16 +0000: >> It looks like only grap and pic have mkfiles that invoke lex. Both of those are Brian Kernighan's work, and from the FIXES file in his nawk, I can offer this quote: >> ... >> Aug 9, 1997: >> somewhat regretfully, replaced the ancient lex-based lexical >> analyzer with one written in C. it's longer, generates less code, >> and more portable; the old one depended too much on mysterious >> properties of lex that were not preserved in other environments. >> in theory these recognize the same language. >> ... ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu - - 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------

5 years, 1 month

Re: [TUHS] v7 K&R C

by Richard Tobin

> The function prototype for getchar() is: int getchar(void); > > It returns an int, not a char. In all likelihood this is specifically > *because* EOF is defined as -1. It would have probably returned int anyway, because of the automatic promotion of char to int in expressions. It was natural to declare functions returning char as int, if you bothered to declare them at all. As K&R1 said: Since char promotes to int in expressions, there is no need to declare functions that return char. Similarly functions that might return short or float would normally return int or double; there aren't separate atof and atod functions for example. -- Richard -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

5 years, 1 month

11/40 CPU (Emulation) test programs still available somewhere

by Michael Stiller

Hi Legends, during corona times i “ported” Dave Cheney’s avr11 PDP11/40 emulator to a Teensy 4 MCU board, fixed already some bugs in it and added multiple rk drives and a partially working tm emulation. (space forward/reverse unimplemented) It runs V6 at about 1 Mips and is completely fine usable with multiple rk and tm drives. Playing around with V6 i noticed that Shoppa disk and tried to get ncc running, but after some debugging it looked like it is stuck in some loop which i think is due to possible bugs in the emulator code. So the question is, are there programs V6 runnable or rk bootable available which test the CPU functionality? I already hat a look at some xxdp disk, but the one i found (while they boot) seem to lack basic cpu tests. Best regards, Michael

5 years, 1 month

A la carte menu of OO features or properties

by Don Hopkins

The properties of object oriented programming are better described as an la carte menu like a cafeteria buffet or smörgåsbord, than a point, line, or continuum. http://www.paulgraham.com/reesoo.html <http://www.paulgraham.com/reesoo.html> Paul Graham: Reese Re: OO (Jonathan Rees had a really interesting response to Why Arc isn't Especially Object-Oriented, which he has allowed me to reproduce here.) Here is an a la carte menu of features or properties that are related to these terms; I have heard OO defined to be many different subsets of this list. • Encapsulation - the ability to syntactically hide the implementation of a type. E.g. in C or Pascal you always know whether something is a struct or an array, but in CLU and Java you can hide the difference. • Protection - the inability of the client of a type to detect its implementation. This guarantees that a behavior-preserving change to an implementation will not break its clients, and also makes sure that things like passwords don't leak out. • Ad hoc polymorphism - functions and data structures with parameters that can take on values of many different types. • Parametric polymorphism - functions and data structures that parameterize over arbitrary values (e.g. list of anything). ML and Lisp both have this. Java doesn't quite because of its non-Object types. • Everything is an object - all values are objects. True in Smalltalk (?) but not in Java (because of int and friends). • All you can do is send a message (AYCDISAM) = Actors model - there is no direct manipulation of objects, only communication with (or invocation of) them. The presence of fields in Java violates this. • Specification inheritance = subtyping - there are distinct types known to the language with the property that a value of one type is as good as a value of another for the purposes of type correctness. (E.g. Java interface inheritance.) • Implementation inheritance/reuse - having written one pile of code, a similar pile (e.g. a superset) can be generated in a controlled manner, i.e. the code doesn't have to be copied and edited. A limited and peculiar kind of abstraction. (E.g. Java class inheritance.) • Sum-of-product-of-function pattern - objects are (in effect) restricted to be functions that take as first argument a distinguished method key argument that is drawn from a finite set of simple names. […] (See the web page and the original thread for a discussion of which languages implement which of the above features.) http://www.paulgraham.com/reesoo.html <http://www.paulgraham.com/reesoo.html> https://web.archive.org/web/20160308032317/http://www.eros-os.org/pipermail… <https://web.archive.org/web/20160308032317/http://www.eros-os.org/pipermail…> -Don

5 years, 1 month

Re: [TUHS] v7 K&R C

by Doug McIlroy

> I feel the essence of object-oriented computing > is not operator overloading but the representation of behavior. Rob is right. Overloading is a universal characteristic of OO programming, but not the essence. Doug

5 years, 1 month

Re: [TUHS] v7 K&R C

by Paul McJones

> On May 13, 2020, at 7:00 PM,Dave Horsfall <dave(a)horsfall.org> wrote: > > I never could figure out why Stroustrup implemented that "feature"; let's > see, this operator usually means this, except when you use it in that > situation in which case it means something else. Now, try debugging that. C continues the tradition begun by Fortran and Algol 60 of overloading the arithmetic operators on the various numeric types. C++ allows new types to be defined; when a new type obeys the generally understood properties of a built-in type, it makes sense to use the same operator (or function) for the corresponding operation on the new type (e.g., addition on complex numbers, arbitrary-precision integers and rationals, polynomials, or matrices).

5 years, 1 month

[off topic] anyone want some QIC-250 tapes?

by arnold＠skeeve.com

I recently unearthed two 250 Mb QIC cartridges (like we used to use on Sun workstations). They were last written on in late 1997. I have no idea if they're any good, but they're free to anyone who'll pay postage (from Israel). If no takers, I'll just toss 'em. Thanks, Arnold

5 years, 1 month

Re: [TUHS] Linotron 202 Information

by TangentDelta

Here is a dump of the ROM in a text-based format. I couldn't think of a good way to represent the 4-bit words in a normal binary format with the order being ambiguous. Connecting a logic analyzer up to the ROM and triggering an "autoload" sequence, the processor reads ROM address 0, followed by ROM address 1, and then seems to lock up. I'm curious if the processor is attempting to store the 8-bit word into RAM for some reason? My RAM board is in very poor condition and I will need to devise a way to troubleshoot it. It'd also be helpful to have some of those control lines hooked up to the logic analyzer while it is happening. I'm working on a disassembler that should let me shuffle the order of the 4-bit words around until I get something that looks sane. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, May 13, 2020 3:27 PM, Ken Thompson <ken(a)google.com> wrote: > can you send me the bits of the rom. > i will take a look. > > On Tue, May 12, 2020 at 12:44 PM TangentDelta via TUHS <tuhs(a)minnie.tuhs.org> wrote: > >> Hello. >> >> I have a pair of controller card cages out of Mergenthaler Linotron 202 photo-typesetting machines. Sadly the machines themselves were scrapped, and these card cages are all I was able to save. >> >> The controllers use Computer Automation Naked Mini processors, which are relatively small 16-bit minicomputers designed for embedded control applications. I've been hacking on these for a few months now and have built up a system bus pinout diagram and several schematics. I haven't been able to find any technical information online in regards to the specific model of Naked Mini processor used in the 202, but I have found a trove of documents for other Naked Mini models on Bitsavers. >> >> I pulled the 512x4bit "boot ROM" mentioned in the "Experience with the Mergenthaler Linotron 202 Phototypesetter, or, How We Spent Our Summer Vacation" paper and dumped it, but the resulting binary doesn't produce any sane-looking code when manually disassembled using the documents on Bitsavers and reference, no matter how I arrange the nybbles. The processor also does not appear to respect the control opcodes issued by the Computer Automation LSI series programming console that I obtained. This has led me to the hypothesis that this is not a stock "Naked Mini" or later "Naked Milli" processor, but something specific to Mergenthaler. >> >> My goal is to get the processor to run my own code, and eventually design my own MaxiBus peripherals to use with it. >> >> If anyone knows where I can look for more information in regards to the 202 and the Naked Mini processor, or has any stories of working on these machines, I would greatly appreciate it! >> >> Thanks.

5 years, 1 month

Linotron 202 Information

by TangentDelta

Hello. I have a pair of controller card cages out of Mergenthaler Linotron 202 photo-typesetting machines. Sadly the machines themselves were scrapped, and these card cages are all I was able to save. The controllers use Computer Automation Naked Mini processors, which are relatively small 16-bit minicomputers designed for embedded control applications. I've been hacking on these for a few months now and have built up a system bus pinout diagram and several schematics. I haven't been able to find any technical information online in regards to the specific model of Naked Mini processor used in the 202, but I have found a trove of documents for other Naked Mini models on Bitsavers. I pulled the 512x4bit "boot ROM" mentioned in the "Experience with the Mergenthaler Linotron 202 Phototypesetter, or, How We Spent Our Summer Vacation" paper and dumped it, but the resulting binary doesn't produce any sane-looking code when manually disassembled using the documents on Bitsavers and reference, no matter how I arrange the nybbles. The processor also does not appear to respect the control opcodes issued by the Computer Automation LSI series programming console that I obtained. This has led me to the hypothesis that this is not a stock "Naked Mini" or later "Naked Milli" processor, but something specific to Mergenthaler. My goal is to get the processor to run my own code, and eventually design my own MaxiBus peripherals to use with it. If anyone knows where I can look for more information in regards to the 202 and the Naked Mini processor, or has any stories of working on these machines, I would greatly appreciate it! Thanks.

5 years, 2 months

Re: [TUHS] SDB debugger

by Doug McIlroy

> Does anyone know if dbx ended up 8 or 9th I believe the only debuggers on research machines were db v1-v6 adb v7,v9,v10 cdb v3-v6 sdb v8-v9 pi v8-v10 Doug

5 years, 2 months

SDB debugger

by Paul Ruizendaal

Reading some more stuff about the road from 7th Edition to 8th Edition, this time about debuggers. My current understanding is as follows: - On 6th edition the debugger was ‘cdb’ - On 7th edition it was ‘adb’, a rewrite / evolution from ‘cdb’ - In 32V a new debugger appears, ‘sdb’. Its code seems a derivative from ‘adb’, but the command language is substantially reworked and it uses a modified variant of the a.out linker format - in essence the beginnings of ‘stabs’. Of course the compiler, assembler, linker and related tools all emit/recognize these new symbol table elements. - The July 78 file note by London/Reiser does not mention a reworked debugger at all; the 32V tape that is on TUHS has ’sdb' files that are dated Feb/Mar 1979. This stuff must have been developed between July 78 and March 79. - In the SysIII and 3BSD code on TUHS (from early 80 and late 79 respectively) the stabs format is more developed. For SysIII it is ‘VAX only’. With these roots, it is not surprising that it is also in 8th Edition. Two questions: (1) According to Wikipedia the original author of the stabs format is unknown. It also says that the original author of ‘sdb’ is unknown. Is that correct, is the author really unknown? (2) As far as I can tell, the ’sdb’ debugger was never back ported to 16 bit Unix, not in the SysIII line and not in the 2.xBSD line. It would seem to me that the simple stabs format of 32V would have lent itself to being back ported. Is it correct that no PDP11 Unix used (a simple) stabs tool chain and debugger?

5 years, 2 months

Question: stdio - Who invented and ...

by Ed Bradford

I've forgotten who created stdio, USG or the research group. Can any of the youthful BTL folks of the 1970's refresh my mind. Given that stdio was invented and, in my opinion at the time, a reasonable and usable standard interface to IO on Unix, I am curious why no standard for networking was developed or proposed and discussed. Sockets just defined a new and very quirky IO interface for Unix based systems. Was any thought given to defining networking using the creat/open/read/write/close/mknod/link/unlink/chmod/chown model of IO in UNIX? Ed Bradford -- Advice is judged by results, not by intentions. Cicero

5 years, 2 months

Bell Labs recruiter

by Efton Collins

I was lucky enough to be in the room last year at VCF East when Ken told the story of how the move from Berkeley to Bell Labs happened. Ken's description of his interactions with the Bell recruiter was entertaining and made clear that persistent effort was needed to get him to come out to New Jersey and meet some of the people there. Does anyone know who the recruiter was?

5 years, 2 months

Fwd: Great deal on Unix! / Boing Boing

by Clem Cole

I felt that I had to pass this along... https://boingboing.net/2020/05/10/great-deal-on-unix.html

5 years, 2 months

uhs@tuhs.org

by Doug McIlroy

Subject: Re: [TUHS] sml/nj and unix/plan9 sml was in the the tenth edition. I used it a bit. I didn't find it unreasonably slow. Doug

5 years, 2 months

sml/nj and unix/plan9

by gdiaz＠qswarm.com

hello Was sml/nj part of UNIX at some point? was it considered as a language to use (proof tools may be)? I was wondering if there is any history in common between the two. I've been unable to find anything :-?, please share your stories! :-D Is it true that the language was too slow to be generally useful? There seems to be commentaries along these lines on the internet. thanks! gabi

5 years, 2 months

Re: [TUHS] DEC Compilers (was: Re: SDB debugger

by Doug McIlroy

>> Compile time was measured. My favorite "bug" was the >> many minutes it took to compile a constant expression >> that involved shifting a constant INT_MAX bits by >> performing that many 1-bit shifts. > > I don't know if this anecdote is an urban legend or if it really > happened. I was told [a similar] story when I was interning as an operator > at my alma mater, which was an IBM System/360 shop. I heard it not from the grapevine, but from McKeeman himself. Doug

5 years, 2 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS