From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: from minnie.tuhs.org (minnie.tuhs.org [50.116.15.146]) by inbox.vuxu.org (Postfix) with ESMTP id 01FD722328 for ; Sat, 6 Jul 2024 00:10:54 +0200 (CEST) Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 340B643DD2; Sat, 6 Jul 2024 08:10:51 +1000 (AEST) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) by minnie.tuhs.org (Postfix) with ESMTPS id 0A76843DCF for ; Sat, 6 Jul 2024 08:10:43 +1000 (AEST) Received: by mail-lj1-x236.google.com with SMTP id 38308e7fff4ca-2ee90dc1dc1so18528241fa.3 for ; Fri, 05 Jul 2024 15:10:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720217441; x=1720822241; darn=tuhs.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=YQj/s+dPkKzd8PQn90JqS8ShtuorTzbx8lpnGBmVhKc=; b=CK3neNtZ/Z2uv4qM9Xzmh5eRdMn663TGw27rx8MVB6MdX6zxVYBYrWVmHNvkynxwZK cEYzHXtc2Cu+1XI8oHZqmW1c6ED+mbDJnDs3mR2/9/vtA9XpEirXcWV/dpBlC8iw4E6O 4vP0U6SGxVmlUQErDWy90Gheznj6lic7up26K4sW+yPWr63f/DDfuNCAD6lbVsaBrTzJ F1r9pX+/+eWyZH3P+YOvK22mvADa/ipfcksRlQ3aNFLrNnGfQ85apzyX/UqVWG6RSYZy 3yD6AXlz0mYJes9rqI0FaAjI5skmh8wjxns/lLi1kpXKCO9THG+dR/61yF14ssqJYRIm 4++g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720217441; x=1720822241; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=YQj/s+dPkKzd8PQn90JqS8ShtuorTzbx8lpnGBmVhKc=; b=RPev5goPgp8Gv4KLllDsSh87PG0z4iLQe+0Ce5SZwx/TmEtQd84hffF35OEZC1AUBB EJxLsCG3MuOYQAaVaVKTM/OR/EpNgtLlScJ1TBnwFwkWxgOBG0hC5UzKgiHOhcrhclrE f2HU7CjYfBcRXksWrVBw9bkZu+NuUWvgafvFyaMVBLoGPBDvOgHTJ+9pN0gspgBiqjGI S9JF1NrYY17a+GQ4D3C8M4MhmGLtrfx86gomQaQ07OWqK+xlARSH2XWBW26tJvBXX5gZ gcf21LzKz33lkSUvneg29eIBO/Qa28Kg/pq9R82Rp5qRlRMocRFucMEpq9FFMrg5EUCS j28A== X-Gm-Message-State: AOJu0Yx7ivsigr5/EY6pRLBlWwIafoUB4z28TrKNAkhT3VLgmS6s5cD6 V8EKUemBPNOOT+FyR1lIrOM4qoGBrpPB1RrkyfVxcvOdsQaLZn2zF8S+agvqNJTx1q7GllU3KXQ 9vA7jooVgI5a93g3VIlajDQtweL1a1SuX X-Google-Smtp-Source: AGHT+IEYLkk7iCHDbO7da7gdvnuBLBl05molsI7vGfc99xxjtH0d3ET953pV5EhTgOwLvsMMV9oQ4iHzzVIqpoU6Y0E= X-Received: by 2002:a2e:9143:0:b0:2ec:4acf:97dc with SMTP id 38308e7fff4ca-2ee8ed5f669mr37336391fa.11.1720217440759; Fri, 05 Jul 2024 15:10:40 -0700 (PDT) MIME-Version: 1.0 References: <20240705213804.550128EDF53C@ary.qy> In-Reply-To: <20240705213804.550128EDF53C@ary.qy> From: Dan Cross Date: Fri, 5 Jul 2024 18:10:04 -0400 Message-ID: To: John Levine Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: 6VGC7P22JAX7DEYOZMLQR47VQG4IDC75 X-Message-ID-Hash: 6VGC7P22JAX7DEYOZMLQR47VQG4IDC75 X-MailFrom: crossd@gmail.com 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: tuhs@tuhs.org, peter.martin.yardley@gmail.com X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Fri, Jul 5, 2024 at 5:47=E2=80=AFPM John Levine wrote: > It appears that Peter Yardley said: > >The DG Nova had a pretty nice architecture. 2 accumulators, 2 index regi= sters, program counter, status register. No stack register tho. There was a= micro processor version by Fairchild. > > It did, but it was word addressed which makes it an historical > curiosity like its spiritual predecessors PDP-4/5/7/8/9. > > I also have a mental model of a PDP-11 but these days it's more a simplif= ied 386 > leaving out the dumb or useless stuff. I ignore the segments which are u= seless > other than for 286 emulation, and some of the strange instructions like d= ecimal > adjust and the warty 8 and 16 bit registers. > > What's important is the memory model which on a 386 the way it was > invariably set up was a flat 32 bit consistent little-endian byte > addressed memory with a stack and reasonable addressing modes, and 4K > pages for virtual memory. It is important to ask, "what does one want to learn about architecture by going through this study exercise?" If one just wants to study the unprivileged instruction set at the level of assembler mnemonics, then x86_64 isn't completely awful. Some of the registers are oddly named, and some instructions have odd implicit operands (e.g., `inc %rax`, but if you're just looking at assembler syntax, perhaps one doesn't care. Of course, the instruction encoding is a huge mess, but most work-a-day programmers don't have to care about that. Where it gets really ugly, in my opinion, is in the privileged instruction set, and there you can't get away from history: there's no escaping descriptor tables or segmentation there! The interrupt stack table in the TSS must be set up properly or you're bound for a triple fault. This implies the GDT, IDT, TR, and TSS --- all 286-era goo --- are all properly set up, and you can't get away from that stuff, even in a modern operating system (you have to reload the TSS _or_ replace RSP0 on every thread switch: there's no other way; that's just how the hardware works). And then there's the matter that you _have_ to enable paging before switching into 64-bit mode on x86...it's not hard, but it's annoying (and the x86S proposal doubles down on it). It'd be more rational to allow execution against a flat 64-bit physical address space; for x86S, I'd rather be able to specify a reset vector in the physical address space by some sort of external strap. Both RISC-V and ARM seem much more rational in this world by comparison. I don't like the RISC-V page table format, though: it doesn't permit you to pun the root of the paging radix tree for other levels, meaning you can't use the "recursive page table" trick to get access to page tables themselves: this, in turn, has effects on the rest of the design of a virtual memory system. I think I've found a way around that involving a dedicated temporary mapping region, but it's kind of a pain and takes a non-trivial chunk of virtual address _space_ (if not fully realized memory) that I don't care for. How to handle cached vs uncached mappings, e.g., for MMIO, is still a bit mysterious to me. Honestly, this is something that x86 got largely right. ARM is ok, but has grown a lot of complexity; most of which can be ignored until needed, I suspect; saturating arithmetic, for example. Understanding it is not critical to understanding more or less how the computer works. > ARM should be OK too but I have to ask which ARM? There have been so > many generations often not backward compatible. I'd start with ARMv8 at this point. It has less confusing, more rational stack push/pop semantics and I think they did away with the conditional execution stuff, which is easier to reason about. My 2c. - Dan C.