From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 32566 invoked from network); 31 Dec 2022 12:55:51 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 31 Dec 2022 12:55:51 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 5609841C78; Sat, 31 Dec 2022 22:55:45 +1000 (AEST) Received: from ewsoutbound.kpnmail.nl (unknown [195.121.94.169]) by minnie.tuhs.org (Postfix) with ESMTPS id 0400141C38 for ; Sat, 31 Dec 2022 22:55:32 +1000 (AEST) X-KPN-MessageId: 61f01e0d-890a-11ed-97dd-005056abad63 Received: from smtp.kpnmail.nl (unknown [10.31.155.37]) by ewsoutbound.so.kpn.org (Halon) with ESMTPS id 61f01e0d-890a-11ed-97dd-005056abad63; Sat, 31 Dec 2022 13:55:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=planet.nl; s=planet01; h=to:message-id:date:from:subject:mime-version:content-type; bh=NlxPelkBVQYYZ/Gevj+kyf8EXGzN2aeuY+zuMk5/umg=; b=nGgZKifLEnuIZkPu0AxE6tbdoBWS2Kuaxri+cg2EgBZE7pLNhu5H9oShXzypOBaMEcrgepklPl3HS o3BPvSBH6bF4TilPlX8ksdhclyZVFQkcY4H0tBoX0axRaQ4zvDGK+drU/XmweNy0Xv7JzdfVV2TjOp HXlZiA9JaqvJ9h7E= X-KPN-MID: 33|s+uLAxFRqMj6vfNRR9A/WVfZPu3jG6a2SnCsCboGn/z9wMwPOsD99FB6f0M1l/1 x/+OtiIOkeaJlbVuyi82GO26I3wySkfjDz8i0/pF2CgY= X-KPN-VerifiedSender: Yes X-CMASSUN: 33|5dYJQLPbqNbEhw8wJLmE7UW4wq8tF0QAXbgNQqgZKzWWeX/0P+Y21g9qeDPd1jo e0caCQZqdFm58/X+DcWiB+g== X-Originating-IP: 77.172.38.96 Received: from smtpclient.apple (77-172-38-96.fixed.kpn.net [77.172.38.96]) by smtp.kpnmail.nl (Halon) with ESMTPSA id 623970d2-890a-11ed-ae06-005056ab1411; Sat, 31 Dec 2022 13:55:21 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Paul Ruizendaal In-Reply-To: Date: Sat, 31 Dec 2022 13:55:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <18521483-A73C-4B5F-A76A-6098BD93E9BC@planet.nl> References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> To: The Unix Historical Society X-Mailer: Apple Mail (2.3654.120.0.1.13) Message-ID-Hash: LAIRJ32P2HO5CEMUKCJ2YCX3BPK77CCS X-Message-ID-Hash: LAIRJ32P2HO5CEMUKCJ2YCX3BPK77CCS X-MailFrom: pnr@planet.nl X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tuhs.tuhs.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: segaloco X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: A few comments on porting the Bourne shell List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: 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=E2=80=99t 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=E2=80=99s in essence needed = a Lions commentary on sh. > On 30 Dec 2022, at 20:57, segaloco wrote: >=20 > I'll have to double check later but I'm fairly certain the remaining = L/R cheats are gone by SysV. =46rom 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. >=20 > - Matt G. >=20 > ------- Original Message ------- > On Friday, December 30th, 2022 at 10:25 AM, Paul Ruizendaal = wrote: >=20 >=20 >> London and Reiser report about porting the shell that =E2=80=9Cit = required by far the largest conversion effort of any supposedly portable = program, for the simple reason that it is not portable.=E2=80=9D 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. >>=20 >> There were three aspects that I found noteworthy: >>=20 >> 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: >>=20 >> >>=20 >> /* 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)) >> >>=20 >>=20 >> 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=E2=80=99d 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. >>=20 >> 2. On the history of dup2 >>=20 >> The shell code includes the following: >>=20 >> >>=20 >> rename(f1,f2) >> REG INT f1, f2; >> { >> #ifdef RES /* research has different sys calls from TS */ >> IF f1!=3Df2 >> THEN dup(f1|DUPFLG, f2); >> close(f1); >> IF f2=3D=3D0 THEN ioset|=3D1 FI >> FI >> #else >> INT fs; >> IF f1!=3Df2 >> THEN fs =3D fcntl(f2,1,0); >> close(f2); >> fcntl(f1,0,f2); >> close(f1); >> IF fs=3D=3D1 THEN fcntl(f2,2,1) FI >> IF f2=3D=3D0 THEN ioset|=3D1 FI >> FI >> #endif >> } >> >>=20 >>=20 >> I=E2=80=99ve 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. >>=20 >> 3. Halfway to demand paging >>=20 >> I stumbled across this one because I had a bug in my signal handling. = =46rom 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: >>=20 >> >>=20 >> VOID fault(sig) >> REG INT sig; >> { >> signal(sig, fault); >> IF sig=3D=3DMEMF >> THEN IF setbrk(brkincr) =3D=3D -1 >> THEN error(nospace); >> FI >> ELIF ... >> >>=20 >>=20 >> 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. >>=20