[TUHS] B Source Code

[TUHS] B Source Code

[Robert Swierczek]

Does anyone know of the existence of source code written in B (C's predecessor?)

I have encountered a few snippets here and there, but nothing
substantial.  The only "real" program that I know of is AberMUD-1.  It
looks like there exists a physical print-out of it:

https://dropsafe.crypticide.com/article/12714

Could it be that this is the only artifact left of this most important
"missing link" of C and Unix History?  How can this (and any other B
source) be gathered and preserved?

[TUHS] B Source Code

[Clem Cole]

Poke around the Honeywell archives.  I believe that there was at least one
implementation of QED and a runoff flavor that I saw.   As I believe Steve
Johnson has mentioned,iIt was popular at Waterloo at one point - so check
with the Waterloo folks. In fact, I had thought that Mike Malcom used it
for Thoth, QNX's predecessor.

On Tue, Sep 12, 2017 at 2:03 PM, Robert Swierczek <rmswierczek at gmail.com>
wrote:

> Does anyone know of the existence of source code written in B (C's
> predecessor?)
>
> I have encountered a few snippets here and there, but nothing
> substantial.  The only "real" program that I know of is AberMUD-1.  It
> looks like there exists a physical print-out of it:
>
> https://dropsafe.crypticide.com/article/12714
>
> Could it be that this is the only artifact left of this most important
> "missing link" of C and Unix History?  How can this (and any other B
> source) be gathered and preserved?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170912/fe39b005/attachment.html>

[TUHS] B Source Code

[Clem Cole]

BTW:  Check out:   ybc: a compiler for B <https://github.com/Leushenko/ybc>

On Tue, Sep 12, 2017 at 2:14 PM, Clem Cole <clemc at ccc.com> wrote:

> Poke around the Honeywell archives.  I believe that there was at least one
> implementation of QED and a runoff flavor that I saw.   As I believe Steve
> Johnson has mentioned,iIt was popular at Waterloo at one point - so check
> with the Waterloo folks. In fact, I had thought that Mike Malcom used it
> for Thoth, QNX's predecessor.
>
> On Tue, Sep 12, 2017 at 2:03 PM, Robert Swierczek <rmswierczek at gmail.com>
> wrote:
>
>> Does anyone know of the existence of source code written in B (C's
>> predecessor?)
>>
>> I have encountered a few snippets here and there, but nothing
>> substantial.  The only "real" program that I know of is AberMUD-1.  It
>> looks like there exists a physical print-out of it:
>>
>> https://dropsafe.crypticide.com/article/12714
>>
>> Could it be that this is the only artifact left of this most important
>> "missing link" of C and Unix History?  How can this (and any other B
>> source) be gathered and preserved?
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170912/d90142ea/attachment.html>

[TUHS] B Source Code

[Charles Anthony]

On Tue, Sep 12, 2017 at 11:14 AM, Clem Cole <clemc at ccc.com> wrote:

> Poke around the Honeywell archives.
>

The Multics archive has  BCPL, including a BCPL compiler, but I don't
recall seeing any B code.

The only QED that I see is 'qedx', written in PL/I.


-- Charles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170912/09138171/attachment.html>

[TUHS] B Source Code

[Steve Johnson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3315 bytes --]

As far as artifacts go, I was on a 9 mo. sabbatical at Waterloo when
the big change took place (and having a daughter, to boot).  Coming
back to the labs was a bigger culture shock than going to Canada! 
Most of the B programs I had worked on, including Yacc, had become C
programs in my absence.

I suspect that was the fate of many of the B sources -- a couple of
hours editing, and they became C programs.   Remember that early C
did not have strong typing.  The few B programs I converted, I
remember the biggest difficulty was with character handling -- * was
used in B formats rather than % in C formats.

A harder artifact might be finding early C programs.  Dennis was
brilliant in the way he morphed everyone along with minimal pain, and
I tried to do the same with PCC.   To introduce a new incompatible
feature, first of all build a compiler where both the old and new
features both work.  Tell people that the old stuff still works, but
sell the new stuff.  After a few weeks, add an informational message
along the lines of "Deprecated usage, use ....".   Stay in this
stage for several months, perhaps increasing the emphasis of the
message gradually.  Then tell people that the old stuff will stop
working in 2 weeks.  And in 2 weeks, make the informational message a
fatal error (but don't remove the old code yet...).   Then, a while
later, leave the message but remove the old code.

It amazed me how quickly and (relatively) painless this process
was...  It did mean more work for the compiler writer, though.  The
transition from using hex constants as addresses in the kernel to
using strongly typed structure pointers was especially hairy.

Steve

----- Original Message -----
From:
 "Clem Cole" <clemc at ccc.com>

To:
"Robert Swierczek" <rmswierczek at gmail.com>
Cc:
"TUHS main list" <tuhs at minnie.tuhs.org>
Sent:
Tue, 12 Sep 2017 15:24:05 -0400
Subject:
Re: [TUHS] B Source Code

BTW:  Check out:   ybc: a compiler for B [1]

On Tue, Sep 12, 2017 at 2:14 PM, Clem Cole <clemc at ccc.com [2]>
 wrote:
Poke around the Honeywell archives.  I believe that there was at
least one implementation of QED and a runoff flavor that I saw.   As
I believe Steve Johnson has mentioned,iIt was popular at Waterloo at
one point - so check with the Waterloo folks. In fact, I had thought
that Mike Malcom used it for Thoth, QNX's predecessor. 

On Tue, Sep 12, 2017 at 2:03 PM, Robert Swierczek
<rmswierczek at gmail.com [3]>
 wrote:
Does anyone know of the existence of source code written in B (C's
predecessor?)

 I have encountered a few snippets here and there, but nothing
 substantial.  The only "real" program that I know of is AberMUD-1. 
It
 looks like there exists a physical print-out of it:

https://dropsafe.crypticide.com/article/12714 [4]

 Could it be that this is the only artifact left of this most
important
 "missing link" of C and Unix History?  How can this (and any other B
 source) be gathered and preserved?

 

Links:
------
[1] https://github.com/Leushenko/ybc
[2] mailto:clemc at ccc.com
[3] mailto:rmswierczek at gmail.com
[4] https://dropsafe.crypticide.com/article/12714

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170912/9c6235c3/attachment-0001.html>

[TUHS] B Source Code

[Robert Swierczek]

> I had thought that Mike Malcom used it for Thoth, QNX's predecessor.

Thoth sounds downright fascinating and does indeed look to be written
in B (or a dialect).  Google pointed me to a few research papers
describing the system.  I wonder if the University of Waterloo or
David Cheriton has a snapshot of it from that research?

[TUHS] B Source Code

[Angelo Papenhoff]

On 12/09/17, Clem Cole wrote:
> BTW:  Check out:   ybc: a compiler for B <https://github.com/Leushenko/ybc>
> 

I may me a bit late now, but I would also like to add my B compiler, that
I wrote a few years ago: https://github.com/aap/abc/
I wasn't able to find another B compiler at the time but wanted to run
B code just for fun. I was also studying dmr's C compiler so I took a lot
of inspiration from his code and wrote this (rhe code generation is entirely mine
though, and terribly inefficient).
I haven't compiled it in a while and I suspect it's not as portable as
it should be, but it was only meant as a toy anyway...my first
parser/compiler/language.

I'm still planning to make it output PDP-6/10 code eventually.

aap

[TUHS] B Source Code

[Thorsten Sideboard]

Ok, so this is slightly tangential - i misappropriated 'BCPL' for a
comic book I'm working on, called Bureau for the Containment of
Programmatic Lifeforms - I gave a talk in London recently entitled
BCPL, which featured Martin Richards, the history of BCPL->C, lots of
drawings of computer scientists including everyone's favorite
curmudgeon Ted Nelson, sci-fi world building comic books, algorithmic
music generation, and trying to bring all of them together into a
project called BCPL.

https://www.youtube.com/watch?v=QFj8q9awAUY

thor (long time lurker!)



On Mon, Sep 18, 2017 at 2:45 PM, Angelo Papenhoff <aap at papnet.eu> wrote:
> On 12/09/17, Clem Cole wrote:
>> BTW:  Check out:   ybc: a compiler for B <https://github.com/Leushenko/ybc>
>>
>
> I may me a bit late now, but I would also like to add my B compiler, that
> I wrote a few years ago: https://github.com/aap/abc/
> I wasn't able to find another B compiler at the time but wanted to run
> B code just for fun. I was also studying dmr's C compiler so I took a lot
> of inspiration from his code and wrote this (rhe code generation is entirely mine
> though, and terribly inefficient).
> I haven't compiled it in a while and I suspect it's not as portable as
> it should be, but it was only meant as a toy anyway...my first
> parser/compiler/language.
>
> I'm still planning to make it output PDP-6/10 code eventually.
>
> aap

[TUHS] B Source Code

[Dave Horsfall]

On Fri, 15 Sep 2017, William Pechter wrote:

[ WCS on the 11/60 ]

> I thought Reuters re-microcoded them to be the fastest PDP8 around...

I'd heard that some newspaper house in Australia ordered a bunch, and when 
the contract fell through DEC were stuck with them, so they practically 
gave them away to Universities.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] B Source Code

[Noel Chiappa]

    > From: Dave Horsfall

    > Did anyone actually use the WCS?

Well, the uassembler was a product for a while, so they must have..

    > I had visions of implementing CSAV and CRET on our -60, but never did
    > get around to it. 

I recently had the idea of programming them into an M792 ROM card (100nsec
access time); user programs couldn't have used it without burning a segment
(to map in the appropriate part of the I/O space), but it might have sped up
the kernel some (and it would have been trivial to add, once the card was
programmed - with a soldering iron - BTDT, BITD :-).

Haven't gotten to it yet - still looking for an M792 (I don't want to trash
any of my pre-programmed M792-xx's :-).


    > From: Clem Cole <clemc at ccc.com>

    > A big issue, again IIRC, was the microcode compiler/tools for the WSC
    > ran on RSX so it meant UNIX was not running, which was not popular.

Why not just write a Unix-native one? They aren't that much work - I created a
uassembler overnight (literally!) for the QSIC project Dave Bridgham and I
have been working on.

It's been improved a lot since the first version (e.g. the entire uengine
description is now read in from a config file, instead of being compiled in),
but that first version did work fine...

