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/ -
-------------------------------------------------------------------------------
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
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/ -
-------------------------------------------------------------------------------
> 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.
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
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
> 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
> 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).
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
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.
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.
> 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
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?
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
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?
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
>> 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
> random small C programs with computable expected outputs
"computable" is subtle here. The only way to compute the
outputs was to run the program. McKeeman's trick was to
sic several completely unrelated compilers on the program
and let them vote on the answer.
Compile time was measured. My favorite "bug" was the
mmany minutes it took to compile a constant expression
that involved shifting a constant INT_MAX bits by
performing that many 1-bit shifts.
Doug
Doug's list is slightly off:
adb v7-v10
sdb v8-v10
sdb may actually have been in V7; I'm quite sure
it was present in 32/V. But it's not in the V7
manual.
adb and sdb were certainly working fine when I
arrived in 1127, but they still used ptrace
because nobody wanted to touch the code. I used
adb quite often (still would were it available
in modern worlds!), so I cared enough to take
it over, restructuring it quite a bit to make it
easier to retarget for different instruction
sets and byte orders, and of course to use /proc.
I also made some trivial, compatible changes to
how numbers were read and printed to conform to
Rob's Rule (of which I am also a fan) that what
a program presents as output it should also
accept as input.
sdb I wasn't as fond of, but I did want to get
rid of ptrace, so I tinkered it just enough to
accomplish that.
I do remember clearly celebrating the death of
ptrace by removing ptrace(2) from the copy of the
V8 manual in the UNIX Room. It took up two
pages, and they happened to be facing pages,
so I glued them together.
I wish it was as easy for others to have such
satisfaction these days.
Norman Wilson
Toronto ON
Brantley Coile just asked:
Looks like the mailman software works!
Say, do you know if there are any copies of the Gnot terminal schematics?
Brantley
I don't know, does anybody else know?
Cheers, Warren
> Sorry, I typed that in haste without testing. I don’t have a 2.11 system to try it on. However, reading the source code, I did that wrong. The args go on the stack, not in line with the code.
> mov $6, -(sp)
> mov a, -(sp)
> mov $1,-(sp)
> sys 4
Without suggesting that every helpful post should be tested, I find the superb https://unix50.org web emulator excellent for such things.
Many thanks to the folks hosting & maintaining this great resource!
> From: Jacob Ritorto
> I wonder if the differences are written up somewhere. I did try to look
> for more documentation but came up short.
Sounds like a perfect topic for a CHWiki page. :-) E.g. this one:
http://gunkies.org/wiki/Unix_V6_internals
which I did as a bit of an addendum to Lions, to explain rsav, qsav and ssav, and
similar topics.
I noticed in the comparison of your two binary files that the instructions
looked the same, but the a.out headers had a difference, but I didn't remember
the fields in the a.out header enough to know what the differences meant.
I thought I remembered doing an a.out page there, but apparently not. I
thought about doing one now, but decided it wasn't worth it; I just needed to
spin up my V6 system and do 'man a.out'! :-)
Noel
