The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Paul Ruizendaal <pnr@planet.nl>
To: The Unix Historical Society <tuhs@tuhs.org>
Cc: segaloco <segaloco@protonmail.com>
Subject: [TUHS] Re: A few comments on porting the Bourne shell
Date: Sat, 31 Dec 2022 13:55:20 +0100	[thread overview]
Message-ID: <18521483-A73C-4B5F-A76A-6098BD93E9BC@planet.nl> (raw)
In-Reply-To: <CqDJahHNUWy9Cx835tZrgXaqZZKafcJSGlRk9Fb43IP_NzYgSiP1t1HCnS_34h11oiwj6FRl4TesmhPeFvYDBCkiK0__bXPENOwVC04qSQc=@protonmail.com>

The "assembly code in the Bourne shell" comment is in the same London/Reiser paper. The full quote is:

"The (Bourne) shell is the standard user command interpreter. It required by far the largest conversion effort of any supposedly portable program, for the simple reason that it is not portable. Critical portions are coded in assembly language and had to be painstakingly rewritten. The shell uses its own sbrk which is functionally different from the standard routine in libc. The shell wants the routine which fields a signal to be passed a parameter giving the number of the signal being caught; signal was also a private rou- tine. This was handled by having the operating system provide the parameter in the first place, doing away with the private code for signal. The code in fixargs (for constructing the argument list to an exec system call) had to be diddled."

The files in the V7 tree on the Tuhs website are dated January 1979, so it would seem that the fixes for 32V were immediately taken back to Research. As you point out, this means that the comments above do not refer to the well known source code, but to a predecessor of that (which I don’t think survived).

Despite all the criticism voiced above, I think it is well understood that the original Bourne shell is an amazing piece of work that managed to fit an enormous amount of functionality into a cramped address space. Its longevity attests to that. That its internals became difficult to understand is par for the course -- the 1980’s in essence needed a Lions commentary on sh.


> On 30 Dec 2022, at 20:57, segaloco <segaloco@protonmail.com> wrote:
> 
> I'll have to double check later but I'm fairly certain the remaining L/R cheats are gone by SysV.  From what I can tell much of that portability work may have been done prior to the V7 release code base we're familiar with, as I did some comparison and found only one significant change between V7 and 32V code as I know it at least.  Either the claims of portability issues came between 32V and System III (meaning the shell was accepted as "broken"? in 32V) or the code we actually see in V7 has already been tidied up significantly and doesn't represent the "non-portable" version lamented in the famous quote.  Does this observation hold with reality?  Is there an earlier, more PDP-11 bound version of the Bourne Shell out there?  I seem to recall reading something about some bits of it even being in assembly at one point, but can't remember the quote source.
> 
> - Matt G.
> 
> ------- Original Message -------
> On Friday, December 30th, 2022 at 10:25 AM, Paul Ruizendaal <pnr@planet.nl> wrote:
> 
> 
>> 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.
>> 


  reply	other threads:[~2022-12-31 12:55 UTC|newest]