Or was the output format not documented?

	Noel

[TUHS] B Source Code

[Clem Cole]

Also, in my Tektronix archives... we had an 11/60 with WSC and IIRC Steve
Glaser took a stab at moving the CMU stuff. The microengines between the
11/40 and 11/60 were different, so the code had to be rewritten. A big
issue, again IIRC, was the microcode compiler/tools for the WSC ran on RSX
so it meant UNIX was not running, which was not popular.

But around the same time, unexpected our group had the chance to get an
fairly loaded cast off seperate I/D based 11/70 which had been running
RSTS/Cobol for a business support team in sales.    By the time, Steve got
anything working on the 11/60, I had the 11/70 (aka "teklabs") up and
installed; and I don't remember what happened to the WSC stuff; since we
had better solution to small address space problem of adding a '17th
address bit' with hardware.

Clem

Clem

On Fri, Sep 15, 2017 at 8:44 AM, Clem Cole <clemc at ccc.com> wrote:

> CMU/CS implemented CSAV and CRET on the 11/40e (6th edition++).  IMO - it
> was a mixed bag.  I've forgotten the statistics, it was a few ticks fasters
> for saving the registers, which was good.   The primary thing it did was
> save a small amount of address space on the non-I/D 40  - which was helpful
> for applications as they got larger and were running out of address
> space...... But it was PITA in practice because it meant that binaries
> compiled on IUS and SUS (the UNIX two systems in CS), would not run
> anywhere else on campus which were mostly 11/34 or later 11/34A's and it a
> networked environment (which we were just starting to create) the seams
> tended to show a little more than we would have liked.
>
> IIRC I eventually got a emulator working at Mellon Institute and EE
> systems so they binaries would not core dump, but we just recompiled we ran
> into them.
>
> The real solution to address space issue was when DEC released the 11/44
> which was separate I/D (11/70 class) and the thunk work that we did in
> 2.9BSD in trying to move 4.1/4.2 code to the 11.
>
> FYI:  Danny Klein and I should have the compiler somewhere (and the
> microcode) is I ever get my CMU archives off tape.  It's on my list of
> things to look for.
>
> Clem
>
>
>
> On Thu, Sep 14, 2017 at 11:59 PM, Dave Horsfall <dave at horsfall.org> wrote:
>
>> On Thu, 14 Sep 2017, Noel Chiappa wrote:
>>
>> Interesting factoid: The PDP-11 initially used a threaded FORTRAN
>>> implementation. In line with the observation above (about a new virtual
>>> machine), DEC actually looked into writing microcode for the -11/60 (which
>>> had a writeable control store) to implement the FORTRAN virtual machine.
>>>
>>
>> Did anyone actually use the WCS?  I had visions of implementing CSAV and
>> CRET on our -60, but never did get around to it.  Too late now...
>>
>> --
>> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
>> suffer."
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170915/0da58f8d/attachment.html>

