I've managed to acquire a PDP-11/03 with twin floppy drives (Sykes
Datatronics RX01 or RX02 equivalents, not sure yet which).
I've stumbled across LSX, and I have it running on SimH. I'm quite
inexperienced with Unix, but it's something I want to learn well, having
brushed against it at university in the '80s, and having played with Linux
somewhat.
I have some interest in Forth, but I don't like the block system of early
forths such as FigForth, and I plan to create a new Forth based on
FigForth, but supporting external source files.
Anyway, I've tried compiling Hello World on LSX, and I get "1: External
definition syntax" error. Some help would be nice, but more generally, is
anyone on this list more than vaguely familiar with LSX, or 6th Edition
itself?
void main () {
printf("Hello World!");
}
It seems that the 7th Edition was the beginning of the standard library in
C, and that this is missing in LSX. I'm not sure if printf is an intrinsic
function in (6th Edition) C, or if it's from a library.
My questions are a bit random, but looking to converse with others with LSX
experience.
Paul
*Paul Riley*
Email: paul(a)rileyriot.com
>
> In this file, 99 blocks are reserved for swap, corresponding to processes with 24KB memory; total disk size is defined as 500 blocks, 250KB - note that this slightly exceeds the 241KB offered by the standard IBM 77 track 26 sector formatting for 8” disks. Probably you will need to tweak the values in param.h
Oops: 77 tracks by 26 sectors of 128 bytes, makes 250.25KB, so it should work as configured.
Hoi,
personally I use fmt(1) a lot for email formatting and such.
Typically I only use the `-w' parameter. Now someone asked me about
`-t' and `-c' of *GNU* fmt(1). I wasn't able to find good documentation
on them. The manpage only tells that they have to do with different
indentation for the first or first two lines. But what are the use
cases? How would source text for these parameters look like?
A look into the description and rationale sections of POSIX, which
often provides helpful information, was not possible because fmt(1)
is not part of POSIX (only fold(1) is). Why's that? Is it because
fmt(1) differs so much between Unix implementations? On BSD `-c'
centers text and `-t' sets tab widths. Plan 9 has none of these
options. But still, `-w' could have been standardized. Or was the
line filling algorithm different as well? How does fold(1) fit into
the picture?
Maybe you can answer some of these questions or give hints on where
I could find answers myself.
meillo
> I've stumbled across LSX, and I have it running on SimH. I'm quite inexperienced with Unix, but it's something I want to learn well, having brushed against it at university in the '80s, and having played with Linux somewhat.
I think you will experience a sizeable learning curve. You will be working with Unix and C as it stood around 1975 and that is substantially different from what it was in the 80’s. That said, I know from personal experience that it is an intriguing journey and certainly not impossible to do.
> Some help would be nice, but more generally, is anyone on this list more than vaguely familiar with LSX, or 6th Edition itself?
Many on this list are familiar with 6th edition. The best way to learn the internals of 6th edition is the “Lions’ book”:
https://www.amazon.com/Lions-Commentary-Unix-John/dp/1573980137
Coming from today’s perspective (or a 1980’s one), you will find the following key challenges:
- The version of C used for 6th edition is different from the 1980’s. Amongst other things the syntax of the assignment operators changed (not += but =+), the syntax for initialisation changed (not 'int a = 3', but 'int a 3’), the ‘long’ datatype (32 bit on a PDP-11) did not exist, the ‘void’ keyword did not exist, structs could not be assigned, passed or returned (only pointers to structs), etc.
- The stdio library did not exist yet, in its place there was the ‘portable i/o library’. This may be the hardest part to get used to.
- The file system was 16-bit based throughout. This has implications for stat(), lseek() did not exist (its precursor seek() used additional whence values to move the file pointer in 512 byte increments), etc.
When it comes to LSX, there are a few people who have experience with it on the this list (that I know of - there may be many more).
First of all, Heinz Lycklama, the original creator of LSX, appears to read this list from time to time.
Second, Leonid Broukhis and Serge Vakulenko (who managed to recover the LSX sources 20 years ago) might be reading the list. They took the trouble to port LSX to the Soviet BK-0010 computer, an LSI-11 type system some 15 years ago:
https://github.com/sergev/bkunix
You can stand on their shoulders, as they already took the trouble to convert the kernel source from 1975 C to 1980’s C and to create a stdio compatible library for it; they are using the 2.11BSD C compiler, which generates tighter code than the 1975 compiler — hence they could squeeze a bit more functionality in.
Third, I found the BK-0010 port some 5 years ago and used that as base to create a version that would run on a small TI990 clone:
http://www.stuartconner.me.uk/mini_cortex/mini_cortex.htm
This work later evolved into a stock 6th edition kernel and is now a curious mix of stuff dating from 1975 to 1985.
Your main challenge will be that neither the BK-0010 work nor my work will run on your hardware as-is. I think you have two possible paths forward. The first is to learn C and the library as it stood in 1975, the second is to take the BK-0010 code and to make it run on a stock LSI-11 again.
The title of the fmt man page in v9 was "ultra-simple text formatter".
Gnu dropped the "ultra" in favor of AI. Sometimes it does a pretty
job. Sometimes it messes up my typing style. Always it produces a
an apparently wavering right margin, as it assigns a separate
"optimal" line length to each paragraph. It's hard to imagine how
this command could stray from classic Unix simplicity and
intelligibility, but Gnu pulled it off.
Doug
re: main.
i was surprised not to see any mention of the entry keyword reserved but, i believe, never used in early c. it is listed in k&r ed1.
i always assumed this was to allow the author to choose an alternative to main() for the program’s entry point, but we all know what assumption is...
-Steve
> From: Tyler Adams
> C is so prolific and influential because it's so easy to write a C
> compiler.
I'm not sure the implied corollary ('it's _not_ easy to write compilers for
other languages') is correct.
As a datapoint, I pulled "Algol 60 Implementation" (Randell and Russell) off
the shelf, and it reveals that the Algol 60 compiler discussed there (for the
KDF9), using lessons from the Algol compiler for the Electrologica X1, was
3600 words (roughly 3 instructions/word). So it was small.
Now, small is not necessarily equivalent to easy, but it was clearly not a
mountainous job. I imagine early BCPL, etc compilers were roughly similar.
The only language from that era which I can think of which was a slog,
compiler-wise, was PL/I.
I suspect the real reason for C's sucess was the nature of the language.
When I first saw it (ca. 1976), it struck me as a quantum improvement over
its contemporaries.
Noel
C main programs define “main”.
This also seems to be true of B main programs, according to the Johnson/Kernighan manual
The 1967 Martin Richards BCPL manual doesn’t explain how programs get started
The 1974 update from Martin Richards says there should be an OS addendum that explains this.
The 1974 University of Essex BCPL manual says to use START
The 1979 Parc Alto BCPL manual uses Main and I think that must be unchanged from 1972.
The AMSTRAD BCPL guide from 1986 uses start()
So who started “main” and when? I can’t find an online copy of the Bell Laboratories BCPL manual (Canaday/Thompson) from 1969 or anything about how to use BCPL on Multics or CTSS.
-L
Lawrence Stewart <stewart(a)serissa.com> asks on Fri, 22 May 2020 14:43:40 -0400:
>> So who started "main" and when?
I have just checked several PDFs of IBM mainframe and Fortran manuals
going back to 1954.
The early manuals did not appear to use the name "main", but in
ibm-7030/C22-6578_7030_Programming_Examples_Apr61.pdf, the phrase "the
main program" occurs in the context of assembly language coding.
In ibm-7030/C22-6751_7030_FORTRAN_IV_May63.pdf, on page 22,
which begins with
Part II. FORTRAN Programming for the IBM 7030
the first paragraph ends with "the main program".
In silliac/SPMpart1-ocr.pdf, titled
Silliac Programming Manual
The Adolph Basser Computing Laboratory
School of Physics
The University of Sydney
and dated January 1959, on page 99, I find
>> ...
>> In this way a program is seen to consist of several distinct,
>> self-contained blocks, namely the various subroutines and the part of
>> the program (usually called the main program or master routine) which
>> ^^^^^^^^^^^^^^^^
>> makes use of its subroutines by sending control to them.
>> ...
I have many manuals for older systems, but most have not been
subjected to optical-character recognition, so it is difficult to find
specific text in them. Nevertheless, I have demonstrated that by at
least January 1959, the phrase "main program" was common enough to
appear in computer documentation, qualified by "usually".
Some day, perhaps I'll find time to do OCR conversion on my extensive
PDF file archives.
I'll be pleased to hear of earlier uses of "main program" from TUHS
list members.
-------------------------------------------------------------------------------
- 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/ -
-------------------------------------------------------------------------------
> I went looking for the three IPC reports:
>
> For more information about this system, see:
> - "Interprocess Communication Extensions for the UNIX Operating System: I -
> Design Considerations", Rand Corporation, Report R-2064/1-AF, June 1977.
> - "Interprocess Communication Extensions for the UNIX Operating System: II
> - Implementation", Rand Corporation, Report R-2064/2-PR, April 1977.
> - "UNIX TCP User's Guide", Bolt Beranek and Newman Inc., Report No. 3724
>
>
> And could only find the first one online at
>
> https://apps.dtic.mil/dtic/tr/fulltext/u2/a044200.pdf
>
> Do we have the other two anywhere?
Yes we do.
The first two are about Rand ports. You’ve found the overview by Carl Sunshine, the implementation by Steve Zucker is the next report up on DTIC:
https://apps.dtic.mil/sti/pdfs/ADA044201.pdf
The TCP User guide report you refer to is about a TCP implementation done by Jack Haverty, which took an implementation in PDP-11 assembler and wrapped it in a NCP Unix shell. Jack has a listing in his attic, but it is not scanned. The problem with this implementation was that it is was all very cramped in the kernel, so he had to reduce disk buffers substantially. As pipes (and Rand ports) use disk buffers to hold pipe data, which get swapped out to disk as needed, he found that his system trashed a lot and effective TCP speeds in his first trials were barely above few dozen byte per second.
The report is actually on the TUHS tree:
https://www.tuhs.org/cgi-bin/utree.pl?file=BBN-V6/doc
(there is also nroff source for Steven Zucker’s report, and other interesting material in that directory - such as a report on pipe performance).
The actual V6 implementation that is on that THUS page is not Jack Haverty’s version, but a version done from scratch by Mike Wingfield, using the learning’s of Jack’s work. Mike’s implementation worked quite well and won first prize in a March 1979 tongue-in-cheek TCP4 conformance & interop competition. The BBN report for that version is 4295. Craig Partridge was kind enough to dig it up from the BBN library - I can send you a copy if you like (it was cleared for public release).
Although the implementation was done for research purposes (mainly Autodin II security features and simulation), it seems to have had a long life as a stop-gap to keep aging PDP-11’s connected after the switch from NCP to TCP in 1983.
Paul
I went looking for the three IPC reports:
For more information about this system, see:
- "Interprocess Communication Extensions for the UNIX Operating System: I -
Design Considerations", Rand Corporation, Report R-2064/1-AF, June 1977.
- "Interprocess Communication Extensions for the UNIX Operating System: II
- Implementation", Rand Corporation, Report R-2064/2-PR, April 1977.
- "UNIX TCP User's Guide", Bolt Beranek and Newman Inc., Report No. 3724
And could only find the first one online at
https://apps.dtic.mil/dtic/tr/fulltext/u2/a044200.pdf
Do we have the other two anywhere?
Warner
>> 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
> Speculating wildly, maybe there was a Lisp machine somewhere?
None that I can remember.
Doug
> for some years I've been using the phrase "algebraic syntax" to
> characterize languages such as Algol, C/C++, Fortran, Java(Script), Ruby, etc.
...
> However, I can't find this usage in Wikipedia or elsewhere
I think "Algol-like" is the closest term in common use, though it
doesn't have the exact connotation that I think you intend.
Nowadays, I think of languages like Haskell as being "algebraic"
in the deeper sense of having taken much inspiration from
modern algebra, and being preeminently suitable for application
to algebraic domains.
Vic Vyssotsky used the term "narrative language" as quite
a close synonym of your "algebraic syntax", but I think his
usage was equally idiosyncratic.
Doug
> o operator overloading
>
> 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.
Does your antipathy extend to C++ IO and its heavily overloaded << and >>?
The essence of object-oriented programming is operator overloading. If you
think integer.add(integer) and matrix.add(matrix) are good, perspicuous,
consistent style, then you have to think that integer+integer and
matrix+matrix are even better. To put it more forcefully: the OO style
is revoltingly asymmetric. If you like it why don't you do everyday
arithmetic that way?
I strongly encouraged Bjarne to support operator overloading, used it
to write beautiful code, and do not regret a bit of it. I will agree,
though, that the coercion rules that come along with operator (and
method) overloading are dauntingly complicated. However, for natural uses
(e.g. mixed-mode arithmetic) the rules work intuitively and well.
Mathematics has prospered on operator overloading, and that's why I
wanted it. My only regret is that Bjarne chose to set the vocabulary of
infix operators in stone. Because there's no way to inroduce new ones,
users with poor taste are tempted to recycle the old ones for incongruous
purposes.
C++ offers more features than C and thus more ways to write obscure code.
But when it happens, blame the writer, not the tool.
Doug
> From: Jacob Ritorto
> I had a suspicion that maybe the clock isn't working on the 11/73.
> Would that make sense?
Would definitely explain the symptoms.
> Maybe I have to check jumpers on the 11/73 to be sure its clock is
> enabled?
There is a jumper on the KFJ11-A that enables/disables the clock®ister;
W9 (closest to the handles) should be removed to enable the clock.
(I really need to add the jumpers to the KDJ11-A page on the Computer History
Wiki, mumble....)
Noel
I bought one of Oscar's kits a while back and I just got around to putting
it together. It was kind of neat booting up a straight V6 (it's been a
long time) and playing with those DEC operating systems that I had learned
to hate (Really Sh-ty Timesharing System). I had hoped that someone,
somewhere had a JHU/BRL dist around (well if you do, I'd love to get it).
But since the thing is mostly just a decoration in my office, I just hacked
the idle function in 2.11 BSD to mimic the one that JHU Unix had.
Hi,
I had a disk in my 11/83 that I'd set up for autoboot. The pdp11 would
load block 0, load /boot and happily count down 5 seconds, then continue on
with kernel loading & regular bringing up of the system to multiuser.
That was cool!
So I pulled that disk out and plugged it into my other system with a dual
height 11/73 (this system has same CMD CQD-200 scsi controller) and it gets
to the countdown part and stops! I'm wondering why.
The initial bootblock load is apparently fine and loading and running of
boot is happening.. its just that the countdown stays stuck at five and I
have to hit <cr> to get it to boot (and the rest of the boot sequence is
totally normal).
I had a suspicion that maybe the clock isn't working on the 11/73. Would
that make sense? Maybe boot is actually using a clock somehow? Maybe I
have to check jumpers on the 11/73 to be sure its clock is enabled?
Just thought I'd float the question here in case someone remembers this
oddity before I start digging / "use the source."
thx
jake
There was a recent message I now can't find that I wanted to reply to,
something about which type to use to get a certain effect.
I wanted to reply to say that I felt that it was not really the best way to
go, to have one set of type names that tried to denote both i) the semantics
of the data, and ii) the size of the item, using arbitrary names.
This came up for me when we started to try and write portable networking code.
There, you need to be able to specify very precisely how long fields are
(well, in lower-level protocols, which use non-printable formats). How to do
that in a way that was portable, in the compilers of the day, was a real
struggle. (It might be doable now, but I think the fixes that allowed it were
still just patches to something that had gone in the wrong direction, above.)
I created a series of macros for type definitions, ones that separately and
explicitly specified the semantics and size. They looked like 'xxxy', where
'xxx' was the semantics (signed and unsigned integers, bit field, etc),
and 'y' was a length indication (byte, short, long, and others). So you'd
see things like 'unsb' and 'intl'.
The interesting twist was a couple of unusual length specifiers; among them,
'w' stood for 'the machine's natural word length', and 'f' meant 'no
particular length, just whatever's fastest on this architecture/compiler, and
at least 16 bits'. The former was useful in OSy type code; the latter for
locals and things where nobody outside the machine would see them.
Then you'd have to have a file of macro definitions (only one per machine)
which translated them all into the local architecture/compiler - some didn't
go, of course (no 'unsb' on a PDP-11), but it all worked really, really well,
for many years.
E.g. at one point, as a dare/hack, I said I'd move the MOS operating system, a
version written in portable C (with that type name system) to the AMD 29000
over one night. This wasn't totaly crazy; I'd already gotten the debugger (a
DDT written in similar portable C) to run on the machine, so I knew where the
potholes were. I'd have to write a small amount of machine language (which I
could traslate from the M68K version), but most of it should just compile and
go. I didn't quite make it, it wasn't quite running when people started coming
in the next morning; but IIRC it started to work later that day.
Noel
> 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.
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
> [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
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
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?
