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=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 3647 invoked from network); 19 May 2023 15:16:33 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 19 May 2023 15:16:33 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 3A1D8412A5; Sat, 20 May 2023 01:16:29 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tuhs.org; s=dkim; t=1684509389; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-owner:list-unsubscribe:list-subscribe:list-post; bh=WPX0A42y9cw89GG0qnLK86zxmm8Dd4uipka7smZoR8s=; b=cryJR1nZuVeDwHPpF4ayDAlTkBJ4QSwqKlqMlrPlfUy8qPKDrESlEpleHVsTxgzgD+M3DP SyXow36M12ynoj463pJ25Lay0y06nEU+ZB0nQ/q8Q8opLKwAPZQUm7h6o8MSh6TMilLBsk 4WprL86Omof8Sxjo2fn0z/+wcGAWqiI= Received: from mail-4318.protonmail.ch (mail-4318.protonmail.ch [185.70.43.18]) by minnie.tuhs.org (Postfix) with ESMTPS id D53634129B for ; Sat, 20 May 2023 01:16:18 +1000 (AEST) Date: Fri, 19 May 2023 15:15:58 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1684509376; x=1684768576; bh=WPX0A42y9cw89GG0qnLK86zxmm8Dd4uipka7smZoR8s=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=sjMcJ8hTxf7fkdQsC+jrLMOkESlnOrqWwQKdMluTRbLronpftotvpTdd8D+pP2Emi sdQj4lVAJ8TVBkEd0iPm1Rpzar1kzaCrFC+qzlqSjN8yaLmQ2kemJXuynDr35YMpA1 ecGUlcRWUsboAJJVORKFysgMu8ATTHuDOd+MATXD19np29iE6k9FaRB3ZY+Teb5hav VyrSzHQzcsEBTPzK0dR7B8LBMenCMgB/i+InVmkPoFEQSX/voqVRZrm9OBHrvTjH8y 7lEn5Frpi23iNhKCsRVgutbwEUekElEDVRT1uIHUHttBsTzoI3cOhO74WsfXjLL9rG UQ1PgdhMfIe0w== To: jnc@mercury.lcs.mit.edu Message-ID: <2Lh60xGsGY4H5cQmH1na_kaiIZkg5u9qMh4SiyaMA-l1WwW-Ag1tuw9Xs7M61ebLWwKEvjqwteLcZ0B9aOMIoTDb90Vwz78xUkt-tTYvdzc=@protonmail.com> In-Reply-To: <20230519143618.11F6918C074@mercury.lcs.mit.edu> References: <20230519143618.11F6918C074@mercury.lcs.mit.edu> Feedback-ID: 35591162:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: OJBQYBDZ2JBKYAFEOGYNADPB4SITRVH5 X-Message-ID-Hash: OJBQYBDZ2JBKYAFEOGYNADPB4SITRVH5 X-MailFrom: segaloco@protonmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: tuhs@tuhs.org X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: A Census of /etc and /sys Prior to V4 List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: From: segaloco via TUHS Reply-To: segaloco There are the s2-bits binaries that I'm slowly disassembling. I don't thin= k there is a kernel image down in there though. That said, there is a "cor= e" file included, I wonder if kernel text is swept up in that. In any case, if there are other binaries floating around, disassembly is on= e of my oldest techie hobbies, so happy to go mining for information. Also, I've mentioned it a few times but in busier emails: The s1-bits sourc= e code fragments appear to be later than the s2-bits binaries, evidenced bo= th by /etc/passwd subbed for /etc/uids in the former and likewise ac and mq= EAE registers are still in use in s2-bits binaries but have been replaced = by s1-bits. All in all that pegs the s1-bits fragments as being closer in c= haracter to V3 while the binaries are closer in character to V2. As my V2 = disassembly progresses I'll try and put together a more detailed list of di= fferences between these two bits of code as well as the Bashkow init and sh= sources, with V5 as a later reference. - Matt G. ------- Original Message ------- On Friday, May 19th, 2023 at 7:36 AM, jnc@mercury.lcs.mit.edu wrote: > > From: Matt G. >=20 >=20 > > Given the movement of UNIX to the 11/45 and then to C, does the Third >=20 > > Edition represent a version of UNIX for the 11/45 with protection but >=20 > > written in assembly, not C? >=20 >=20 > I think so (evidence detailed below). The support may not have been quite > identical to that in V4 (e.g. there was no support for pure texts in V3 - > below), though. >=20 > > is there any other information such as documents, code, etc. concerning >=20 > > the 11/45 assembly version? >=20 >=20 > This is the real problem, of course; all we have for V3 is some man pages= . > (And in relying on them, we have to hope that they were updated to match = the > then-current system - which is not guaranteed, but in general at this poi= nt > in time, man pages do seem to match whats's in the code.) >=20 > > Was work completed on the 11/45 kernel changes in the context of this >=20 > > version and then simply "ported" to the C version or were there >=20 > > concepts that were cropping up in one or the other and varying amounts >=20 > > of transportation back and forth as 11/45 and C aspects were >=20 > > implemented? >=20 >=20 > Without a lot more information, which is now almost certainly lost, we ar= e > unlikely to be able to tell. But let me start by laying out what we do kn= ow. >=20 >=20 > To start with, it's important to realize that support for protection (and > relocation - i.e. memory that looks, to user code, like it's at 0, > is actually at, say, 060000 in physical terms) in PDP-11 UNIX pre-dates t= he > -11/45. DEC had a rare, and now almost forgotten "Memory Protect & Reloca= te" > option for the -11/20, the KS11: >=20 > https://gunkies.org/wiki/KS11_Memory_Protection_and_Relocation_option >=20 > What exactly it did, and how, is now uncertain (no documentation, or code > that used it, appeats to have survived - all we have are a couple of vagu= e > recollections), but it is certain that that the UNIX group's -11/20 had i= t: >=20 > https://www.bell-labs.com/usr/dmr/www/odd.html >=20 > and Ken has said that he wrote the code to use it. >=20 > It's also important to remember that not all the machines running UNIX wo= uld > have had their hardware updated simultaneously: e.g. the patent group's > -11/20 would not have needed the KS11 as much, since it was runnng mature > applications. So UNIX was probably conditionalized to run with and withou= t > the KS11. As late as V3, there were apparently still UNIX machines withou= t > relocation hardware: "The purpose of this command is to simplify the > preparation of object programs for systems which have no relocation > hardware.": >=20 > http://squoze.net/UNIX/v3man/man1/reloc >=20 > When the support for the KS11 appeared is uncertain. It's not in the exta= nt > V1 code; but V2 seems to have had it: "the current system, which has > relocation and protection hardware": >=20 > http://squoze.net/UNIX/v2man/man5/core >=20 > V2 also seems to have started looking forward to the -11/45 - "a trap is > simulated by the floating point simulator" (ditto); "if they correspond t= o > 11/45 floating point instructions": >=20 > http://squoze.net/UNIX/v2man/man3/fptrap >=20 > It is possible that they already had the -11/45 at this point, but I woul= d > tend to doubt it: "immediate mode ((pc)+) is not supported, since the > PDP-11/45 handbook is not clear on what to do about it." (If they had it,= a > simple experiment would have produced the answer.) And "Double precision > results are probably less correct than the hardware will be" (note tense)= . > (All from v2man/man3/fptrap.) >=20 >=20 > V3 seems to have the -11/45: "it depends on what hardware is present (EAE= , > floating-point option)": >=20 > http://squoze.net/UNIX/v3man/man5/core >=20 > The "floating-point option" would only have been on the -11/45. (And agai= n we > see that V3 still ran on -11/20's; the -11/45 would not have had an EAE: >=20 > https://gunkies.org/wiki/KE11-A_Extended_Arithmetic_Element >=20 > since all the EAE operations - except normalization, but that's only need= ed > for floating-point - were in the basic -11/45.) >=20 > Probably the protection and relocation provided to UNIX processes on the > 11/45 was very similar to that provided with the KS11. Do note that theme= mory > management was not exactly the same as V4's: "In the future the text segm= ent > will be write-protected and shared.": >=20 > http://squoze.net/UNIX/v3man/man5/a.out >=20 > However, it was keeping multiple processes in main memory at the same tim= e: > "only processes whose core images are on disk have visible names": >=20 > http://squoze.net/UNIX/v3man/man8/ps >=20 >=20 > So we can actually tell a fair amount about the evolution through V2 and = V3 > from the few scraps that are left to us. I do live in hope that a V2 or V= 3 > listing will turn up one day; the system changed a lot in that period, an= d > many questions aren't answered definitively by the man pages. >=20 > (One big one is details of how the process' address space was laid out - > ld(III) and exec(II) simply say nothing at all. I assume it started at 0 = - > but who knows? In V1, it must have started at a higher address - as on > MINI-UNIX: >=20 > https://gunkies.org/wiki/MINI-UNIX#Implementation_details >=20 > which I am fairly familiar with - but again, neither V1's ld(III) or exec= (II) > mentions this detail. I suppose I could work it out from the V1 source, b= ut > I'm not that interested... :-)) >=20 > It is possible that the evolution started with just protection (if the KS= 11 > could do that), and relocation was added later. It seems clear that the > step from the KS11 to the -11/45 was probably not large. >=20 >=20 > If anyone has a V2 or V3 listing, please sing up! That would be an > incredibly valuable thing to add to the historical record. >=20 > Noel