[TUHS] B Source Code

[Clem Cole]

CMU/CS implemented CSAV and CRET on the 11/40e (6th edition++).  IMO - it
was a mixed bag.  I've forgotten the statistics, it was a few ticks fasters
for saving the registers, which was good.   The primary thing it did was
save a small amount of address space on the non-I/D 40  - which was helpful
for applications as they got larger and were running out of address
space...... But it was PITA in practice because it meant that binaries
compiled on IUS and SUS (the UNIX two systems in CS), would not run
anywhere else on campus which were mostly 11/34 or later 11/34A's and it a
networked environment (which we were just starting to create) the seams
tended to show a little more than we would have liked.

IIRC I eventually got a emulator working at Mellon Institute and EE systems
so they binaries would not core dump, but we just recompiled we ran into
them.

The real solution to address space issue was when DEC released the 11/44
which was separate I/D (11/70 class) and the thunk work that we did in
2.9BSD in trying to move 4.1/4.2 code to the 11.

FYI:  Danny Klein and I should have the compiler somewhere (and the
microcode) is I ever get my CMU archives off tape.  It's on my list of
things to look for.

Clem



On Thu, Sep 14, 2017 at 11:59 PM, Dave Horsfall <dave at horsfall.org> wrote:

> On Thu, 14 Sep 2017, Noel Chiappa wrote:
>
> Interesting factoid: The PDP-11 initially used a threaded FORTRAN
>> implementation. In line with the observation above (about a new virtual
>> machine), DEC actually looked into writing microcode for the -11/60 (which
>> had a writeable control store) to implement the FORTRAN virtual machine.
>>
>
> Did anyone actually use the WCS?  I had visions of implementing CSAV and
> CRET on our -60, but never did get around to it.  Too late now...
>
> --
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
> suffer."
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170915/e6e59abe/attachment.html>

