In the last months, I've spent a little time on curating John Walker's Unix clone and software stack, including an emulator to run it:
https://gitlab.com/marinchip
After creating a basic tool chain (edit, asm, link and a simple executive), John set out to find a compiler. Among the first programs were a port of the META 3 compiler-generator (similar to TMG on early Unix) and a port of Birch-Hansen’s Pascal compiler. META was used to create a compiler that generated threaded code. He found neither compiler good enough for his goals and settled on writing his Unix-like OS in assembler. As the 9900 architecture withered after 1980, this sealed the fate of this OS early on -- had he found a good compiler, the code might have competed alongside Coherent, Idris, and Minix during the 80’s.
This made me realise once more how unique the Ritchie C compiler was. In my view its uniqueness combines three aspects:
1. The C language itself
2. The ability to run natively on small hardware (even an LSI-11 system)
3. Generating code with modest overhead versus handwritten assembler (say 30%)
As has been observed before, working at a higher abstraction level makes it easier to work on algorithms and on refactoring, often earning back the efficiency loss. John Walkers work may be case in point: I estimate that his hand-coded kernel is 10% larger than an equivalent V6 Unix kernel (as compiled for the 9900 architecture).
There are three papers on DMR’s website about the history of the compiler and a compare-and-contrast with other compilers of the era:
https://www.bell-labs.com/usr/dmr/www/primevalC.htmlhttps://www.bell-labs.com/usr/dmr/www/chist.htmlhttps://www.bell-labs.com/usr/dmr/www/hopl.html
It seems to me that these papers rather understate the importance of generating good quality code. As far as I can tell, BCPL and BLISS came close, but were too large to run on a PDP-11 and only existed as cross-compilers. PL/M was a cross-compiler and generated poorer code. Pascal on small machines compiled to a virtual machine. As far as I can tell, during most of the 70s there was no other compiler that generated good quality code and ran natively on a small (i.e. PDP-11 class) machine.
As far as I can tell the uniqueness was mostly in the “c1” phase of the compiler. The front-end code of the “c0” phase seems to use more or less similar techniques as many contemporary compilers. The “c1” phase seems to have been unique in that it managed to do register allocation and instruction selection with a pattern matcher and associated code tables squeezed into a small address space. On a small machine, other native compilers of the era typically proceeded to generate threaded code, code for a virtual machine or poor quality native code that evaluated expressions using stack operations rather than registers.
I am not sure why DMR's approach was not more widely used in the 1970’s. The algorithms he used do not seem to be new and appear to have their roots in other (larger) compilers of the 1960’s. The basic design seems to have been in place from the very first iterations of his compiler in 1972 (see V2 tree on TUHS) and he does not mention these algorithms as being special or innovative in his later papers.
Any observations / opinions on why DMR’s approach was not more widely used in the 1970’s?
Hi all,
I was working with my IRIX 4 machine recently and noticed a mysterious file
- /usr/lib/ecfe. It turns out that this is the Edison Design Group C (not
C++) Front End, included almost certainly by accident with the last release
of the Developer Toolkit for IRIX 4. No other piece of the compiler
toolchain references the EDG product in any way and there is no
documentation for it whatsoever.
The research that I did seems to indicate that this is a source to source
translator, akin to the contemporary Kuck & Associates product - is that
correct? I also found a reference to EDG's tool being used in the Apogee C
compiler. I have a copy of Apogee C for SunOS and it does appear that
"cfe" is the same EDG product. Unfortunately there is no documentation
specific to the C front end, and I don't have a license for Apogee C so I
can't run the compiler to see how it's calling cfe. Just running a C file
"blah.c" through the IRIX front end with no switches results in a
transformed file "blah.int.c". Unfortunately running anything even
moderately complex through the front end results in code that either
doesn't compile or doesn't run, so I feel that I must be missing some flags
or basic options.
Does anyone have any information about SGI's use of this software, or any
documentation/information in general about the EDG product? My usual
sources came up empty.
-Henry
> From: Kevin Bowling
> https://gunkies.org/wiki/BSD/386 and the parent page on seem to suggest
> it originated off Net/2 directly.
I wouldn't be putting too much weight on what that page says; most of the
*BSD pages were done by people I don't know well, and who might have gotten
details wrong
I myself later just tried to quickly, without much effort, work out roughly
what the relationship was between those *BSD systems, based on what other
people had written. E.g the now-'BSD/OS' page was originally at '386/BSD',
and I seem to have worked out that it's correct name was BSD/OS and moved it
there. The BSD/386 page is probably roughly correct, since it contains a scan
of a contemporary ad for it.
(So confusing that '386BSD' is something different from 'BSD/386'. Was there ever
actually a '386/BSD'?)
Someone who knows the early history of all the *BSD systems (as in, you lived
through all that) is welcome, nay invited, to fix any errors therein.
Noel
> From: Noel Chiappa
> Was there ever actually a '386/BSD'?
I decided (for not particular reason) to take a quick read through Marshall
Kirk McKusick's "Twenty Years of Berkeley Unix From AT&T-Owned to Freely
Redistributable":
https://www.oreilly.com/openbook/opensources/book/kirkmck.html
and he refers to Jolitz's system as "386/BSD" (apparently incorrectly). (So
there's a lesson there; even people who '_were_ there' can occasionally get it
wrong - something that professional historians are well aware of. I have a
funny story of my learning that lesson, here:
http://www.chiappa.net/~jnc/nontech/tmlotus.html
in a totally different technical area.)
I have yet to see a _scan_ of contemporary documentation (I believe nothing
that isn't a contemporary _physical artifact_) that confirms it was actually
named "386BSD", but that does seem to be the name as given in the Dr. Dobbs
series on it. That series confirms that it was based directly on the 'Net/2'
BSD release (although 'diff's on the sources are probably the most reliable
proof).
Noel
I have been playing around a bit with this in VirtualBox.
Maybe due to the backing company, I had assumed it was a commercial FreeBSD
variant. But looking a bit harder, it seems like it was a distinct strain
of 386bsd like NetBSD and FreeBSD. There seems to be scant information
about it online. Does anyone know if its story is told somewhere?
Regards,
Kevin
hello everyone,
i recently came across a little window manager, written in Alef, that
i've had in my /tmp folder
for the last five years. it's called Y (probably as a response to X),
and i grabbed it from
9gridchan's public griddisk; run by the late mycroftiv until 2022.
i think it must've been an experimental project by Pike, Rosenthal or
Tom Duff, but i can't find
any documentation about it anywhere. i'd love to know if any of you
remembers this, and if so,
would you share the story behind it?
i uploaded the source code here: http://antares-labs.eu/isometric/Y.tgz
and it runs on 2nd ed plan 9 without issue (see the attached screenshot.)
cheers!
-rodri
> From: Kevin Bowling
> I wonder if we should collect resources like this on a wiki page or
> something?
My habit on the CHWiki is to have the articles on subjects where there is a
lot of documentation online is to have the articles mostly be 'executive
summeries', and corral the links to the stuff online to a section at the end,
so that people who want to see the gory details can look at the original
documentation. See, for example:
https://gunkies.org/wiki/AN/FSQ-7
That works well, even for material that later goes 404, because with the URL,
one can generally find it later in the Internet Archive (things like Google
won't find things that are only there).
Don't ask me to add them, though; I still haven't found time to add the links
to the BSD/OS stuff you found!
Noel
> From: Rodrigo Lopez
>> Google tells me: https://www.y-windows.org/
> from .. the code, that one has nothing to do with this.
It actually makes sense that there are two separate ones called 'Y'. The X
Window System was a descendant of the W window system, so if someone wanted
to do another one, 'Y' was the obvious namee to pick. All it needs now is two
separate people who decide they want to do a window system... voila!
Noel
On Aug 31, 2024, at 11:16 AM, Jaap Akkerhuis <jaapna(a)xs4all.nl> wrote:
>
>> On 31 Aug 2024, at 20:09, Angel M Alganza <ama(a)ugr.es> wrote:
>>
>> On 2024-08-31 11:59, Rodrigo G. López wrote:
>>
>>> i'd love to know if any of you remembers this, and if so, would you share the story behind it?
>
> Google tells me: https://www.y-windows.org/
This is likely a different Y window sys than what Rodrigo found,
which is written in Alef and runs on 2nd ed plan9. Rodrigo may
want to trawl through 9fans mailing list/usenet group archives
or ask there.
