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_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,MAILING_LIST_MULTI, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 31629 invoked from network); 20 Dec 2023 20:29:24 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 20 Dec 2023 20:29:24 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id A077743F18; Thu, 21 Dec 2023 06:29:22 +1000 (AEST) Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) by minnie.tuhs.org (Postfix) with ESMTPS id DE69443F14 for ; Thu, 21 Dec 2023 06:29:18 +1000 (AEST) Received: by mail-pj1-x1036.google.com with SMTP id 98e67ed59e1d1-28beccb626aso32507a91.2 for ; Wed, 20 Dec 2023 12:29:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1703104158; x=1703708958; darn=tuhs.org; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=KTnfC0j4bN6CMzTeTcyktCx0cEGfTeKcXgoUJe4u3J0=; b=gSjNIXIPY3HLyJ/QV+DD7Vevn8HMNtI0hN7ui/+HCZFZsKw2yS6AsrPIq3eM/sO9cb DAPJWLwT2wPX9s2/ISyudU9wL1qq6/t7e3qpG2P7Kh3ElNDsrpLsD+N1/EaQO2ALjAo1 mKJV8lMBKbrS1hE6BG21mH7BHwWwAl7hwZNOaToCzRuKBAXGmv1tTmu/rZBR+IlOXPEa qulLznq5M6WIQXH4zCwPNIBQ2+wnIqi5QGRwy/wLY7kkaaSmnlyeukRzK5+l6EuLlTnE NPD8RPaYYczlSS99PUC8tsL0OE8+C9In7Mtb6DeaYB4eozJL6Y0aE6bN23e/b7hjhlEy rKHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703104158; x=1703708958; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=KTnfC0j4bN6CMzTeTcyktCx0cEGfTeKcXgoUJe4u3J0=; b=B2m51o/d0ZPyhoeLTODwF2qgM6HKA52uINyr5dKflCsaChK/kZtwQaqOwrajROhXAG NprEhxPWqzsyWZ+zS21DpKYBvDTryKTzvaOAvSeoZCthpJ6LmBbZHMhgsxm6UrJyol08 9IEjASd3KT5tGXraV/mmqgm/iDIO0sx5SPb493Z5Yjg9N+yPaXag9xAgjRibLdZBY2cs 16FXkgi1XWx5TPMxPnfSFUNJCm4PSpuwoTLOqLT/wdd70F9Kdfla9ILOGgmnn0R9KezS Ox/7R7S/PUvaQ2X3h5f0EJ2PTp/Y0Xr4PaY5kft4OBKeAeLMfEJ8ecxeu23ZI6j6IceG NcaQ== X-Gm-Message-State: AOJu0YzSXjKU+0iuNuYSOQrixQjOZlxryVZEhLu3kaE3gK2ROmfBPEQG 3p8YsXcKQGCBAgXdYiUyhOzfdczcNM+wZ3seSx9MGUiE X-Google-Smtp-Source: AGHT+IGhdv4FEUUIVcGW+dvOkn9fz2b6qCizr7dKqlX21rL+wk6OG+j8b9eIM23B7JnXZr3MMLaGpyvKSb1zffrodHo= X-Received: by 2002:a17:90a:4406:b0:28a:bc14:8f08 with SMTP id s6-20020a17090a440600b0028abc148f08mr6074772pjg.88.1703104158089; Wed, 20 Dec 2023 12:29:18 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a05:6a10:a487:b0:52a:96f1:6718 with HTTP; Wed, 20 Dec 2023 12:29:17 -0800 (PST) In-Reply-To: <20231220193141.DC1C918C092@mercury.lcs.mit.edu> References: <20231220193141.DC1C918C092@mercury.lcs.mit.edu> From: Paul Winalski Date: Wed, 20 Dec 2023 15:29:17 -0500 Message-ID: To: Noel Chiappa Content-Type: text/plain; charset="UTF-8" Message-ID-Hash: VYXIWU4NEMWYPFAK3YDP6V3RWQVNP3WV X-Message-ID-Hash: VYXIWU4NEMWYPFAK3YDP6V3RWQVNP3WV X-MailFrom: paul.winalski@gmail.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: coff@tuhs.org X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [COFF] Re: Terminology query - 'system process'? List-Id: Computer Old Farts Forum Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On 12/20/23, Noel Chiappa wrote: > > To give an example; the first DEC machine with an IC > processor was the -11/20, in 1970 (the KI10 was 1972); starting with the > LSI-11, in 1975, DEC started using microprocessors; the last PDP-11 with a > CPU made out of of discrete ICs was the -11/44, in 1979. All -11's produced > after that used microprocessors. The VAX-11/780, 11/750, and 11/730 were all implemented using 7400-series discrete, gate-level TTL integrated circuits. The planned follow-on series was Venus (ECL gate level; originally planned to be the 11/790 but after many delays released as the VAX 8600), Gemini (a two-board VAX implementation; cancelled), and Scorpio (a chip set eventually released as the VAX 8000). Superstar, released as the VAX-11/785, is a re-implementation of the 11/780 using faster TTL. The floating point accelerator board for the 11/785 was implemented using Fast Fairchild TTL. The first microprocessor implementation of the VAX architecture was the MicroVAX-I. It, and all later VAX processors, implemented only the MicroVAX subset of the VAX architecture in hardware and firmware. The instructions left out were the character string instructions (except for MOVC), decimal arithmetic, H-floating point, octaword, and a few obscure, little-used instructions such as EDITPC and CRC. The missing instructions were simulated by the OS. These instructions were originally dropped from the architecture because there wasn't enough real estate on a chip to hold the microcode for them. It's interesting that they continued to be simulated in macrocode even after several process shrink cycles made it feasible to move them to microcode. I wrote a distributed (computation could be done in parallel over a DECnet LAN or WAN) Mandelbrot Set computation and display program for VAX/VMS. It was implemented in PL/I. The actual display was incredibly sluggish, and I went in search of the performance problem. It turned out to be in the cartesian-to-screen coordinate translation subroutine. The program did its computations in VAX D-float double precision floating point. The window was 800x800 pixels and this was divvied up into 32x32-pixel cells for distributed, parallel computation. The expression "800/32" occurred in the coordinate conversion program. In PL/I language data type semantics, this expression is "fixed decimal(3,0) divided by fixed decimal(2,0)". This expression was being multiplied by a VAX D-float (float decimal in PL/I) and this mixture of fixed and float triggered one of the more bizarre of PL/I's baroque implicit data type conversions. First, the D-float values were converted to full-precision (15-digit) packed decimal by calling one of the Fortran RTL's subroutines. All the arithmetic in the routine was done in full-precision packed decimal. The result was then converted back to D-float (again by a Fortran RTL call). There were effectively only two instructions in the whole subroutine that weren't simulated in macrocode, and one of those was the RET instruction at the end of the routine! I changed the offending expression to "800E0/32E0" and got a 100X speedup--everything was now being done in (hardware) D-float. -Paul W.