[TUHS] B Source Code

[William Pechter]

I thought Reuters re-microcoded them to be the fastest PDP8 around...

So was the DEC Field Service story...

Bill


-----Original Message-----
From: Dave Horsfall <dave@horsfall.org>
To: The Eunuchs Hysterical Society <tuhs at tuhs.org>
Sent: Fri, 15 Sep 2017 0:00
Subject: Re: [TUHS] B Source Code

On Thu, 14 Sep 2017, Noel Chiappa wrote:

> Interesting factoid: The PDP-11 initially used a threaded FORTRAN 
> implementation. In line with the observation above (about a new virtual 
> machine), DEC actually looked into writing microcode for the -11/60 
> (which had a writeable control store) to implement the FORTRAN virtual 
> machine.

Did anyone actually use the WCS?  I had visions of implementing CSAV and
CRET on our -60, but never did get around to it.  Too late now...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] B Source Code

[Dave Horsfall]

On Thu, 14 Sep 2017, Noel Chiappa wrote:

> Interesting factoid: The PDP-11 initially used a threaded FORTRAN 
> implementation. In line with the observation above (about a new virtual 
> machine), DEC actually looked into writing microcode for the -11/60 
> (which had a writeable control store) to implement the FORTRAN virtual 
> machine.

Did anyone actually use the WCS?  I had visions of implementing CSAV and
CRET on our -60, but never did get around to it.  Too late now...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] B Source Code

[Derek Fawcus]

On Thu, Sep 14, 2017 at 10:24:08AM -0400, Dan Cross wrote:
> 
> Was the term "threaded code" in use earlier?

Forth.

Which was say 1968 - 1970 for its inception, how did it's early
versions refer to the technique?  I certainly recall it being
used as the term when I learnt about Forth (which was much later than that).

DF

[TUHS] B Source Code

[Dan Cross]

On Thu, Sep 14, 2017 at 9:39 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
>     > From: Alec Muffett
>
>     > "threaded code" in the old sense could be smaller than the equivalent
>     > CISC binary on the same machine
>
> One can think of 'threaded code' as code for a new virtual machine, one
> specialized to the task at hand.
>
>     > https://en.m.wikipedia.org/wiki/Threaded_code
>
> For those who really want to delve in some depth, see the chapter "Turning
> Cousins into Sisters" (Chapter 15, pg. 365) in "Computer Engineering: A DEC
> View of Hardware Systems Design", by Bell, Mudge and McNamara.

