TUHS

tuhs@tuhs.org

32 participants
6541 discussions

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, 2 months

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, 2 months

Re: [TUHS] v7 K&R C

by Doug McIlroy

They are flagging non-portable usage.

5 years, 2 months

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, 2 months

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, 2 months

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, 2 months

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, 2 months

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, 2 months

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, 2 months

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, 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