I assume people have seen this?
https://github.com/ryomuk/TangNanoDCJ11MEM/tree/main
It's capable of running Unix v1 & some limited amount of v6 among other
things. The FPGA in question the Tang Nano 20k is sub 30GBP delivered from
AliExpress.
Kind of neat to combine a real processor with a simple FPGA implementation
of the hardware.
Ken,
Was smalgol also known as BC Algol, as described here:
https://www.softwarepreservation.org/projects/ALGOL/algol60impl/#BC_ALGOL
> On Mar 9, 2025, at 12:06 PM, Ken Thompson <kenbob(a)gmail.com <mailto:kenbob@gmail.com>>
> wrote:
>
> how about smalgol?
>
> it was an algol-like language with just int and float types.
> i dont know its history, but it came out of berkeley near
> when Niklaus Wirth was there. it compiled for the ibm 7094
> in normal batch processing fashion. i converted it to a jit
> into memory in order to skip the loading phase. i used
> it for a lot of my fun-work. (1965-66)
>
> mainframe time, then, was a big factor in the computing process.
> smalgol could compile, load, and run in about 1 cpu-second.
>
> smalgol was all ibm-cards, but it was on my mind through
> the bcpl to b to nb phases. i would use the modern word
> "influencer.”
Paul McJones
Adding to Brian's remarks.
Both PL/I, which had been adopted by Multics, and BCPL/B were very
familiar. PL/I , even gutted as it had been for Multics, was much too big
to contemplate. BCPL's integration of subscripting and pointers was nice,
as was its closeness to the machine. Typlessness was a drawback: how would
one integrate floating point or characters? Another was the global vector,
like Fortran COMMON.
Algol W was known (to me, at least) only via its publication in CACM. I
don't recall it having been considered. Because Algol W had more concepts
than BCPL,was not as closely matched to machine-level coding, and (I
believe) was equally lacking in separate-compilation facilities, I suspect
it would not have made the cut.
Doug
I asked BWK if he had any thoughts about possible alternative
languages. Here is his response, forwarded by permission.
Arnold
> Date: Sun, 9 Mar 2025 08:27:57 -0400 (EDT)
> From: Brian Kernighan <bwk(a)cs.princeton.edu>
> To: arnold(a)skeeve.com
> cc: crossd(a)gmail.com, Brian Kernighan <bwk(a)cs.princeton.edu>
> Subject: Re: An interesting history question
>
> Dan raises an interesting question. I don't have a good answer,
> but there are possibilities.
>
> Typeless languages like BCPL were in the air; Bliss, from CMU in
> 1970, was a significant example, used mostly on the PDP-10 but it
> could run on a PDP-11. It was definitely a contender for doing
> systems work.
>
> I used MAD in the summer of 1966 at MIT and remembered it as being
> much nicer than Fortran, though when I looked at a description a
> while ago, it wasn't clear what the attraction was.
>
> Bell Labs (Doug McIlroy and Bob Morris, mostly) made a PL/I subset
> called EPL that was at least compilable and a lot easier to manage
> than the full language. I don't know whether that would have
> worked, but it would seem that Ken didn't think so, since he went
> off on his own direction. Doug would know more; he sent me some
> corrective info a month ago, on the errata page here:
>
> https://www.cs.princeton.edu/~bwk/memoir.html
>
> Fortran would have needed major work to handle non-numeric data.
> I wrote a text formatter in it by hacking with the Logical*1 type;
> that let me handle one character at a time by basically lying,
> though I've long since forgotten the details.
>
> Pascal was hopeless, as I have described elsewhere, though
> variants that repaired some of the type system might have worked.
>
> The US military used Jovial; it sounds like it's still sort of in
> use, since it handles the avionics in a lot of planes. It looks
> like a direct descendant of Algol 58.
>
> I never used Algol/W, but of all the options, it seems like it
> might have been the strongest contender.
>
> Xerox PARC had Mesa, but my dim memory is that it was big and
> complicated, which is the opposite of what was needed at the time.
> It also came along too late, mid to late 1970s. It did influence
> Java and Modula-2, says Wikipedia.
>
> HOPL 1 includes papers on other languages of the time, most of
> which would not have worked, and/or have died by now. There's a
> lot of history, and I have no idea how to get on top of it all.
> But still interesting to look at and speculate about.
>
> Brian
>
>
> On Sat, 8 Mar 2025, arnold(a)skeeve.com wrote:
>
> > Hi Brian.
> >
> > Any thoughts on this?
> >
> > (cc-ing Dan, the original poster)
> >
> > Thanks,
> >
> > Arnold
> >
> >> From: Dan Cross <crossd(a)gmail.com>
> >> Date: Sat, 8 Mar 2025 22:46:58 -0500
> >> To: TUHS <tuhs(a)tuhs.org>
> >> Subject: [TUHS] What would early alternatives to C have been?
> >>
> >> As I mentioned in the discussion about C, it's easy to look back with
> >> a modern perspective and cast aspersions on C. But this got me
> >> thinking, what would possible alternatives have been? In the context
> >> of the very late 1960s heading into the early 70s, and given the
> >> constraints of the PDP-7 and early PDP-11s, what languages would one
> >> consider for implementing a system like early Unix? Dennis's history
> >> paper mentioned a very short-lived effort at Fortran, and I asked
> >> about that a few years ago, but no one really remembered much about
> >> it; I gather this was an experiment that lasted a few days or weeks
> >> and was quickly abandoned. But what else?
> >>
> >> My short list included PL/1, Algol/W, Fortran, and Pascal. Fortran was
> >> already mentioned. I don't think PL/1 (or PL/I) could have fit on
> >> those machines. Pascal was really targeted towards teaching and would
> >> have required pretty extensive work to be usable. The big question
> >> mark in my mind is Algol/W; how well known was it at the time? Was any
> >> consideration for it made?
> >>
> >> Obviously, the decision to go with BCPL (as the basis for B, which
> >> beget C) was made and the rest is history. But I'm really curious
> >> about how, in the research culture at the time, information about new
> >> programming languages made its way through the community.
> >>
> >> - Dan C.
> >>
> >
>
> From: Larry McVoy
> Not once did I think about packing, the structs somehow just worked on
> the machines I was working on. Maybe the TCP/IP guys knew about spacing
> in the structs.
Not really! Of the first 6 TCP/IP implementations:
https://gunkies.org/wiki/TCP_and_IP_bake_offs
only 1 was in C - and it was a relatively late one. The earliest ones were
mostly in assembler (PDP-10 and PDP-11).
Noel
> From: Phil Budne
> BUT, the basic TCP and IP protocols seem to have been created with a
> general care that two byte fields should be aligned at multiples of two
> bytes
Yes, because dealing with a 16-bit field that spans two PDP-11 16-bit words
is a pain (espcially because the PDP-11 does not have a 'load byte into
register _without_ extending the sign bit into the high half' instruction).
Do realize that in addition to the early TCP implementation, the _first_ TCP
router (at that stage, TCP and IP were not separate protocols) was also a
PDP-11 (albeit programmed in BCPL, not MACRO-11).
I remember the extension being a real PITA. To load an un-aligned 16-bit
quantity into R0, one would have had to do something like (assuming a pointer
to the un-aligned 16-bit quantity was in R1):
MOVB (R1)+, R0
SWAB R0
BIC #0377, R0
BISB (R1)+, R0
There may have been a better way to do it, but that's the best I can come up
with now; I recall we had to do something like that.
Yes, the 16-bit fields were 16-bit word aligned.
Noel
the code in the repo is for the FPGA, the processor that is strapped to the
FPGA well it runs the real code.
It's like the 'minimig' Amiga emulator platform, a real processor, and FPGA
to do all the IO heavy lifting.
So it's not 100% FPGA but you are executing code on a real processor so you
aren't exactly full emulation either. And it doesn't cost a fortune,
assuming you can find one of these ancient microprocessors.
-----Original Message-----
From: emanuel stiebler
To: Jason Stevens; 'tuhs(a)tuhs.org'
Sent: 3/5/25 2:50 PM
Subject: Re: [TUHS] DCJ-11 processor with 20k FPGA
On 2025-03-01 07:11, Jason Stevens via TUHS wrote:
> I assume people have seen this?
>
> https://github.com/ryomuk/TangNanoDCJ11MEM/tree/main
>
>
> It's capable of running Unix v1 & some limited amount of v6 among
other
> things. The FPGA in question the Tang Nano 20k is sub 30GBP
delivered from
> AliExpress.
>
> Kind of neat to combine a real processor with a simple FPGA
implementation
> of the hardware.
I just had a look at it, but he doesn't show the code, which runs on the
TangNano?
> From: Rob Pike
> The notion that the struct layout must correspond to the hardware
> device's layout is about as non-portable as thinking can get.
I'm confused; I thought device register layout is inherently about as
non-portable a thing as one could have, generally.
(Exceptions: 1) the device is basically a single chip, so interfaces on two
machines might be essentially identical, if they use the same chip; 2) someone
made a 68K card that plugged into a QBUS, so drivers on a PDP-11 and that 68K
could be identical.)
Or did you mean that one could somehow disassociate the struct layout and the
details of the device (assuming it has addressable registers, as became
common)? How (I'm missing it)?
Noel
