I just stumbled across an old letter, from a VP of Burroughs to me and
Steve Bartels, authorizing $30,000 for a port of Unix to the E-mode stack
machine. I had forgotten getting it.
Burroughs was famed for its stack machines. E-mode was a kind of last gasp
attempt to save the stack architecture, which failed as far as I know, see
this table:
http://jack.hoa.org/hoajaa/Burr126b.html
I worked as a hardware engineer on the A15. I also had been a Unix user for
7 years at that point and kept pointing out how awful the Burroughs CANDE
time-sharing system was, and how much better Unix was. At some point I
guess they asked me to put up or shut up. I got that money, and left
Burroughs a week later for grad school.
Funny note: A15 was Motorola ECL (MECL), and ran at 16 Mhz., considered
fast at that time. We used a technique called "stored logic" which was,
believe it or not, using MECL RAM to map logic inputs to outputs, i.e.
implement combinational logic with SRAM. Kind of nuts, but it worked at the
time. We also used a precursor of JTAG to scan it in. Those of you who know
JTAG have some idea of how fun this had to be.
One side effect of working with MECL is you realized just how well designed
the TI 7400 SSI/MSI parts were ... MECL always just felt like an awkward
family to design with.
Another funny story, pointing to what was about to happen to Burroughs. We
had an app that ran for hours on the stack machine. We quick ported it to a
VAX, started it up, and headed out to lunch -- "this will take a while,
let's go eat." We got to the front door and: "Oh, wait, let me hop back
into the office,I forgot my jacket". And, noticed, the program was done in
... about 3 minutes. Not 8 hours.
That's when we knew it was game over for Burroughs.
If a picture of this letter would be useful in some archive somewhere, let
me know, I can send it.
The security vulnerability in question could be briefly summarized as,
"Fortran divide-by-zero gives root." I think that was just a specific
manifestation of the underlying problem, though. More specifically it
was actually due to failure to sanitize state after handling a SIGFPE
(and possibly other signals as well?).
I have a distinct memory of this, but can no longer find any evidence
for it. Did I just make it up from whole cloth, or was this actually a
thing?
- Dan C.
London and Reiser report about porting the shell that “it required by far the largest conversion effort of any supposedly portable program, for the simple reason that it is not portable.” By the time of SysIII this is greatly improved, but also in porting the SysIII user land it was the most complex of the set so far.
There were three aspects that I found noteworthy:
1. London/Reiser apparently felt strongly about a property of casts. The code argues that casting an l-value should not convert it into a r-value:
<quote from "mode.h">
/* the following nonsense is required
* because casts turn an Lvalue
* into an Rvalue so two cheats
* are necessary, one for each context.
*/
union { int _cheat;};
#define Lcheat(a) ((a)._cheat)
#define Rcheat(a) ((int)(a))
<endquote>
However, Lcheat is only used in two places (in service.c), to set and to clear a flag in a pointer. Interestingly, the 32V code already replaces one of these instances with a regular r-value cast. So far, I’d never thought about this aspect of casts. I stumbled across it, because the Plan 9 compiler did not accept the Lcheat expansion as valid C.
2. On the history of dup2
The shell code includes the following:
<quote from “io.c”>
rename(f1,f2)
REG INT f1, f2;
{
#ifdef RES /* research has different sys calls from TS */
IF f1!=f2
THEN dup(f1|DUPFLG, f2);
close(f1);
IF f2==0 THEN ioset|=1 FI
FI
#else
INT fs;
IF f1!=f2
THEN fs = fcntl(f2,1,0);
close(f2);
fcntl(f1,0,f2);
close(f1);
IF fs==1 THEN fcntl(f2,2,1) FI
IF f2==0 THEN ioset|=1 FI
FI
#endif
}
<endquote>
I’ve check the 8th edition source, and indeed it supports using DUPFLG to signal to dup() that it really is dup2(). I had earlier wondered why dup2() did not appear in research until 10th edition, but now that is clear. It would seem that the dup of 8th edition is a direct ancestor to dup() in Plan 9. I wonder why this way of doing things never caught on in the other Unices.
3. Halfway to demand paging
I stumbled across this one because I had a bug in my signal handling. From early days onwards, Unix supported dynamically growing the stack allocation, which arguably is a first step towards building the mechanisms for demand paging. It appears that the Bourne shell made another step, catching page faults and expanding the data/bss allocation dynamically:
<quote from “fault.c”>
VOID fault(sig)
REG INT sig;
{
signal(sig, fault);
IF sig==MEMF
THEN IF setbrk(brkincr) == -1
THEN error(nospace);
FI
ELIF ...
<endquote>
This was already present in 7th edition, so it is by no means new in 32V or SysIII -- it had just escaped my attention as a conceptual step in the development of Unix memory handling.
Here’s a stretch, but does anybody have a copy of the 1982-ish C With
Classes Reference Manual kicking around. I can take it in n/troff or a
more modern format if you have it.
> segaloco via TUHS writes:
>> I think that's a good point that scripting problems may be
>> a symptom of the nature of the tools being used in them.
> I think that you're hinting at something different.
> To the best of my recollection, scripting languages were originally
> intended and used for the automation of repetitive personal tasks;
> making it easier for users who found themselves typing the same
> stuff over and over again.
Indeed!
> Somewhere along the line people forgot
> how to use a compiler and began writing large systems in a variety
> of roughly equivalent but incompatible interpreted languages. Can
> one even boot linux without having several different incompatible
> versions of Python installed today? So I don't think that it's the
> nature of the tools; I think that it's people choosing the wrong
> tools for the problems that they're trying to solve.
> Jon
The forgotten compilers were typically used to supply glue
to paste major tools together. The nature of that glue---often
simple data reformatting--inspired tools like sed and awk.
Each use of a tool became a process that saved many minutes
of work that would in a scriptless world be guided by hand,
boringly and unreliably.
Yet glue processes typically did only microseconds of
"real" work. In the name of efficiency, the operations began
to be incorporated directly into the shell. The first
inklings of this can be seen in "echo" and various forms
of variable-substitution making their way into the v7
shell. The phenomenon proliferated into putting what were
typically canned sed one-liners (but not sed itself) into
the shell.
Lots of specializations crowded out universality. A side
effect was an explosion of knowledge required to write
or understand code. Such is the tragedy of "forgetting
compilers".
Doug
Someone dumped a bunch of Unix/Plan 9/FORTRAN/FOCAL documents on github:
https://github.com/kenmartin-unix/UnixDocs
I haven't looked at them closely to see what may be there, but this
may interest some TUHS readers.
- Dan C.
I'd love to get my hands on a 3B2 someday, this'll be cool if I can get it going but that'd be a much more robust machine.
I'm starting to suspect if there isn't any sort of boot ROM that spits out commentary on the UART and that doesn't get flexed until UNIX is up, I may not be able to get very far. I referred to http://bitsavers.trailing-edge.com/pdf/att/3b1/999-809-010IS_UNIX_PC_Remote… for the serial settings and it appears:
9600 baud, 1 stop bit, no parity, 8 data bits
And the relevant pins
Pin 1 - GND
Pin 2 - RX
Pin 3 - TX
Pin 4 - RTS
Pin 5 - CTS
Pin 6 - DSR
Pin 7 - GND
Pin 8 - DCD
Pin 20 - DTR
So I've plugged my USB-TTY GND/RX/TX into the relevant pins and setup the necessary tty settings. The manual then suggests if running null modem mode to short pin 4 to 5 and then pins 6, 8, and 20 together, presumably omitting any need for modem signalling from the remote machine, doing basic serial RX/TX. Unfortunately even with all of this bypassing I get nothing out of the RS-232 port. What I don't know is if I could even expect something or if this is unlikely to bear fruit whether the hardware works or not. In any case, if I do get this thing running I'll have a writeup for folks afterwards. If not, then hopefully I can figure out something useful to do with this thing rather than junking it.
- Matt G.
------- Original Message -------
On Tuesday, January 3rd, 2023 at 3:53 PM, rob(a)atvetsystems.com <rob(a)atvetsystems.com> wrote:
> Hello Matt,
>
> I’ve got one of these in my garage. I bought it about twenty years ago as a working system but when I got it home I noticed that the hard disk wasn’t connected but at some point I’d like to get it and my 3b2/300 working.
>
> Regards, Rob.
>
>> On 3 Jan 2023, at 23:27, segaloco via TUHS <tuhs(a)tuhs.org> wrote:
>>
>> And here are some pictures of the guts.
>>
>> https://imgur.com/a/E1ioxZl
>>
>> Various bits inside date this to late 1985. The good news is it at least turns on, but that's about as far as I've gotten with it. The display never turns on, nor do I hear any sounds indicating it tries to start the CRT. The fans kick on and there it stays until I turn it off. I plugged in a USB-TTY to pins 2, 3, and 7 (RX/TX/GND) and listened at 9600 baud 8 bit 1 stop no parity and got nothing. Swapped the RX/TX, still nothing. Of course, that's all predicated on the assumption there's something there to even interact with. I have little faith that whatever UNIX install was on this is extant. Additionally, it didn't come with a keyboard, so if there was some futzing with key combos that would trigger some sort of UART over those lines, I can't do that. I wonder if there are some contacts inside I can just poll for activity with this serial connector, not sure how safe that is...
>>
>> Anywho, the CPU has a bit of corrosion on the surface, not sure how that bodes for the innards, but this is in kinda rough shape either way. I hope I can salvage it but if not, I'm going to at least do some study on the CRT particulars and see if I can extract and keep the monitor from it, been wanting a smaller CRT to have around for a while.
>>
>> - Matt G.
>> ------- Original Message -------
>> On Tuesday, January 3rd, 2023 at 12:20 PM, segaloco via TUHS <tuhs(a)tuhs.org> wrote:
>>
>>> Good day everyone, just starting a thread for yet another project I'll be tinkering on over time. Picked up a (presumably broken/untested) 7300 off eBay to at the very least tear down and get some good pictures of and, with some luck, perhaps get working again.
>>>
>>> https://imgur.com/a/CExzebl
>>>
>>> Here are some pictures of the exterior for starters. I'll update this thread when I've got pictures of the guts and also with any info I can glean regarding whether this might be salvageable. The rust on the back is pretty nasty but I've seen older/worse start up just fine.
>>>
>>> - Matt G.
Good day everyone, just starting a thread for yet another project I'll be tinkering on over time. Picked up a (presumably broken/untested) 7300 off eBay to at the very least tear down and get some good pictures of and, with some luck, perhaps get working again.
https://imgur.com/a/CExzebl
Here are some pictures of the exterior for starters. I'll update this thread when I've got pictures of the guts and also with any info I can glean regarding whether this might be salvageable. The rust on the back is pretty nasty but I've seen older/worse start up just fine.
- Matt G.
Does anyone have the original troff of this document? It was written
by Bill Shannon at Sun, documenting the C style conventions for SunOS.
A PDF rendering is here:
https://www.cis.upenn.edu/~lee/06cse480/data/cstyle.ms.pdf
Thanks!
- Dan C.
The /bin/sh stuff made me think of an interview question I had for engineers,
that a surprisingly few could pass:
"Tell me about something you wrote that was entirely you, the docs, the
tests, the source, the installer, everything. It doesn't have to be a
big thing, but it has to have been successfully used by at least 10
people who had no contact with you (other than to say thanks)."
Most people fail this. I think the people who pass might look
positively on the v7 sh stuff. But who knows?
