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 28723 invoked from network); 6 Aug 2023 06:52:54 -0000 Received: from minnie.tuhs.org (2600:3c01:e000:146::1) by inbox.vuxu.org with ESMTPUTF8; 6 Aug 2023 06:52:54 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 7D201426E9; Sun, 6 Aug 2023 16:52:46 +1000 (AEST) Received: from ewsoutbound.kpnmail.nl (ewsoutbound.kpnmail.nl [195.121.94.169]) by minnie.tuhs.org (Postfix) with ESMTPS id BF979426E2 for ; Sun, 6 Aug 2023 16:52:32 +1000 (AEST) X-KPN-MessageId: c99f2181-3425-11ee-849a-005056abad63 Received: from smtp.kpnmail.nl (unknown [10.31.155.40]) by ewsoutbound.so.kpn.org (Halon) with ESMTPS id c99f2181-3425-11ee-849a-005056abad63; Sun, 06 Aug 2023 08:52:19 +0200 (CEST) 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=TcgDUl0dUI++D/KrStGWc1NMlQG6ACiMP3x+Lq2LgeE=; b=vkPgO/67tMee2ZuU8yZQsfOE3mumxIEn2WbKC8SLaJGHzDTuoFjDcBZr6dNf384SoRylf6GKyC+m8 my7FIenvbf+ecEyGwE8cdJw17qM4sGa84WEIlmFZE7sw0dTtZn8TgS3En6XXbFC4+EGH7vGPiXD//e Koo9Eo5wq9SIS2LA= X-KPN-MID: 33|7HHU7zpsqxv/HsxxTcj+zs3TpZOdkVQaq1raFXyUYmBvsGQZ4SVvtOJpAiB7LAy FIb9pVdPgd6xOeFZn5h8/SHxL0v7X8MerUaE9wPDjFxs= X-KPN-VerifiedSender: Yes X-CMASSUN: 33|VqQclxq+A8S6KeNKNDzr0TAgPhOXXtSUSVEOo0F18DvCxqvQuB5UPeiNrB0j/Fj uqx/0LroUT1xUrvF+vhXfNg== X-Originating-IP: 113.160.248.69 Received: from smtpclient.apple (unknown [113.160.248.69]) by smtp.kpnmail.nl (Halon) with ESMTPSA id cb3db124-3425-11ee-93b1-005056ab7584; Sun, 06 Aug 2023 08:52:26 +0200 (CEST) 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: <4726704a3c0e056d6e4d5dd1dc582116@yaccman.com> Date: Sun, 6 Aug 2023 13:52:20 +0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7C8CADAB-65AA-4841-AFA1-569A9651E56D@planet.nl> <4726704a3c0e056d6e4d5dd1dc582116@yaccman.com> To: "tuhs@tuhs.org" X-Mailer: Apple Mail (2.3654.120.0.1.13) Message-ID-Hash: VPXKCWEV3WA2BE24BO777CD6ABDJ3XFM X-Message-ID-Hash: VPXKCWEV3WA2BE24BO777CD6ABDJ3XFM X-MailFrom: pnr@planet.nl 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 X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: Early multiprocessor Unix List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Thank you for sharing, very interesting context info! It would seem to me that there was only limited work on multi-processor = Unix prior to 1985, with the work by Bach/Buroff/Kelleman around 1983 = being the defining effort. When I was doing my thesis with Prof. Van de Goor (who had earlier = worked at DEC with the PDP-8 and PDP-11 design teams), another student = down the corridor was working on multi-processor Unix ca. 1984-1985. = There is a short paper about that work here = https://dl.acm.org/doi/pdf/10.1145/6592.6598 =46rom today=E2=80=99s perspective the paper=E2=80=99s conclusions seem = odd. It describes going through the source code end-to-end as a huge = job, but the core SysIII kernel is only some 7,000 sloc, with maybe two = dozen shared data structures. On the other hand, with the tooling of the = early 1980=E2=80=99s debugging this stuff must have been very hard. In = contrast, on my porting projects today it is very easy to generate a = kernel trace for millions of instructions in a few seconds. Even = billions is do-able. The edit/compile/test cycle for a kernel with some = debug test code compiled in is similarly a matter of seconds. A single = test must have taken an hour or more back in the day, assuming that one = had exclusive access to the machine. Also its observation that the Unix kernel is =E2=80=9Cnot highly = structured=E2=80=9D seems unfair. I find the 1980-era Unix kernel rather = well structured, with the exception of the memory management code which = is indeed spread out over multiple files making it not so easy to fully = grasp. Maybe this was what my fellow student was referring to in his MSc = thesis. Also note that a Dutch MSc thesis only took 6-12 months. > On 6 Aug 2023, at 06:00, scj@yaccman.com wrote: >=20 > When I left Bell Labs in 1986, I joined Ardent Computer in California. = We built a multiprocessor Unix system with up to four processors based = on ECL technology (faster than the computer chips of the time). The CPU = had a standard set of registers, and there were four vector registers = that would hold 1000 floating-point numbers and vector instructions to = do arithmetic. > So that meant that we had compiler work to do. Luckily, Randy Allen = had just graduated and signed on to do the parallelism. I took on the = job of doing the assembler, loader, parallelizing C and FORTRAN = compilers, and I did the lower-level stuff: assembler, loader, > designed the a.out format, and even wrote a bug tracking system. = Randy's compiler was excellent, but there were other problems. The Sun = workstations had some quirks: from time to time they would page in a = page of all zeros due to a timing problem. Unhappily, the zero was the = halt operation! We addressed that by adding code to the Kernel the = verify that no code page was all 0's before executing. AT&T and Sun = and MIPS and all the hardware makers have problems like this with early = chips. One thing I had told the team from the beginning was that we = were going to have to patch hardware problems in the early versions. >=20 > The most serious early hardware bug in our machine was that when the = MIPS chip had a page fault, the CPU started executing the new page = before it was all present. It only missed the first two or three = instructions. We settled on a strategy to generate the a.out file so = that the first 4 instructions were all No-Ops. This solved the MIPS = problem. >=20 > Now we faced the problem of how do we take a standard a.out format and = redo it so that the first four instructions in each code page are NOPs. = We built an "editor" for a.out files that would read the file in, = respond to a series of requests, relocate the instructions correctly, = and then branch to the line of code that it had been about to execute. = One good thing about this was that when the chip got fixed we would not = have to change any code -- it would just work. >=20 > And then we got creative. We could use the "editor" to find the basic = blocks in the code, introduce counting instructions at the head of each = block, and produce a profiler by recompiling. We probably found about = 20 things we could do with this mechanism, including optimization after = loading, timing the code without having to recompile everything, = collecting parallelism statistics, etc. >=20 >=20 > --- >=20 >=20 > On 2022-11-28 05:24, Paul Ruizendaal wrote: >> The discussion about the 3B2 triggered another question in my head: >> what were the earliest multi-processor versions of Unix and how did >> they relate? >> My current understanding is that the earliest one is a dual-CPU VAX >> system with a modified 4BSD done at Purdue. This would have been late >> 1981, early 1982. I think one CPU was acting as master and had >> exclusive kernel access, the other CPU would only run user mode code. >> Then I understand that Keith Kelleman spent a lot of effort to make >> Unix run on the 3B2 in a SMP setup, essentially going through the >> source and finding all critical sections and surrounding those with >> spinlocks. This would be around 1983, and became part of SVr3. I >> suppose that the =E2=80=9Cspl()=E2=80=9D calls only protected = critical sections that >> were shared between the main thread and interrupt sequences, so that = a >> manual review was necessary to consider each kernel data structure = for >> parallel access issues in the case of 2 CPU=E2=80=99s. >> Any other notable work in this area prior to 1985? >> How was the SMP implementation in SVr3 judged back in its day? >> Paul