Huh. I happened to have that book on my shelf here at work and it's a great
description. That chapter cites a CACM paper from June 1973; citation here:
http://dl.acm.org/citation.cfm?id=362270

The paper is short; only 4 or so pages.

Now I'm confused about the timeline: I thought B was obsolete by this time
and that C was on the rise. Was the term "threaded code" in use earlier? Ah,
I see a note at the bottom of the paper that it was received in June, 1971 and
revised in December 1972, but not published until June 1973 (2 years after
initial submission). Given that the technique is described in the context of a
FORTRAN IV compiler for the PDP-11 that must have been in existence at
the time it was submitted in 1971, it seems reasonable to believe that the
technique was known in advance.

        - Dan C.

[TUHS] B Source Code

[Noel Chiappa]

    > From: Alec Muffett

    > "threaded code" in the old sense could be smaller than the equivalent
    > CISC binary on the same machine

One can think of 'threaded code' as code for a new virtual machine, one
specialized to the task at hand.

    > https://en.m.wikipedia.org/wiki/Threaded_code

For those who really want to delve in some depth, see the chapter "Turning
Cousins into Sisters" (Chapter 15, pg. 365) in "Computer Engineering: A DEC
View of Hardware Systems Design", by Bell, Mudge and McNamara.

Interesting factoid: The PDP-11 initially used a threaded FORTRAN
implementation. In line with the observation above (about a new virtual
machine), DEC actually looked into writing microcode for the -11/60 (which had
a writeable control store) to implement the FORTRAN virtual machine.

	Noel

[TUHS] B Source Code

[Ronald Natalie]

>> 
>> Threaded?  I'm guessing you mean that it did paging, did that need
>> threads in the current sense?
> 
> Read this:
> https://en.wikipedia.org/wiki/Threaded_code

Yep, used to make heavy use of this back in my first post-college job writing database handlers in Macro11.    Each transaction was just a table of subroutine addresses.
This was about the last thing I had to do on a non-UNIX platform for years.

[TUHS] B Source Code

[Warner Losh]

On Wed, Sep 13, 2017 at 11:33 PM, Alec Muffett <alec.muffett at gmail.com>
wrote:

> I only know what this means due to a stint on GCOS-3 and having my
> boss/sysmgr explain that "threaded code" in the old sense could be smaller
> than the equivalent CISC binary on the same machine:
>
> https://en.m.wikipedia.org/wiki/Threaded_code
>
> And no, it's not Threads :-)
>

A PDP-11 FORTRAN compiler I used back in the day was implemented this way,
in part to make overlays easier (though I was young at the time, and never
understood this bit). Overlays, as you may recall, were paging for systems
that didn't support paging that swapped code (mostly) in/out as needed to
fixed locations. The overlay manager was a quite important thing, since it
automatically laid out the overlays based on calling sequences. Later
versions would use MMU flipping tricks and had them aligned to 8k
bounaries, but earlier versions were aligned to 512 boundaries to match the
block size on the disk (since code was read-only, the OVL files were used
to page code in). The Threading made the Fortran code smaller since the
meat of the code was elsewhere, often in an area that wasn't overlaid... At
least that's how my brain recalls things from 30-some years ago... Once I
went away to college and was on a VAX or DECsystem20 (and later Sun3's and
Sun4's), I swapped all this arcania out of my brain, so bit errors may have
occurred before I just swapped it back in :)

Based on Doug's description, it sure sounds familiar (and somewhat
triggering it turns out, but in a good way)...

There were also options to get co-routines, which is akin to a primitive
'threads' as we'd use the term today using an instruction that swapped the
top of the stack and the PC, but that's different...

Warner