Thread overview: 121+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-30 18:25 [TUHS] " Paul Ruizendaal
2022-12-30 19:51 ` [TUHS] " Chet Ramey
2022-12-30 20:02   ` Larry McVoy
2022-12-30 20:31     ` Adam Thornton
2022-12-30 20:49       ` Chet Ramey
2022-12-30 20:42     ` Sven Mascheck
2022-12-30 20:48       ` Jon Steinhart
2022-12-30 20:51         ` Sven Mascheck
2022-12-31 11:40         ` Ralph Corderoy
2022-12-31 18:49           ` Jon Steinhart
2022-12-31 19:24             ` Clem Cole
2023-01-03 16:32               ` Chet Ramey
2023-01-01  1:51             ` Ron Natalie
2023-01-02 20:03       ` [TUHS] Command Line Editing in the Terminal Driver (Was: A few comments on porting the Bourne shell) Joseph Holsten
2023-01-02 20:33         ` [TUHS] Re: Command Line Editing in the Terminal Driver Lars Brinkhoff
2023-01-11  2:51           ` Chris Hanson
2023-01-11  3:53             ` Greg 'groggy' Lehey
2023-01-02 21:08         ` [TUHS] Re: Command Line Editing in the Terminal Driver (Was: A few comments on porting the Bourne shell) Rob Pike
2023-01-03 16:53         ` Marshall Conover
2023-01-04  9:18           ` Joseph Holsten
2023-01-11  2:56           ` Chris Hanson
2022-12-30 20:47     ` [TUHS] Re: A few comments on porting the Bourne shell Chet Ramey
2022-12-31  0:08     ` Luther Johnson
2022-12-31  3:59       ` Larry McVoy
2022-12-31  4:12         ` Steve Nickolas
2022-12-31  4:18         ` Bakul Shah
2022-12-31  4:40           ` Larry McVoy
2022-12-31  4:19         ` Marc Donner
2022-12-31  4:23         ` Dave Horsfall
2022-12-31  4:37           ` Clem Cole
2023-01-02  5:10           ` Mary Ann Horton
2023-01-02 16:25             ` Clem Cole
2023-01-02 16:51               ` Larry McVoy
2023-01-02 17:32                 ` Adam Thornton
2023-01-02 17:43                   ` Larry McVoy
2023-01-02 17:48                     ` Luther Johnson
2023-01-02 18:00                       ` G. Branden Robinson
2023-01-02 18:05                         ` Luther Johnson
2023-01-02 18:12                         ` Larry McVoy
2023-01-02 18:16                           ` Clem Cole
2023-01-02 19:50                             ` Warner Losh
2023-01-02 20:05                               ` Adam Thornton
2023-01-02 19:21                           ` G. Branden Robinson
2023-01-02 19:34                             ` Rich Salz
2023-01-02 20:12                               ` Larry McVoy
2023-01-02 20:24                               ` G. Branden Robinson
2023-01-02 20:41                                 ` Larry McVoy
2023-01-02 21:00                                   ` Dan Cross
2023-01-02 21:06                                     ` Clem Cole
2023-01-02 21:19                                       ` Dan Cross
2023-01-02 22:54                                         ` segaloco via TUHS
2023-01-02 23:58                                           ` Jon Steinhart
2023-01-04  9:00                                             ` Joseph Holsten
2023-01-02 22:43                                       ` Steve Nickolas
2023-01-02 21:08                                     ` Joseph Holsten
2023-01-02 21:15                                       ` Adam Thornton
2023-01-02 17:55                     ` Adam Thornton
2023-01-02 18:11                       ` Clem Cole
2023-01-02 18:36                         ` Dan Cross
2023-01-02 18:48                           ` Dan Cross
2023-01-02 18:18                       ` Larry McVoy
2023-01-04  3:20                     ` John Cowan
2023-01-04  3:31                       ` Dan Cross
2023-01-04  4:16                         ` Bakul Shah
2023-01-04 16:15                           ` Dan Cross
2023-01-04 18:28                             ` ron minnich
2023-01-04 19:33                             ` Chet Ramey
2023-01-04 15:21                       ` Ralph Corderoy
2023-01-04 15:54                         ` Ron Natalie
2023-01-02 17:55                 ` Clem Cole
2023-01-03 17:08                   ` Paul Winalski
2023-01-03 19:19                     ` Warner Losh
2023-01-03 19:56                       ` Luther Johnson
2023-01-03 20:21                       ` Dave Horsfall
2023-01-03 21:47                       ` Clem Cole
2023-01-03 21:51                         ` Clem Cole
2022-12-31  4:41         ` Greg 'groggy' Lehey
2022-12-30 20:20   ` Sven Mascheck
2022-12-30 20:49     ` Ron Natalie
2022-12-30 20:52       ` Rob Pike
2022-12-30 20:53       ` Jon Steinhart
2023-01-01 10:44   ` arnold
2023-01-01 11:28     ` arnold
2023-01-03 16:34       ` Chet Ramey
2023-01-03 15:06     ` Chet Ramey
2022-12-30 19:57 ` segaloco via TUHS
2022-12-31 12:55   ` Paul Ruizendaal [this message]
2023-01-01  2:55     ` Warner Losh
2023-01-01  4:38       ` Jonathan Gray
2023-01-01  5:25         ` Warner Losh
2023-01-01  5:35           ` Dan Cross
2023-01-01  5:52             ` G. Branden Robinson
2023-01-01  6:35               ` Warner Losh
2023-01-01  6:35               ` Rob Pike
2023-01-01  6:27             ` Warner Losh
2023-01-01 14:50             ` Ron Natalie
2023-01-01  7:11           ` Jonathan Gray
2023-01-01  7:21             ` Warner Losh
2023-01-01 10:25           ` Paul Ruizendaal
2022-12-31 13:26 Douglas McIlroy
2022-12-31 22:19 ` Rob Pike
2023-01-03 15:08 Douglas McIlroy
2023-01-03 15:57 ` Alejandro Colomar
2023-01-03 17:19   ` Jon Steinhart
2023-01-05 13:22     ` Tom Ivar Helbekkmo via TUHS
2023-01-05 21:11       ` Rob Pike
2023-01-03 17:26 ` Dan Cross
2023-01-03 18:07   ` Steve Nickolas
2023-01-03 20:19     ` Steffen Nurpmeso
2023-01-03 23:03       ` ron minnich
2023-01-04  1:37         ` Bakul Shah
2023-01-04  1:58           ` Adam Thornton
2023-01-04 15:19             ` Ralph Corderoy
2023-01-04 18:01               ` Bakul Shah
2023-01-04 20:46                 ` Alejandro Colomar
2023-01-05  0:06                   ` John Cowan
2023-01-05  0:41                     ` Adam Thornton
2023-01-04  5:05         ` Theodore Ts'o
2023-01-03 18:19   ` Niklas Karlsson
2023-01-04  1:29   ` Adam Thornton
2023-01-05  1:51     ` Alejandro Colomar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=18521483-A73C-4B5F-A76A-6098BD93E9BC@planet.nl \
    --to=pnr@planet.nl \
    --cc=segaloco@protonmail.com \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).