> - alec
>
>
>
> On 14 Sep 2017 6:50 am, "Larry McVoy" <lm at mcvoy.com> wrote:
>
>> Doug, could you talk about this some more?  Sort of like Reddit's
>> explain it like I'm 5?  Assume I'm dense but want to learn and tell
>> me how this worked again.  Threaded?  I'm guessing you mean that it
>> did paging, did that need threads in the current sense?
>>
>> On Wed, Sep 13, 2017 at 11:48:44PM -0400, Doug McIlroy wrote:
>> > > Check out:  ybc: a compiler for B <https://github.com/Leushenko/ybc>
>> >
>> > >From a historical standpoint, a plain B compiler lacks a very important
>> > attribute of B in Unix. Yes, B presaged some C syntax. But its shining
>> > property was that it produced threaded code, for which both compact
>> > and expanded runtime support was available. The latter had software
>> > paging. Thus B transcended the limited physical memory of the early
>> > PDP-11s.
>> >
>> > If you can't compile something, you can't run it.  A prime example was B
>> > itself. Without software paging it would not have been able to recompile
>> > itself, and Unix would not have been self-supporting.
>> >
>> > Doug
>>
>> --
>> ---
>> Larry McVoy                  lm at mcvoy.com
>> http://www.mcvoy.com/lm
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170913/93ba6659/attachment-0001.html>

[TUHS] B Source Code

[Alec Muffett]

I only know what this means due to a stint on GCOS-3 and having my
boss/sysmgr explain that "threaded code" in the old sense could be smaller
than the equivalent CISC binary on the same machine:

https://en.m.wikipedia.org/wiki/Threaded_code

And no, it's not Threads :-)

- alec



On 14 Sep 2017 6:50 am, "Larry McVoy" <lm at mcvoy.com> wrote:

> Doug, could you talk about this some more?  Sort of like Reddit's
> explain it like I'm 5?  Assume I'm dense but want to learn and tell
> me how this worked again.  Threaded?  I'm guessing you mean that it
> did paging, did that need threads in the current sense?
>
> On Wed, Sep 13, 2017 at 11:48:44PM -0400, Doug McIlroy wrote:
> > > Check out:  ybc: a compiler for B <https://github.com/Leushenko/ybc>
> >
> > >From a historical standpoint, a plain B compiler lacks a very important
> > attribute of B in Unix. Yes, B presaged some C syntax. But its shining
> > property was that it produced threaded code, for which both compact
> > and expanded runtime support was available. The latter had software
> > paging. Thus B transcended the limited physical memory of the early
> > PDP-11s.
> >
> > If you can't compile something, you can't run it.  A prime example was B
> > itself. Without software paging it would not have been able to recompile
> > itself, and Unix would not have been self-supporting.
> >
> > Doug
>
> --
> ---
> Larry McVoy                  lm at mcvoy.com
> http://www.mcvoy.com/lm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170914/96d9c9a3/attachment.html>

[TUHS] B Source Code

[Lars Brinkhoff]

Larry McVoy wrote:
> Doug McIlroy wrote:
>> B presaged some C syntax. But its shining property was that it
>> produced threaded code, for which both compact and expanded runtime
>> support was available.
> 
> Threaded?  I'm guessing you mean that it did paging, did that need
> threads in the current sense?

Read this:
https://en.wikipedia.org/wiki/Threaded_code

[TUHS] B Source Code

[Larry McVoy]

Doug, could you talk about this some more?  Sort of like Reddit's
explain it like I'm 5?  Assume I'm dense but want to learn and tell
me how this worked again.  Threaded?  I'm guessing you mean that it
did paging, did that need threads in the current sense?

On Wed, Sep 13, 2017 at 11:48:44PM -0400, Doug McIlroy wrote:
> > Check out:  ybc: a compiler for B <https://github.com/Leushenko/ybc>
> 
> >From a historical standpoint, a plain B compiler lacks a very important
> attribute of B in Unix. Yes, B presaged some C syntax. But its shining
> property was that it produced threaded code, for which both compact
> and expanded runtime support was available. The latter had software
> paging. Thus B transcended the limited physical memory of the early
> PDP-11s.
> 
> If you can't compile something, you can't run it.  A prime example was B
> itself. Without software paging it would not have been able to recompile
> itself, and Unix would not have been self-supporting.
> 
> Doug

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

[TUHS] B Source Code

[Doug McIlroy]

> Check out:  ybc: a compiler for B <https://github.com/Leushenko/ybc>

From a historical standpoint, a plain B compiler lacks a very important
attribute of B in Unix. Yes, B presaged some C syntax. But its shining
property was that it produced threaded code, for which both compact
and expanded runtime support was available. The latter had software
paging. Thus B transcended the limited physical memory of the early
PDP-11s.

If you can't compile something, you can't run it.  A prime example was B
itself. Without software paging it would not have been able to recompile
itself, and Unix would not have been self-supporting.

Doug