* [TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix?
@ 2024-07-10 2:20 Douglas McIlroy
2024-07-10 2:36 ` [TUHS] Re: machine code translation,as mental architecture models John Levine
0 siblings, 1 reply; 38+ messages in thread
From: Douglas McIlroy @ 2024-07-10 2:20 UTC (permalink / raw)
To: TUHS main list
[-- Attachment #1: Type: text/plain, Size: 648 bytes --]
> In order to port VMS to new architectures, DEC/HP/VSI ...
> turned the VAX MACRO assembly language (in which
> some of the VMS operating system was written) into a
> portable implementation language by 'compiling' the
> high-level CISC VAX instructions (and addressing modes)
> into sequences of RISC instructions.
Clem Pease did the same thing to port TMG from IBM 7000-series machines to
the GE 600 series for Multics, circa 1967. Although both architectures had
36-bit words, it was a challenge to adequately emulate IBM's accumulator,
which supported 38-bit sign-magnitude addition, 37-bit twos-complement and
36-bit ones-complement.
Doug
[-- Attachment #2: Type: text/html, Size: 978 bytes --]
^ permalink raw reply [flat|nested] 38+ messages in thread
* [TUHS] Re: machine code translation,as mental architecture models 2024-07-10 2:20 [TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? Douglas McIlroy @ 2024-07-10 2:36 ` John Levine 2024-07-10 4:59 ` Lars Brinkhoff ` (2 more replies) 0 siblings, 3 replies; 38+ messages in thread From: John Levine @ 2024-07-10 2:36 UTC (permalink / raw) To: tuhs; +Cc: douglas.mcilroy It appears that Douglas McIlroy <douglas.mcilroy@dartmouth.edu> said: >> portable implementation language by 'compiling' the >> high-level CISC VAX instructions (and addressing modes) >> into sequences of RISC instructions. This idea, emulating one machine on another by translating strings of instructions (basic blocks in compiler-ese) is quite old. I don't know who did it first, and would be interested to hear if anyone knows, although I expect it was reinvented multiple times. It used to be harder because programs would store into the instruction stream but these days code is all read-only it's quite standard. I'm typing this on my M1 Macbook using an editor that thinks it's running on an x86. R's, John ^ permalink raw reply [flat|nested] 38+ messages in thread
* [TUHS] Re: machine code translation,as mental architecture models 2024-07-10 2:36 ` [TUHS] Re: machine code translation,as mental architecture models John Levine @ 2024-07-10 4:59 ` Lars Brinkhoff 2024-07-10 12:53 ` John R Levine 2024-07-10 11:56 ` Paul Winalski 2024-07-10 14:12 ` Marc Donner 2 siblings, 1 reply; 38+ messages in thread From: Lars Brinkhoff @ 2024-07-10 4:59 UTC (permalink / raw) To: John Levine; +Cc: tuhs, douglas.mcilroy John Levine writes: > It used to be harder because programs would store into the instruction > stream but these days code is all read-only it's quite standard. I'm > typing this on my M1 Macbook using an editor that thinks it's running > on an x86. Note that Apple silicon has special hardware - not in standard ARM devices - to accomodate the x86 memory model. I don't know the detals of Rosetta 2, but I believe this hardware is an important component to make it work. ^ permalink raw reply [flat|nested] 38+ messages in thread
* [TUHS] Re: machine code translation,as mental architecture models 2024-07-10 4:59 ` Lars Brinkhoff @ 2024-07-10 12:53 ` John R Levine 0 siblings, 0 replies; 38+ messages in thread From: John R Levine @ 2024-07-10 12:53 UTC (permalink / raw) To: Lars Brinkhoff; +Cc: tuhs, douglas.mcilroy On Wed, 10 Jul 2024, Lars Brinkhoff wrote: >> typing this on my M1 Macbook using an editor that thinks it's running >> on an x86. > > Note that Apple silicon has special hardware - not in standard ARM > devices - to accomodate the x86 memory model. I don't know the detals > of Rosetta 2, but I believe this hardware is an important component to > make it work. I believe there's hardware to make it work better, but there's plenty of examples of object code translation without special hardware. The last time Apple switched processors they compiled POWER code to x86 which was harder since the byte orders were different. Still would be interested to hear when it was invented. 1967 seems early but not that early. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ^ permalink raw reply [flat|nested] 38+ messages in thread
* [TUHS] Re: machine code translation,as mental architecture models 2024-07-10 2:36 ` [TUHS] Re: machine code translation,as mental architecture models John Levine 2024-07-10 4:59 ` Lars Brinkhoff @ 2024-07-10 11:56 ` Paul Winalski 2024-07-10 14:12 ` Marc Donner 2 siblings, 0 replies; 38+ messages in thread From: Paul Winalski @ 2024-07-10 11:56 UTC (permalink / raw) To: douglas.mcilroy; +Cc: tuhs [-- Attachment #1: Type: text/plain, Size: 860 bytes --] It appears that Douglas McIlroy <douglas.mcilroy@dartmouth.edu> said: > >> portable implementation language by 'compiling' the > >> high-level CISC VAX instructions (and addressing modes) > >> into sequences of RISC instructions. > > No need for the quotes around 'compiling'. VAX MACRO is a true, genuine compiler. The first version of it had a front end that translated VAX/VMS assembly language into expanded IL for the GEM compiler back end. The GEM code generator then generated the Alpha code for that IL. IIRC this process bypassed most of the GEM optimizer. But it gave you native Alpha code. GEM was later targeted to Itanium and that allowed the VAX MACRO compiler to produce code for the IA64 version of OpenVMS. The same process was used by VSI to port OpenVMS to x86-64, but they may be using a LLVM-based compiler back end now. -Paul W. [-- Attachment #2: Type: text/html, Size: 1230 bytes --] ^ permalink raw reply [flat|nested] 38+ messages in thread
* [TUHS] Re: machine code translation,as mental architecture models 2024-07-10 2:36 ` [TUHS] Re: machine code translation,as mental architecture models John Levine 2024-07-10 4:59 ` Lars Brinkhoff 2024-07-10 11:56 ` Paul Winalski @ 2024-07-10 14:12 ` Marc Donner 2024-07-10 16:58 ` segaloco via TUHS 2 siblings, 1 reply; 38+ messages in thread From: Marc Donner @ 2024-07-10 14:12 UTC (permalink / raw) To: John Levine; +Cc: tuhs, douglas.mcilroy [-- Attachment #1: Type: text/plain, Size: 1988 bytes --] Well, a computer scientist named Cathy May at IBM Research did this for the S370 / Power PC architecture pair back in the mid-1980s. The work was novel to me at the time ... she and her long-term partner were close friends of mine, so I heard about her work over shared dinners across several years. The basic technique was to load pages of 360 machine code unmodified into Power PC memory, marking the pages as dirty. If the machine branched into one of these pages the VM trap handler would take the page and translate all of its code from 370 instructions to Power PC instructions. Once that was done the branch, suitably recalculated, was reinstated. It turned out to be remarkably easy to do the translation. And in practice the resulting Power PC code was only about 10% bigger than the original 370 code. AND, since tons of code is never touched (corner cases on corner cases) the result is quite efficient. I don't know if IBM ever built a product based on her research, but it seemed remarkably clever to me. Marc ===== nygeek.net mindthegapdialogs.com/home <https://www.mindthegapdialogs.com/home> On Tue, Jul 9, 2024 at 10:37 PM John Levine <johnl@taugh.com> wrote: > It appears that Douglas McIlroy <douglas.mcilroy@dartmouth.edu> said: > >> portable implementation language by 'compiling' the > >> high-level CISC VAX instructions (and addressing modes) > >> into sequences of RISC instructions. > > This idea, emulating one machine on another by translating strings of > instructions (basic blocks in compiler-ese) is quite old. I don't know > who did it first, and would be interested to hear if anyone knows, > although I expect it was reinvented multiple times. > > It used to be harder because programs would store into the instruction > stream but these days code is all read-only it's quite standard. I'm > typing this on my M1 Macbook using an editor that thinks it's running > on an x86. > > R's, > John > [-- Attachment #2: Type: text/html, Size: 3414 bytes --] ^ permalink raw reply [flat|nested] 38+ messages in thread
* [TUHS] Re: machine code translation,as mental architecture models 2024-07-10 14:12 ` Marc Donner @ 2024-07-10 16:58 ` segaloco via TUHS 2024-07-10 17:15 ` Dan Cross 2024-07-10 19:23 ` Marc Donner 0 siblings, 2 replies; 38+ messages in thread From: segaloco via TUHS @ 2024-07-10 16:58 UTC (permalink / raw) To: tuhs On Wednesday, July 10th, 2024 at 7:12 AM, Marc Donner <marc.donner@gmail.com> wrote: > The basic technique was to load pages of 360 machine code unmodified into Power PC memory, marking the pages as dirty. If the machine branched into one of these pages the VM trap handler would take the page and translate all of its code from 370 instructions to Power PC instructions. Once that was done the branch, suitably recalculated, was reinstated. > > ... > > Marc > ===== > nygeek.net > mindthegapdialogs.com/home Was this under the assumption everything else going on (bus architecture, memory map, exception/trap handling, etc.) was exactly the same or was the MMU for instance in the picture translating from 370 addresses to their equivalents on whatever PowerPC machine was in play? That or was this only expected to work on PIC, user-level code and anything touching for instance privilege escalation or with explicit address pointers, I/O port access, etc. just understood to not be applicable to such a direct translation? To tie it back to UNIX, for instance, was this thing also able to detect that a UNIX system call was being made and translate the 370 syscall mechanism into the PowerPC syscall mechanism? My main experience with emulation is console video games so in that realm, you're dealing not only with a different CPU architecture but system bus, memory map, peripheral controllers, etc. Essentially you're not just speaking another language, you're on another planet entirely. This has lead to a entrenched belief in my mind that this sort of "direct translation" of CPU operations is a non-starter in emulation hence my curiosity. If there's some historic approach to emulation efficiently handling system architecture diversity beyond just CPU instructions, I'm certainly interested! - Matt G. P.S. Feeling trepid about continuing this thread on TUHS rather than COFF, but resisting the urge to bump it (again). To keep it on topic, I'd mostly be interested in how this sort of thing would handle the UNIX system call mechanism, because that would certainly illuminate the general idea of translating something more complicated than an algorithm. ^ permalink raw reply [flat|nested] 38+ messages in thread
* [TUHS] Re: machine code translation,as mental architecture models 2024-07-10 16:58 ` segaloco via TUHS @ 2024-07-10 17:15 ` Dan Cross 2024-07-10 19:23 ` Marc Donner 1 sibling, 0 replies; 38+ messages in thread From: Dan Cross @ 2024-07-10 17:15 UTC (permalink / raw) To: segaloco; +Cc: tuhs On Wed, Jul 10, 2024 at 12:58 PM segaloco via TUHS <tuhs@tuhs.org> wrote: > On Wednesday, July 10th, 2024 at 7:12 AM, Marc Donner <marc.donner@gmail.com> wrote: > > The basic technique was to load pages of 360 machine code unmodified into Power PC memory, marking the pages as dirty. If the machine branched into one of these pages the VM trap handler would take the page and translate all of its code from 370 instructions to Power PC instructions. Once that was done the branch, suitably recalculated, was reinstated. > > Was this under the assumption everything else going on (bus architecture, memory map, exception/trap handling, etc.) was exactly the same or was the MMU for instance in the picture translating from 370 addresses to their equivalents on whatever PowerPC machine was in play? > > That or was this only expected to work on PIC, user-level code and anything touching for instance privilege escalation or with explicit address pointers, I/O port access, etc. just understood to not be applicable to such a direct translation? To tie it back to UNIX, for instance, was this thing also able to detect that a UNIX system call was being made and translate the 370 syscall mechanism into the PowerPC syscall mechanism? > > My main experience with emulation is console video games so in that realm, you're dealing not only with a different CPU architecture but system bus, memory map, peripheral controllers, etc. Essentially you're not just speaking another language, you're on another planet entirely. This has lead to a entrenched belief in my mind that this sort of "direct translation" of CPU operations is a non-starter in emulation hence my curiosity. If there's some historic approach to emulation efficiently handling system architecture diversity beyond just CPU instructions, I'm certainly interested! Surely things like this have some limitations. Self-modifying code, for example, would be more challenging (though not impossible) to implement. But for _most_ programs, where text and data are mapped separately, it wouldn't be that bad; if data formats are common across ISAs and the instruction sets are similar-ish, it wouldn't be that bad. For the mainframe to PowerPC, I imagine floating point would be the sticky wicket. > P.S. Feeling trepid about continuing this thread on TUHS rather than COFF, but resisting the urge to bump it (again). To keep it on topic, I'd mostly be interested in how this sort of thing would handle the UNIX system call mechanism, because that would certainly illuminate the general idea of translating something more complicated than an algorithm. In some sense, this is one of the easiest cases to support. The system call mechanism necessarily needs some method to trap into the kernel; the kernel, in turn, needs to look at the state of the user program to see what it should do in response to that trap. In the case of going across an ISA, the kernel's job is marginally harder in that it has to respond to having multiple ways to end up at the system call handler, but that's not so much different than supporting multiple system call conventions on a single system. For example, on x86, we have the SYSCALL instruction, but also SYSENTER and older software might initiate a syscall by means of the INT instruction (e.g., INT 0x80 or INT 0x40). Across ISAs, one might enter the kernel on an illegal instruction trap, in which case the trap handler will have access to the faulting address and can examine what's there; if it's e.g. a 370 instruction, one could interpret it and figure out what to do from there. Usually system calls are made by calling a stub function in, say, the C library. That stub then sets up state in whatever manner the system expects, such as poking the system call number and arguments into registers or putting them on the stack in a specific order or whatever; the stub then traps, at which point the kernel takes over, services the syscall, and (usually) returns control to userspace, the return value will be examined, errno might be set, and the stub "returns" to calling code. Of course, the process might have invoked `exit` or something, in which case control won't be returned to userspace. Or the call can block, context switches might happen, the arguments might be bad, the thing can be killed, etc, etc. Anyway, in the context of this kind of ISA translation, presumably the stubs would be interpreted and the interpreter would be smart enough to recognize the trap, in which case it might rewrite to a native trap of some kind, instead of relying on the illegal instruction trick. These techniques are rather old, and I think go back much further than we're suggesting. Knuth mentions nested translations in TAOCP (Volume 1, I believe), suggesting the technique was well-known as early as the mid-1960s. - Dan C. ^ permalink raw reply [flat|nested] 38+ messages in thread
* [TUHS] Re: machine code translation,as mental architecture models 2024-07-10 16:58 ` segaloco via TUHS 2024-07-10 17:15 ` Dan Cross @ 2024-07-10 19:23 ` Marc Donner 2024-07-10 19:38 ` Clem Cole 2024-07-10 21:18 ` Adam Thornton 1 sibling, 2 replies; 38+ messages in thread From: Marc Donner @ 2024-07-10 19:23 UTC (permalink / raw) To: segaloco; +Cc: tuhs [-- Attachment #1: Type: text/plain, Size: 3028 bytes --] I never dug that deep into her work. If I were to guess, I would say that this was aimed at user-space sorts of code. It was aimed at making it possible to run large old 370 binaries in Power PC architecture machines. If I recall correctly, there was some discussion of migrating off of the S370 (later S390 and then z-system) ISA to the Power PC architecture. My sense was that this was a research study to understand whether a naive translation like this could work. I can not imagine trying to translate system code in this way. ===== nygeek.net mindthegapdialogs.com/home <https://www.mindthegapdialogs.com/home> On Wed, Jul 10, 2024 at 1:07 PM segaloco via TUHS <tuhs@tuhs.org> wrote: > On Wednesday, July 10th, 2024 at 7:12 AM, Marc Donner < > marc.donner@gmail.com> wrote: > > > The basic technique was to load pages of 360 machine code unmodified > into Power PC memory, marking the pages as dirty. If the machine branched > into one of these pages the VM trap handler would take the page and > translate all of its code from 370 instructions to Power PC instructions. > Once that was done the branch, suitably recalculated, was reinstated. > > > > ... > > > > Marc > > ===== > > nygeek.net > > mindthegapdialogs.com/home > > Was this under the assumption everything else going on (bus architecture, > memory map, exception/trap handling, etc.) was exactly the same or was the > MMU for instance in the picture translating from 370 addresses to their > equivalents on whatever PowerPC machine was in play? > > That or was this only expected to work on PIC, user-level code and > anything touching for instance privilege escalation or with explicit > address pointers, I/O port access, etc. just understood to not be > applicable to such a direct translation? To tie it back to UNIX, for > instance, was this thing also able to detect that a UNIX system call was > being made and translate the 370 syscall mechanism into the PowerPC syscall > mechanism? > > My main experience with emulation is console video games so in that realm, > you're dealing not only with a different CPU architecture but system bus, > memory map, peripheral controllers, etc. Essentially you're not just > speaking another language, you're on another planet entirely. This has > lead to a entrenched belief in my mind that this sort of "direct > translation" of CPU operations is a non-starter in emulation hence my > curiosity. If there's some historic approach to emulation efficiently > handling system architecture diversity beyond just CPU instructions, I'm > certainly interested! > > - Matt G. > > P.S. Feeling trepid about continuing this thread on TUHS rather than COFF, > but resisting the urge to bump it (again). To keep it on topic, I'd mostly > be interested in how this sort of thing would handle the UNIX system call > mechanism, because that would certainly illuminate the general idea of > translating something more complicated than an algorithm. > [-- Attachment #2: Type: text/html, Size: 4011 bytes --] ^ permalink raw reply [flat|nested] 38+ messages in thread
* [TUHS] Re: machine code translation,as mental architecture models 2024-07-10 19:23 ` Marc Donner @ 2024-07-10 19:38 ` Clem Cole 2024-07-10 20:04 ` Marc Donner 2024-07-10 21:18 ` Adam Thornton 1 sibling, 1 reply; 38+ messages in thread From: Clem Cole @ 2024-07-10 19:38 UTC (permalink / raw) To: Marc Donner; +Cc: segaloco, tuhs [-- Attachment #1: Type: text/plain, Size: 998 bytes --] On Wed, Jul 10, 2024 at 3:23 PM Marc Donner <marc.donner@gmail.com> wrote: > I can not imagine trying to translate system code in this way. > Marc, you are better than that - proof by lack of imagination is not very effective😘 Seriously, the "VAX Compiler" that Paul describes made a great deal of sense to the VMS team when it was developed. It's all about *economics*, not technical purity. And solution actually worked really well; as Paul points out, it lived for many different ISAs that followed VAX at DEC and now VSi. What I always was amazed by was the Cutler use assembler in the first place since DEC had production quality BLISS compilers. But as Dave Cane [VAX750 lead] once put it, it was the world's greatest assembler machine. Dave (famously) hated BLISS but was one heck of an assembly programmer. VMS both at the kernel and systems level, was (is) in assembler, so treating the VAX as a HLL and "compiling" to a new ISA was solid economics. ᐧ [-- Attachment #2: Type: text/html, Size: 3022 bytes --] ^ permalink raw reply [flat|nested] 38+ messages in thread
* [TUHS] Re: machine code translation,as mental architecture models 2024-07-10 19:38 ` Clem Cole @ 2024-07-10 20:04 ` Marc Donner 0 siblings, 0 replies; 38+ messages in thread From: Marc Donner @ 2024-07-10 20:04 UTC (permalink / raw) To: Clem Cole; +Cc: segaloco, The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 1316 bytes --] Picky, picky, Clem. Given the dramatic differences in I/O architecture, interrupt handling, and virtual memory between s370 and Power PC, it makes little sense to try to translate system code this way. On Wed, Jul 10, 2024, 15:39 Clem Cole <clemc@ccc.com> wrote: > > > On Wed, Jul 10, 2024 at 3:23 PM Marc Donner <marc.donner@gmail.com> wrote: > >> I can not imagine trying to translate system code in this way. >> > Marc, you are better than that - proof by lack of imagination is not > very effective😘 > > Seriously, the "VAX Compiler" that Paul describes made a great deal of > sense to the VMS team when it was developed. It's all about *economics*, > not technical purity. And solution actually worked really well; as Paul > points out, it lived for many different ISAs that followed VAX at DEC and > now VSi. > > What I always was amazed by was the Cutler use assembler in the first place > since DEC had production quality BLISS compilers. But as Dave Cane > [VAX750 lead] once put it, it was the world's greatest assembler machine. > Dave (famously) hated BLISS but was one heck of an assembly programmer. > VMS both at the kernel and systems level, was (is) in assembler, so > treating the VAX as a HLL and "compiling" to a new ISA was solid economics. > ᐧ > [-- Attachment #2: Type: text/html, Size: 3622 bytes --] ^ permalink raw reply [flat|nested] 38+ messages in thread
* [TUHS] Re: machine code translation,as mental architecture models 2024-07-10 19:23 ` Marc Donner 2024-07-10 19:38 ` Clem Cole @ 2024-07-10 21:18 ` Adam Thornton 1 sibling, 0 replies; 38+ messages in thread From: Adam Thornton @ 2024-07-10 21:18 UTC (permalink / raw) To: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 252 bytes --] The Cathy May paper can be found at: https://dl.acm.org/doi/pdf/10.1145/29650.29651 And it's quite interesting; the first time I was aware of work like this was six or seven years later, when ARDI's Mac emulator "Executor" was the new hotness. Adam [-- Attachment #2: Type: text/html, Size: 443 bytes --] ^ permalink raw reply [flat|nested] 38+ messages in thread
* [TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? @ 2024-07-07 13:57 Noel Chiappa 2024-07-07 16:43 ` John Levine 0 siblings, 1 reply; 38+ messages in thread From: Noel Chiappa @ 2024-07-07 13:57 UTC (permalink / raw) To: tuhs; +Cc: jnc > From: Steve Jenkin > C wasn't the first standardised coding language, FORTRAN & COBOL at > least were before it There were a ton; Algol-60 is the most imppotant one I can think of. (I was thinking that Algol-60 was probably an important precursor to BCPL, which was the predecessor to C, but Richards' first BCPL paper: https://dl.acm.org/doi/10.1145/1476793.1476880 "BCPL: A tool for compiler writing and system programming" doesn't call it out, only CPL. However, CPL does admit its dues to Algol-60: "CPL is to a large extent based on ALGOL 60".) Noel ^ permalink raw reply [flat|nested] 38+ messages in thread
* [TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? 2024-07-07 13:57 [TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? Noel Chiappa @ 2024-07-07 16:43 ` John Levine 0 siblings, 0 replies; 38+ messages in thread From: John Levine @ 2024-07-07 16:43 UTC (permalink / raw) To: tuhs; +Cc: jnc It appears that Noel Chiappa <jnc@mercury.lcs.mit.edu> said: > > From: Steve Jenkin > > > C wasn't the first standardised coding language, FORTRAN & COBOL at > > least were before it > >There were a ton; Algol-60 is the most imppotant one I can think of. Only sort of. It didn't have a standard concrete representation, and it didn't have any I/O, so it was fine for portable elegant numerical solutions to partial differential equations, but hopeless for portably reading in a list of numbers and printing the sum. In 1964 they defined what were supposed to be standard I/O routines but it was too little too late. Wirth's Algol W and Pascal were supposed to fix that but Pascal never was all that portable in practice. R's, John ^ permalink raw reply [flat|nested] 38+ messages in thread
* [TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix? @ 2024-07-05 7:36 Dave Horsfall 2024-07-05 10:18 ` Peter Yardley 0 siblings, 1 reply; 38+ messages in thread From: Dave Horsfall @ 2024-07-05 7:36 UTC (permalink / raw) To: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 1426 bytes --] On Thu, 4 Jul 2024, Adam Thornton wrote: > ARM or one of the smaller RISC-V flavor-sets (RISC-V is super-modular) > would be a perfectly reasonable architecture to learn these days. After > the PDP-11 but before ARM I'd'a suggested 68000. Definitely NOT x86 and > its betentacled descendants. Even so, you'd still want to treat it (if > you're learning "how do computers work?") as if it were not superscalar, > even though it obviously is. Which I guess is pushing me into "please > let me just pretend it's a PDP-11 and keep all the scary pipelining and > speculative execution and all the things that are hard to reason about > below the layer where I need to care" territory. Pretty much anything with a linear address space, an orthogonal instruction set, and a stack will do, I think. Was it John Gilmore who said "Segment registers are for worms"? I dips me lid to those souls who implemented ALGOLW on the 360... > And yeah, if you need me to sweep the floors, I'll sweep the floors, but > if I'm needed to sweep the floors often, there's a management problem > here, in that you can hire people who are much better at sweeping floors > than I am for much less money than you hired me to do software > engineering for. I've worked in places where I've swept the floor (and also did the dishes etc); I'll still need to be paid the same salary, though :-) -- Dave ^ permalink raw reply [flat|nested] 38+ messages in thread
* [TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix? 2024-07-05 7:36 [TUHS] " Dave Horsfall @ 2024-07-05 10:18 ` Peter Yardley 2024-07-05 21:38 ` [TUHS] Re: mental architecture models, " John Levine 0 siblings, 1 reply; 38+ messages in thread From: Peter Yardley @ 2024-07-05 10:18 UTC (permalink / raw) To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society The DG Nova had a pretty nice architecture. 2 accumulators, 2 index registers, program counter, status register. No stack register tho. There was a micro processor version by Fairchild. Sent from my iPhone > On 5 Jul 2024, at 5:36 pm, Dave Horsfall <dave@horsfall.org> wrote: > > On Thu, 4 Jul 2024, Adam Thornton wrote: > >> ARM or one of the smaller RISC-V flavor-sets (RISC-V is super-modular) >> would be a perfectly reasonable architecture to learn these days. After >> the PDP-11 but before ARM I'd'a suggested 68000. Definitely NOT x86 and >> its betentacled descendants. Even so, you'd still want to treat it (if >> you're learning "how do computers work?") as if it were not superscalar, >> even though it obviously is. Which I guess is pushing me into "please >> let me just pretend it's a PDP-11 and keep all the scary pipelining and >> speculative execution and all the things that are hard to reason about >> below the layer where I need to care" territory. > > Pretty much anything with a linear address space, an orthogonal > instruction set, and a stack will do, I think. > > Was it John Gilmore who said "Segment registers are for worms"? > > I dips me lid to those souls who implemented ALGOLW on the 360... > >> And yeah, if you need me to sweep the floors, I'll sweep the floors, but >> if I'm needed to sweep the floors often, there's a management problem >> here, in that you can hire people who are much better at sweeping floors >> than I am for much less money than you hired me to do software >> engineering for. > > I've worked in places where I've swept the floor (and also did the dishes > etc); I'll still need to be paid the same salary, though :-) > > -- Dave ^ permalink raw reply [flat|nested] 38+ messages in thread
* [TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? 2024-07-05 10:18 ` Peter Yardley @ 2024-07-05 21:38 ` John Levine 2024-07-05 21:49 ` Larry McVoy 2024-07-05 22:10 ` Dan Cross 0 siblings, 2 replies; 38+ messages in thread From: John Levine @ 2024-07-05 21:38 UTC (permalink / raw) To: tuhs; +Cc: peter.martin.yardley It appears that Peter Yardley <peter.martin.yardley@gmail.com> said: >The DG Nova had a pretty nice architecture. 2 accumulators, 2 index registers, 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 simplified 386 leaving out the dumb or useless stuff. I ignore the segments which are useless other than for 286 emulation, and some of the strange instructions like decimal 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. ARM should be OK too but I have to ask which ARM? There have been so many generations often not backward compatible. ^ permalink raw reply [flat|nested] 38+ messages in thread
* [TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? 2024-07-05 21:38 ` [TUHS] Re: mental architecture models, " John Levine @ 2024-07-05 21:49 ` Larry McVoy 2024-07-05 22:08 ` Charles H Sauer (he/him) 2024-07-05 23:17 ` John Levine 2024-07-05 22:10 ` Dan Cross 1 sibling, 2 replies; 38+ messages in thread From: Larry McVoy @ 2024-07-05 21:49 UTC (permalink / raw) To: John Levine; +Cc: tuhs, peter.martin.yardley On Fri, Jul 05, 2024 at 05:38:03PM -0400, John Levine wrote: > It appears that Peter Yardley <peter.martin.yardley@gmail.com> said: > >The DG Nova had a pretty nice architecture. 2 accumulators, 2 index registers, 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 simplified 386 > leaving out the dumb or useless stuff. I took a look at x86 in 386/486 days and found it to be enough of a mess that I stopped looking. In no way did it compare the simplicity and elegance of the PDP-11. I had a TA, Ken Witte, who could read octal dumps of PDP-11 assembly like it was C. I'm pretty sure the way the instructions were encoded was a big part of what made that possible. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat ^ permalink raw reply [flat|nested] 38+ messages in thread
* [TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? 2024-07-05 21:49 ` Larry McVoy @ 2024-07-05 22:08 ` Charles H Sauer (he/him) 2024-07-05 22:24 ` Larry McVoy 2024-07-05 23:17 ` John Levine 1 sibling, 1 reply; 38+ messages in thread From: Charles H Sauer (he/him) @ 2024-07-05 22:08 UTC (permalink / raw) To: tuhs On 7/5/2024 4:49 PM, Larry McVoy wrote: > On Fri, Jul 05, 2024 at 05:38:03PM -0400, John Levine wrote: >> It appears that Peter Yardley <peter.martin.yardley@gmail.com> said: >>> The DG Nova had a pretty nice architecture. 2 accumulators, 2 index registers, 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 simplified 386 >> leaving out the dumb or useless stuff. > > I took a look at x86 in 386/486 days and found it to be enough of a mess that > I stopped looking. In no way did it compare the simplicity and elegance > of the PDP-11. I had a TA, Ken Witte, who could read octal dumps of PDP-11 > assembly like it was C. I'm pretty sure the way the instructions were > encoded was a big part of what made that possible. Assuming you mean the same Kendall Witte that spearheaded Dell SVR4 (https://notes.technologists.com/notes/2008/01/10/a-brief-history-of-dell-unix/), he is quite fluent in X86 as well. After Dell SVR4 he became prominent in Dell firmware work. I saw him just over a year ago at a gathering of Dell "old timers". -- voice: +1.512.784.7526 e-mail: sauer@technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/LinkedIn/Twitter: CharlesHSauer ^ permalink raw reply [flat|nested] 38+ messages in thread
* [TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? 2024-07-05 22:08 ` Charles H Sauer (he/him) @ 2024-07-05 22:24 ` Larry McVoy 0 siblings, 0 replies; 38+ messages in thread From: Larry McVoy @ 2024-07-05 22:24 UTC (permalink / raw) To: Charles H Sauer (he/him); +Cc: tuhs On Fri, Jul 05, 2024 at 05:08:01PM -0500, Charles H Sauer (he/him) wrote: > Assuming you mean the same Kendall Witte that spearheaded Dell SVR4 (https://notes.technologists.com/notes/2008/01/10/a-brief-history-of-dell-unix/), > he is quite fluent in X86 as well. After Dell SVR4 he became prominent in > Dell firmware work. I saw him just over a year ago at a gathering of Dell > "old timers". Yep, that's him. I have fond memories of bring a six pack and an octal dump to his place and him swigging a beer and reading it with ease. Great guy. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat ^ permalink raw reply [flat|nested] 38+ messages in thread
* [TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? 2024-07-05 21:49 ` Larry McVoy 2024-07-05 22:08 ` Charles H Sauer (he/him) @ 2024-07-05 23:17 ` John Levine 2024-07-06 12:52 ` sjenkin 2024-07-07 5:33 ` arnold 1 sibling, 2 replies; 38+ messages in thread From: John Levine @ 2024-07-05 23:17 UTC (permalink / raw) To: tuhs According to Larry McVoy <lm@mcvoy.com>: >> 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 simplified 386 >> leaving out the dumb or useless stuff. > >I took a look at x86 in 386/486 days and found it to be enough of a mess that >I stopped looking. In no way did it compare the simplicity and elegance >of the PDP-11. If you're looking for simplicity and elegance, I can still remember most of the PDP-8's instruction codes so I could disassemble at sight. But it's not a very good model for a modern computer. I realized a while ago that the only really important things in an architecture are the addressing model, e.g., flat byte addressed little-endian, and the data formats, e.g., two's complement integers, ASCII or UTF-8 text, IEEE floating point. Back in the day getting a program to act the same on different computers, was really hard, with the switch from IBM 7090 (36 bit word addressed binary floating point) to IBM 360 (32 or 64 bit byte addressed hex floating point) the most famous example. These days we write code and compile it for x64 or ARM or RISC-V and for the most part, it just works because the data formats and addressing are all the same. ^ permalink raw reply [flat|nested] 38+ messages in thread
* [TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? 2024-07-05 23:17 ` John Levine @ 2024-07-06 12:52 ` sjenkin 2024-07-06 14:02 ` John R Levine 2024-07-06 15:58 ` Clem Cole 2024-07-07 5:33 ` arnold 1 sibling, 2 replies; 38+ messages in thread From: sjenkin @ 2024-07-06 12:52 UTC (permalink / raw) To: TUHS; +Cc: John Levine C wasn’t the first standardised coding language, FORTRAN & COBOL at least were before it, so there were multi-platform source libraries and shared source, though often single platform. From what I know, vendor extensions of FORTAN, optimised for their hardware, were common, making high-performance, portable source difficult or impossible. 6-bit and 8-bit chars were the least of it. Is this right: C was the first ’systems tool’ language + libraries available across many platforms. Notionally, source code could be ported with zero or minimal change. It made possible portable languages like PERL, PHP, Python. [ then came the "Tower of Babel" requiring tools like ‘autoconf’ ] C became a bootstrapping environment for other portable languages & tools, e.g. C++ & Golang. Secondly, portable systems tool languages with a common 2-part design of parser/front-end providing an abstract syntax tree to multiple back-ends with platform specific code-generators. Are these back-ends where most of the assembler, memory model and instruction optimisation take place now? > On 6 Jul 2024, at 09:17, John Levine <johnl@taugh.com> wrote: > > Back in the day getting a program to act the same on different > computers, was really hard, with the switch from IBM 7090 (36 bit word > addressed binary floating point) to IBM 360 (32 or 64 bit byte > addressed hex floating point) the most famous example. These days we > write code and compile it for x64 or ARM or RISC-V and for the most > part, it just works because the data formats and addressing are all > the same. -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin ^ permalink raw reply [flat|nested] 38+ messages in thread
* [TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? 2024-07-06 12:52 ` sjenkin @ 2024-07-06 14:02 ` John R Levine 2024-07-06 15:58 ` Clem Cole 1 sibling, 0 replies; 38+ messages in thread From: John R Levine @ 2024-07-06 14:02 UTC (permalink / raw) To: sjenkin, TUHS On Sat, 6 Jul 2024, sjenkin@canb.auug.org.au wrote: > C wasn’t the first standardised coding language, FORTRAN & COBOL at least were before it, > so there were multi-platform source libraries and shared source, though often single platform. > > From what I know, vendor extensions of FORTAN, optimised for their hardware, were common, > making high-performance, portable source difficult or impossible. 6-bit and 8-bit chars were the least of it. Even without vendor extensions, writing portable Fortran code was hard. Different floating point formats give you different results, and architectural differences can bite you. One famous example is that the 709x required word alignment, but S/360 had 4 byte aligned floats and 8 byte aligned doubles, so this: REAL R(100) DOUBLE PRECISION D(10) EQUIVALENCE (R(2), D(1)) would work fine on a 7090 but crash on a 360. That was painful enough that one of the first things they changed on S/370 was to allow misaligned data. I never wrote much COBOL but it had structured data (the ancestor of C structs) and "redefines" for overlaying structures which could bite you when different machines had different size or alignment. There were also a lot of different character sets which led to bugs when code had implicit assumptions about collating sequences, e.g., do numbers come before letters as in ASCII, or after as in EBCDIC. The fact that everything now has 8 bit byte addressed memory with power of two data sizes and everything is ASCII makes all these problems go away. > Is this right: > > C was the first ’systems tool’ language + libraries available across many platforms. > Notionally, source code could be ported with zero or minimal change. > It made possible portable languages like PERL, PHP, Python. I think so. There were previous system languages like a PL/I subset on Multics or PL/S on IBM or PL/M on micros but I don't think any of them had multiple targets. > Secondly, portable systems tool languages with a common 2-part design > of parser/front-end providing an abstract syntax tree > to multiple back-ends with platform specific code-generators. > > Are these back-ends where most of the assembler, memory model and instruction optimisation take place now? That's the standard way to build a compiler. Back in the late 1950s someone had the bright idea to invent a common intermediate language they called UNCOL so all of the front ends could produce UNCOL and all of the back ends could translate from UNCOL thereby reducing the NxM compiler problem to N+M. It never worked, both because the semantic differences between source languages are larger than they look, and the machine architectures of the era were wildly different. Now we have GCC and LLVM which are sort of UNCOL-ish, but mostly because the back ends are all so similar. The instruction sets may be different but the data formats are all the same. R's, John ^ permalink raw reply [flat|nested] 38+ messages in thread
* [TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? 2024-07-06 12:52 ` sjenkin 2024-07-06 14:02 ` John R Levine @ 2024-07-06 15:58 ` Clem Cole 2024-07-06 20:56 ` John R Levine 1 sibling, 1 reply; 38+ messages in thread From: Clem Cole @ 2024-07-06 15:58 UTC (permalink / raw) To: sjenkin; +Cc: TUHS, John Levine [-- Attachment #1: Type: text/plain, Size: 2565 bytes --] On Sat, Jul 6, 2024 at 8:52 AM <sjenkin@canb.auug.org.au> wrote: > Is this right: > > C was the first ’systems tool’ language + libraries available > across many platforms. > No !! Not even close. ESPOL predators all of them, although one can say since it was only available on Burroughs large, medium, and small systems - it was retargeted, but not widely used. Other systems programming languages followed, BCPL, BLISS, PL/360 and even B before C. If you consider PL/M a child of PL/360 (which is was more than child of PL/1 if you look at it), all of the others have code generators and libraries for multiple ISA and OS and did before C did. That said, I don't think any fo them have as many targets as C and many FORTRAN. I might accept this rephrasing: *While other systems' programming languages existed, and many were retargets to multiple ISA/OS combinations, because of its appearance as a language with a licensed but open implementation, at the time of the first widespread available of inexpensive microprocessors, the language and it libraries became (and continues to remain) the widest and most popular systems development language in production use.* WRT: FORTRAN. John is correct; Kahan and his students demonstrated the core problem with Paranoia ( https://www.netlib.org/paranoia/ ). But remember that the FP issue was more than just a FORTRAN problem [BTW: I took that class in those days]. You are correct that private extensions were also a problem, although through F4 - the 'standard was IBM's 'G' compiler, and while most vendors ensured they could pass the ANSI test suite, smart vendors made sure they were IBM FORTRAN-G compliant. A good example is the original Adventure game written on DEC's PDP-10 FORTRAN compiler in the late 1970s, but it seemed to be running on anything a FORTRAN compiler within weeks of its release on the ARPAnet [I know that my peeps and I fed it to FORTRAN-G on TSS]. The same issue of "ANSI Standard" vs "De Facto Standard" occurred with F77, but the de facto standard was VMS FORTRAN by that time That said, by F90, which is also post IEEE 754 [FP format] - portable FORTRAN code in the wild was really not the issue it had been in the 60s and 70s. FWIW: With FORTRAN 2018, the compiler most people reference and for code that runs on most supers is Intel's (DEC derived) ifort - but even Intel is replacing that with their investment in IFX, the LLVM-based backend using Intel rewritten (and FOSS) LLVM FORTRAN front end. Clem [-- Attachment #2: Type: text/html, Size: 5396 bytes --] ^ permalink raw reply [flat|nested] 38+ messages in thread
* [TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? 2024-07-06 15:58 ` Clem Cole @ 2024-07-06 20:56 ` John R Levine 2024-07-06 21:32 ` Charles H Sauer (he/him) 0 siblings, 1 reply; 38+ messages in thread From: John R Levine @ 2024-07-06 20:56 UTC (permalink / raw) To: Clem Cole, sjenkin; +Cc: TUHS On Sat, 6 Jul 2024, Clem Cole wrote: > ESPOL predators all of them, although one can say since it was only > available on Burroughs large, medium, and small systems - it was retargeted, > but not widely used. Good point. > Other systems programming languages followed, BCPL, BLISS, PL/360 and even > B before C. If you consider PL/M a child of PL/360 (which is was more than > child of PL/1 if you look at it), all of the others have code generators > and libraries for multiple ISA and OS and did before C did. That said, I > don't think any fo them have as many targets as C and many FORTRAN. Untangling the sequence of all this stuff is hard. BCPL was indeed retargeted at a lot of machines but it's not clear how portable programs were since the word sizes varied so much from 16 to 60 bits, but couldn't deal with byte addressed memory which is a large reason we have C. The original version of BLISS was only for the PDP-10. DEC retargeted it to the PDP-11 and VAX, but I think that was after Unix moved to the Interdata and possibly other machines. PL360 was Wirth's implentation language for Algol W, a 360 assembler with Algol-like syntax that had nothing to do with PL/I and only targeted the 360. I used it, it was pretty nice. Are you maybe thinking of IBM's PL.8 or PL/S? The former was originally for the 801, later S/360 and ROMP, the latter used for S/360 system programming. PL.8 was about 80% of PL.I, hence the name, PL/S a subset with some hackery like register declarations and in-line assembler. R's, John ^ permalink raw reply [flat|nested] 38+ messages in thread
* [TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? 2024-07-06 20:56 ` John R Levine @ 2024-07-06 21:32 ` Charles H Sauer (he/him) 2024-07-06 23:46 ` Peter Yardley ` (2 more replies) 0 siblings, 3 replies; 38+ messages in thread From: Charles H Sauer (he/him) @ 2024-07-06 21:32 UTC (permalink / raw) To: tuhs On 7/6/2024 3:56 PM, John R Levine wrote: > On Sat, 6 Jul 2024, Clem Cole wrote: >> ESPOL predators all of them, although one can say since it was only >> available on Burroughs large, medium, and small systems - it was >> retargeted, >> but not widely used. > > Good point. > >> Other systems programming languages followed, BCPL, BLISS, PL/360 and >> even >> B before C. If you consider PL/M a child of PL/360 (which is was more >> than >> child of PL/1 if you look at it), all of the others have code generators >> and libraries for multiple ISA and OS and did before C did. That said, I >> don't think any fo them have as many targets as C and many FORTRAN. > > Untangling the sequence of all this stuff is hard. BCPL was indeed > retargeted at a lot of machines but it's not clear how portable programs > were since the word sizes varied so much from 16 to 60 bits, but > couldn't deal with byte addressed memory which is a large reason we have C. > > The original version of BLISS was only for the PDP-10. DEC retargeted > it to the PDP-11 and VAX, but I think that was after Unix moved to the > Interdata and possibly other machines. > > PL360 was Wirth's implentation language for Algol W, a 360 assembler > with Algol-like syntax that had nothing to do with PL/I and only > targeted the 360. I used it, it was pretty nice. > > Are you maybe thinking of IBM's PL.8 or PL/S? The former was originally > for the 801, later S/360 and ROMP, the latter used for S/360 system > programming. PL.8 was about 80% of PL.I, hence the name, PL/S a subset > with some hackery like register declarations and in-line assembler. > > R's, > John I like the 80% explanation, but suspect PL.8 was really named PL.8 to go along with the 801 processor architecture defined in Building 801 aka Thomas J. Watson Research Center in Yorktown Heights. There are probably living Yorktown alumni that could be definitive. I found PL/I quite usable as long as one kept it simple. But then, I also found Fortran usable as long as one kept it simple. Regarding Fortran portability, I did all my dissertation work on punched cards using CDC Fortran on the 6400/6600 at the UT-Austin computation center. I brought several boxes of cards to Yorktown and don't remember any significant difficulty getting my simulator and other programs to run on VM/370 there. The absence of pointers and structures in Fortran was annoying. Eventually I used SNOBOL to quickly translate the Fortran to PL/I (https://technologists.com/sauer/RESQPPP.pdf). Charlie -- voice: +1.512.784.7526 e-mail: sauer@technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/LinkedIn/Twitter: CharlesHSauer ^ permalink raw reply [flat|nested] 38+ messages in thread
* [TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? 2024-07-06 21:32 ` Charles H Sauer (he/him) @ 2024-07-06 23:46 ` Peter Yardley 2024-07-07 17:43 ` James Frew 2024-07-07 1:39 ` John Levine 2024-07-08 21:39 ` Aron Insinga 2 siblings, 1 reply; 38+ messages in thread From: Peter Yardley @ 2024-07-06 23:46 UTC (permalink / raw) To: Charles H Sauer (he/him); +Cc: tuhs There was a ‘military’ standard ForTran 66. It was more difficult to use than the various ForTran IVs, which had several niceties like string literals, but the code was at least more portable. This was about 40 years ago so details are fading. > On 7 Jul 2024, at 7:32 AM, Charles H Sauer (he/him) <sauer@technologists.com> wrote: > > > > On 7/6/2024 3:56 PM, John R Levine wrote: >> On Sat, 6 Jul 2024, Clem Cole wrote: >>> ESPOL predators all of them, although one can say since it was only >>> available on Burroughs large, medium, and small systems - it was retargeted, >>> but not widely used. >> Good point. >>> Other systems programming languages followed, BCPL, BLISS, PL/360 and even >>> B before C. If you consider PL/M a child of PL/360 (which is was more than >>> child of PL/1 if you look at it), all of the others have code generators >>> and libraries for multiple ISA and OS and did before C did. That said, I >>> don't think any fo them have as many targets as C and many FORTRAN. >> Untangling the sequence of all this stuff is hard. BCPL was indeed retargeted at a lot of machines but it's not clear how portable programs were since the word sizes varied so much from 16 to 60 bits, but couldn't deal with byte addressed memory which is a large reason we have C. >> The original version of BLISS was only for the PDP-10. DEC retargeted it to the PDP-11 and VAX, but I think that was after Unix moved to the Interdata and possibly other machines. >> PL360 was Wirth's implentation language for Algol W, a 360 assembler with Algol-like syntax that had nothing to do with PL/I and only targeted the 360. I used it, it was pretty nice. >> Are you maybe thinking of IBM's PL.8 or PL/S? The former was originally for the 801, later S/360 and ROMP, the latter used for S/360 system programming. PL.8 was about 80% of PL.I, hence the name, PL/S a subset with some hackery like register declarations and in-line assembler. >> R's, >> John > > I like the 80% explanation, but suspect PL.8 was really named PL.8 to go along with the 801 processor architecture defined in Building 801 aka Thomas J. Watson Research Center in Yorktown Heights. There are probably living Yorktown alumni that could be definitive. > > I found PL/I quite usable as long as one kept it simple. But then, I also found Fortran usable as long as one kept it simple. Regarding Fortran portability, I did all my dissertation work on punched cards using CDC Fortran on the 6400/6600 at the UT-Austin computation center. I brought several boxes of cards to Yorktown and don't remember any significant difficulty getting my simulator and other programs to run on VM/370 there. The absence of pointers and structures in Fortran was annoying. Eventually I used SNOBOL to quickly translate the Fortran to PL/I (https://technologists.com/sauer/RESQPPP.pdf). > > Charlie > > -- > voice: +1.512.784.7526 e-mail: sauer@technologists.com > fax: +1.512.346.5240 Web: https://technologists.com/sauer/ > Facebook/Google/LinkedIn/Twitter: CharlesHSauer Peter Yardley peter.martin.yardley@gmail.com ^ permalink raw reply [flat|nested] 38+ messages in thread
* [TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? 2024-07-06 23:46 ` Peter Yardley @ 2024-07-07 17:43 ` James Frew 0 siblings, 0 replies; 38+ messages in thread From: James Frew @ 2024-07-07 17:43 UTC (permalink / raw) To: tuhs On 2024-07-06 16:46, Peter Yardley wrote: > There was a ‘military’ standard ForTran 66. It was more difficult to use than the various ForTran IVs, which had several niceties like string literals, but the code was at least more portable. This was about 40 years ago so details are fading. https://apps.dtic.mil/sti/tr/pdf/ADA328606.pdf Not the actual standard, but the single most useful reference on porting old FORTRAN. From the Foreword: "This FORTRAN volume presents material that will assist in understanding FORTRAN 66 and its replacement, FORTRAN 77. Because even a superficial comparison of the two language variants will involve contrasting their respective syntaxes, a set of FORTRAN 66 grammar rules is included: These rules, expressed in chart form, are comparable to rules that define FORTRAN 77. Next, there are two chapters of observations on what using standard FORTRAN 66 implies, and how the 1966 Standard is often interpreted and stretched to achieve practical ends. Finally, a comparison of the new FORTRAN 77 with FORTRAN 66 shows how the language has changed, and what converting older programs must entail. The four chapters address programmers concerned with FORTRAN conversions, managers engaged in programming standards, and other practitioners interested in system influences upon languages. Since the text touches upon several general programming aspects (input/output, storage allocation and lifetimes, control structures), the volume's appeal will extend beyond the immediate FORTRAN community." Cheers, /Frew P.S.: If anybody cares, I have a cleaner scan that I can share. ^ permalink raw reply [flat|nested] 38+ messages in thread
* [TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? 2024-07-06 21:32 ` Charles H Sauer (he/him) 2024-07-06 23:46 ` Peter Yardley @ 2024-07-07 1:39 ` John Levine 2024-07-08 21:39 ` Aron Insinga 2 siblings, 0 replies; 38+ messages in thread From: John Levine @ 2024-07-07 1:39 UTC (permalink / raw) To: tuhs It appears that Charles H Sauer (he/him) <sauer@technologists.com> said: >I like the 80% explanation, but suspect PL.8 was really named PL.8 to go >along with the 801 processor architecture defined in Building 801 aka >Thomas J. Watson Research Center in Yorktown Heights. There are probably >living Yorktown alumni that could be definitive. John Cocke said in a paper in IBM J R&D V44 #1/2, Jan 2000, p 50: The result [of the language design] was the PL.8 language, the ".8" implying that it had about 80% of the richness of PL/I. PL.8 bore the same relation to PL/I as the 801 architecture had to System/370. Not gonna argue with him. >I found PL/I quite usable as long as one kept it simple. But then, I >also found Fortran usable as long as one kept it simple. Regarding >Fortran portability, I did all my dissertation work on punched cards >using CDC Fortran on the 6400/6600 at the UT-Austin computation center. >I brought several boxes of cards to Yorktown and don't remember any >significant difficulty getting my simulator and other programs to run on >VM/370 there. The absence of pointers and structures in Fortran was >annoying. Eventually I used SNOBOL to quickly translate the Fortran to >PL/I (https://technologists.com/sauer/RESQPPP.pdf). For the most part Fortran could be pretty portable. The hard parts were when you were trying to get reliable numeric results in complex calculations, or you were doing stuff that Fortran didn't do very well like pre-F77 string handling. R's, JOhn ^ permalink raw reply [flat|nested] 38+ messages in thread
* [TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? 2024-07-06 21:32 ` Charles H Sauer (he/him) 2024-07-06 23:46 ` Peter Yardley 2024-07-07 1:39 ` John Levine @ 2024-07-08 21:39 ` Aron Insinga 2024-07-08 22:14 ` Paul Winalski 2024-07-08 22:17 ` Rik Farrow 2 siblings, 2 replies; 38+ messages in thread From: Aron Insinga @ 2024-07-08 21:39 UTC (permalink / raw) To: Charles H Sauer (he/him), tuhs See https://www.cs.tufts.edu/~nr/cs257/archive/ronald-brender/bliss.pdf C allowed writing Unix with a limited amount of assembly code, but CMU's original BLISS-10 was designed to write an operating system with *no* outside assembly code. Features like the 'MACHOP' (machine operation) builtin function made use of the orthogonality of the PDP-10 instruction format to execute machine-specific instructions in-line. (cf. the 'asm' extensions in some implementations of C.) The PDP-10's 36-bit word allowed single-precision floating point numbers to fit in machine words, so it had infix operators for both integer and single-precision floating point operations (which I presume were adequate for an operating system). When DEC chose an implementation language, they knew about C but it had not yet escaped from Bell Labs. PL/I was considered, but there were questions of whether or not it would be suitable for a minicomputer. On the other hand, by choosing BLISS, DEC could start with the BLISS-11 cross compiler running on the PDP-10, which is described in https://en.wikipedia.org/wiki/The_Design_of_an_Optimizing_Compiler BLISS-11 and DEC's Common BLISS had changes necessitated by different word lengths and architectures, including different routine linkages such as INTERRUPT, access to machine-specific operations such as INSQTI, and multiple-precision floating point operations using builtin functions which used the addresses of data instead of the values. In order to port VMS to new architectures, DEC/HP/VSI retargeted and ported the BLISS compilers to new architectures. What I find amazing is that they also turned the VAX MACRO assembly language (in which some of the VMS operating system was written) into a portable implementation language by 'compiling' the high-level CISC VAX instructions (and addressing modes) into sequences of RISC instructions. I believe that this is similar to how modern CPU chips dynamically translate x86_64 instructions (or whatever) to an internal RISC format. - Aron (Disclaimer: I worked at DEC for a long time and VSI for a short time, but I wasn't responsible for the above work.) On 7/6/24 17:32, Charles H Sauer (he/him) wrote: > On 7/6/2024 3:56 PM, John R Levine wrote: >> On Sat, 6 Jul 2024, Clem Cole wrote: >>> Other systems programming languages followed, BCPL, BLISS, PL/360 >>> and even >>> B before C. >> The original version of BLISS was only for the PDP-10. DEC >> retargeted it to the PDP-11 and VAX, but I think that was after Unix >> moved to the Interdata and possibly other machines. ^ permalink raw reply [flat|nested] 38+ messages in thread
* [TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? 2024-07-08 21:39 ` Aron Insinga @ 2024-07-08 22:14 ` Paul Winalski 2024-07-09 1:04 ` Aron Insinga 2024-07-08 22:17 ` Rik Farrow 1 sibling, 1 reply; 38+ messages in thread From: Paul Winalski @ 2024-07-08 22:14 UTC (permalink / raw) To: Computer Old Farts Followers; +Cc: tuhs [-- Attachment #1: Type: text/plain, Size: 3313 bytes --] [redirecting this to COFF] On Mon, Jul 8, 2024 at 5:40 PM Aron Insinga <aki@insinga.com> wrote: > > When DEC chose an implementation language, they knew about C but it had > not yet escaped from Bell Labs. PL/I was considered, but there were > questions of whether or not it would be suitable for a minicomputer. On > the other hand, by choosing BLISS, DEC could start with the BLISS-11 > cross compiler running on the PDP-10, which is described in > https://en.wikipedia.org/wiki/The_Design_of_an_Optimizing_Compiler > BLISS-11 > <https://en.wikipedia.org/wiki/The_Design_of_an_Optimizing_CompilerBLISS-11> > and DEC's Common BLISS had changes necessitated by different > word lengths and architectures, including different routine linkages > such as INTERRUPT, access to machine-specific operations such as INSQTI, > and multiple-precision floating point operations using builtin functions > which used the addresses of data instead of the values. > > In order to port VMS to new architectures, DEC/HP/VSI retargeted and > ported the BLISS compilers to new architectures. > > There have in general been two approaches to achieving language portability (machine independence). One of them is to provide only abstract data types and operations on them and to completely hide the machine implementation. PL/I and especially Ada use this approach. BLISS does the exact opposite. It takes the least common denominator. All machine architectures have machine words and ways to pick them apart. BLISS has only one data type--the word. It provides a few simple arithmetic and logical operations and also syntax for operating on contiguous sets of bits within a word. More complicated things such as floating point are done by what look like routine calls but are actually implemented in the compiler. BLISS is also a true, full-blown expression language. Statement constructs such as if/then/else have a value and can be used in expressions. In C terminology, everything in BLISS is a lvalue. A semicolon terminates an expression and throws its value away. BLISS is also unusual in that it has an explicit fetch operator, the dot (.). The assignment expression (=) has the semantics "evaluate the expression to the right of the equal sign and then store that value in the location specified by the expression to the left of the equal sign". Supposing that a and b are identifiers for memory locations, the expression: a = b; means "place b (the address of a memory location) at the location given by a (also a memory location)". This is the equivalent of: a = &b; in C. To get C's version of "a = b;" in BLISS you need an explicit fetch operator: a = .b; Forgetting to use the fetch operator is probably the most frequent error made by new BLISS programmers familiar with more conventional languages. DEC used four dialects of BLISS as their primary software development language: BLISS-16, BLISS-32, BLISS-36, and BLISS-64 the numbers indicating the BLISS word size in bits. BLISS-16 targeted the PDP-11 and BLISS-36 the PDP-10. DEC did implementations of BLISS-32 for VAX, MIPS, and x86. BLISS-64 was targeted to both Alpha and Itanium. VSI may have a version of BLISS-64 that generates x86-64 code. -Paul W. [-- Attachment #2: Type: text/html, Size: 4039 bytes --] ^ permalink raw reply [flat|nested] 38+ messages in thread
* [TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? 2024-07-08 22:14 ` Paul Winalski @ 2024-07-09 1:04 ` Aron Insinga 0 siblings, 0 replies; 38+ messages in thread From: Aron Insinga @ 2024-07-09 1:04 UTC (permalink / raw) To: Computer Old Farts Followers; +Cc: tuhs [-- Attachment #1: Type: text/plain, Size: 2797 bytes --] Re: Floating point is unnecessary for operating systems: Yes, that's a big relief for early, small computers without hardware floating point! But floating point is important for runtime libraries which need to implement math functions or reading & writing floating point numbers. IMHO that's work for a system implementation language too, YMMV. Re: BLISS: I found it sad, but the newest versions of the BLISS compilers do not support using it as an expression language. The section bridging pp 978-979 (as published) of Brender's history is: "The expression language characteristic was often highly touted in the early years of BLISS. While there is a certain conceptual elegance that results, in practice this characteristic is not exploited much. The most common applications use the if-then-else expression, for example, in something like the maximum calculation illustrated in Figure 5. Very occasionally there is some analogous use of a case expression. Examples using loops (taking advantage of the value of leave), however, tend not to work well on human factors grounds: the value computed tends to be visually lost in the surrounding control constructs and too far removed from where it will be used; an explicit assignment to a temporary variable often seems to work better. On balance, the expression characteristic of BLISS was not terribly important." Another thing that I always liked (but is still there) is the ease of accessing bit fields with V<FOO_OFFSET, FOO_SIZE> which was descended from BLISS-10's use of the PDP-10 byte pointers. [Add a dot before V to get an rvalue.] (Well, there was this logic simulator which really packed data into bit fields of blocks representing gates, events, etc....) Yes, there is now a BLISS-64 compiler and a MACRO-64 compiler which generate x86_64 code. - Aron Ref: https://www.cs.tufts.edu/~nr/cs257/archive/ronald-brender/bliss.pdf On 7/8/24 18:14, Paul Winalski wrote: > ... > BLISS is also a true, full-blown expression language. Statement > constructs such as if/then/else have a value and can be used in > expressions. In C terminology, everything in BLISS is a lvalue. A > semicolon terminates an expression and throws its value away. > ... > DEC used four dialects of BLISS as their primary software development > language: BLISS-16, BLISS-32, BLISS-36, and BLISS-64 the numbers > indicating the BLISS word size in bits. BLISS-16 targeted the PDP-11 > and BLISS-36 the PDP-10. DEC did implementations of BLISS-32 for VAX, > MIPS, and x86. BLISS-64 was targeted to both Alpha and Itanium. VSI > may have a version of BLISS-64 that generates x86-64 code. > > -Paul W. [-- Attachment #2: Type: text/html, Size: 3894 bytes --] ^ permalink raw reply [flat|nested] 38+ messages in thread
* [TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? 2024-07-08 21:39 ` Aron Insinga 2024-07-08 22:14 ` Paul Winalski @ 2024-07-08 22:17 ` Rik Farrow 2024-07-09 0:08 ` Adam Thornton 1 sibling, 1 reply; 38+ messages in thread From: Rik Farrow @ 2024-07-08 22:17 UTC (permalink / raw) To: Aron Insinga; +Cc: tuhs [-- Attachment #1: Type: text/plain, Size: 3506 bytes --] When I was tech editing "Operating Systems Concepts", tenth edition, around seven years ago, I downloaded the Linux source and searched all .c and .h files for float and double. There aren't any. Linux does not require floating point support, and that's likely true of other operating systems, where performance is key. It also means that Linux can run on RISC V without floating point support (I know the basic CPU doesn't include it). As for microcode in Intel chips, translation of CISC instructions into its internally used RISC is done as lookups into a table that takes up a good portion of the chip die. Rik On Mon, Jul 8, 2024 at 2:40 PM Aron Insinga <aki@insinga.com> wrote: > See https://www.cs.tufts.edu/~nr/cs257/archive/ronald-brender/bliss.pdf > > C allowed writing Unix with a limited amount of assembly code, but CMU's > original BLISS-10 was designed to write an operating system with *no* > outside assembly code. Features like the 'MACHOP' (machine operation) > builtin function made use of the orthogonality of the PDP-10 > instruction format to execute machine-specific instructions in-line. > (cf. the 'asm' extensions in some implementations of C.) The PDP-10's > 36-bit word allowed single-precision floating point numbers to fit in > machine words, so it had infix operators for both integer and > single-precision floating point operations (which I presume were > adequate for an operating system). > > When DEC chose an implementation language, they knew about C but it had > not yet escaped from Bell Labs. PL/I was considered, but there were > questions of whether or not it would be suitable for a minicomputer. On > the other hand, by choosing BLISS, DEC could start with the BLISS-11 > cross compiler running on the PDP-10, which is described in > https://en.wikipedia.org/wiki/The_Design_of_an_Optimizing_Compiler > BLISS-11 > <https://en.wikipedia.org/wiki/The_Design_of_an_Optimizing_CompilerBLISS-11> > and DEC's Common BLISS had changes necessitated by different > word lengths and architectures, including different routine linkages > such as INTERRUPT, access to machine-specific operations such as INSQTI, > and multiple-precision floating point operations using builtin functions > which used the addresses of data instead of the values. > > In order to port VMS to new architectures, DEC/HP/VSI retargeted and > ported the BLISS compilers to new architectures. > > What I find amazing is that they also turned the VAX MACRO assembly > language (in which some of the VMS operating system was written) into a > portable implementation language by 'compiling' the high-level CISC VAX > instructions (and addressing modes) into sequences of RISC > instructions. I believe that this is similar to how modern CPU chips > dynamically translate x86_64 instructions (or whatever) to an internal > RISC format. > > - Aron > > (Disclaimer: I worked at DEC for a long time and VSI for a short time, > but I wasn't responsible for the above work.) > > > On 7/6/24 17:32, Charles H Sauer (he/him) wrote: > > On 7/6/2024 3:56 PM, John R Levine wrote: > >> On Sat, 6 Jul 2024, Clem Cole wrote: > >>> Other systems programming languages followed, BCPL, BLISS, PL/360 > >>> and even > >>> B before C. > >> The original version of BLISS was only for the PDP-10. DEC > >> retargeted it to the PDP-11 and VAX, but I think that was after Unix > >> moved to the Interdata and possibly other machines. > [-- Attachment #2: Type: text/html, Size: 4255 bytes --] ^ permalink raw reply [flat|nested] 38+ messages in thread
* [TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? 2024-07-08 22:17 ` Rik Farrow @ 2024-07-09 0:08 ` Adam Thornton 2024-07-09 2:40 ` Dave Horsfall 0 siblings, 1 reply; 38+ messages in thread From: Adam Thornton @ 2024-07-09 0:08 UTC (permalink / raw) To: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 860 bytes --] Indeed, S/390 Linux ran just fine on machines without IEEE floating point. Which meant that for years I had to jam `use integer` at the top of any Perl I ran, because otherwise any Perl arithmetic at all would go through the software float routines, which was very painful on little machines, such as a P/390. Adam On Mon, Jul 8, 2024 at 3:37 PM Rik Farrow <rik@rikfarrow.com> wrote: > When I was tech editing "Operating Systems Concepts", tenth edition, > around seven years ago, I downloaded the Linux source and searched all .c > and .h files for float and double. There aren't any. Linux does not require > floating point support, and that's likely true of other operating systems, > where performance is key. It also means that Linux can run on RISC > V without floating point support (I know the basic CPU doesn't include it). > > [-- Attachment #2: Type: text/html, Size: 1224 bytes --] ^ permalink raw reply [flat|nested] 38+ messages in thread
* [TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? 2024-07-09 0:08 ` Adam Thornton @ 2024-07-09 2:40 ` Dave Horsfall 2024-07-09 2:43 ` Warner Losh ` (2 more replies) 0 siblings, 3 replies; 38+ messages in thread From: Dave Horsfall @ 2024-07-09 2:40 UTC (permalink / raw) To: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 517 bytes --] On Mon, 8 Jul 2024, Adam Thornton wrote: > Indeed, S/390 Linux ran just fine on machines without IEEE floating > point. Which meant that for years I had to jam `use integer` at the top > of any Perl I ran, because otherwise any Perl arithmetic at all would go > through the software float routines, which was very painful on little > machines, such as a P/390. When it comes down to it, why would a kernel need floating point? Or are you talking about the distribution instead of the OS? -- Dave ^ permalink raw reply [flat|nested] 38+ messages in thread
* [TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? 2024-07-09 2:40 ` Dave Horsfall @ 2024-07-09 2:43 ` Warner Losh 2024-07-09 4:23 ` Adam Thornton 2024-07-09 5:06 ` Aron Insinga 2 siblings, 0 replies; 38+ messages in thread From: Warner Losh @ 2024-07-09 2:43 UTC (permalink / raw) To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 954 bytes --] On Mon, Jul 8, 2024 at 8:41 PM Dave Horsfall <dave@horsfall.org> wrote: > On Mon, 8 Jul 2024, Adam Thornton wrote: > > > Indeed, S/390 Linux ran just fine on machines without IEEE floating > > point. Which meant that for years I had to jam `use integer` at the top > > of any Perl I ran, because otherwise any Perl arithmetic at all would go > > through the software float routines, which was very painful on little > > machines, such as a P/390. > > When it comes down to it, why would a kernel need floating point? Or are > you talking about the distribution instead of the OS? > Not floating point, per se, but there's things like AESNI that use special registers that are akin to floating point (I can't recall if they are shared with the FP registers or not off the top of my head). For doing crypto fast, these are often used. The same the same facilities that FP uses to save/restore them on context switches. Warner [-- Attachment #2: Type: text/html, Size: 1376 bytes --] ^ permalink raw reply [flat|nested] 38+ messages in thread
* [TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? 2024-07-09 2:40 ` Dave Horsfall 2024-07-09 2:43 ` Warner Losh @ 2024-07-09 4:23 ` Adam Thornton 2024-07-09 5:06 ` Aron Insinga 2 siblings, 0 replies; 38+ messages in thread From: Adam Thornton @ 2024-07-09 4:23 UTC (permalink / raw) To: Dave Horsfall, The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 955 bytes --] Generally it shouldn't, and didn't. But Perl assumed you had hardware floating point, because most architectures did--including S/390--but Perl on Linux further assumed IEEE 754 floating point, which was implemented in software on the S/390 (the hardware FP was IBM FP), and, on small and pokey machines, was really quite slow. Adam On Mon, Jul 8, 2024 at 7:41 PM Dave Horsfall <dave@horsfall.org> wrote: > On Mon, 8 Jul 2024, Adam Thornton wrote: > > > Indeed, S/390 Linux ran just fine on machines without IEEE floating > > point. Which meant that for years I had to jam `use integer` at the top > > of any Perl I ran, because otherwise any Perl arithmetic at all would go > > through the software float routines, which was very painful on little > > machines, such as a P/390. > > When it comes down to it, why would a kernel need floating point? Or are > you talking about the distribution instead of the OS? > > -- Dave [-- Attachment #2: Type: text/html, Size: 1333 bytes --] ^ permalink raw reply [flat|nested] 38+ messages in thread
* [TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? 2024-07-09 2:40 ` Dave Horsfall 2024-07-09 2:43 ` Warner Losh 2024-07-09 4:23 ` Adam Thornton @ 2024-07-09 5:06 ` Aron Insinga 2 siblings, 0 replies; 38+ messages in thread From: Aron Insinga @ 2024-07-09 5:06 UTC (permalink / raw) To: tuhs Sorry if I'm mistaken, but I thought that we were talking about system implementation languages. The languages discussed have their roots back in the early days of using an HLL instead of assembly language for this. One could certainly write the kernel in a subset [or a superset of a subset] of the language that is used for everything else and I believe it has been done before. (Is ESPOL a superset of Burroughs ALGOL?) One could write the kernel in C and everything else in a *very* different language. I only mentioned single-precision floating point as an example of BLISS-10 being operator-typed as opposed to data-typed, and then added that a little floating point is useful for writing run-time libraries. (For another example, a debugger might want to use floating point to allow examining or depositing such a value.) I'd consider PDP-11 UNIX to be an operating system, and it included some libraries and a debugger. I can see that others might consider PDP-11 UNIX to be a 'distribution'. Sorry if I wandered too far afield. - Aron On 7/8/24 22:40, Dave Horsfall wrote: > On Mon, 8 Jul 2024, Adam Thornton wrote: > >> Indeed, S/390 Linux ran just fine on machines without IEEE floating >> point. Which meant that for years I had to jam `use integer` at the top >> of any Perl I ran, because otherwise any Perl arithmetic at all would go >> through the software float routines, which was very painful on little >> machines, such as a P/390. > When it comes down to it, why would a kernel need floating point? Or are > you talking about the distribution instead of the OS? > > -- Dave ^ permalink raw reply [flat|nested] 38+ messages in thread
* [TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? 2024-07-05 23:17 ` John Levine 2024-07-06 12:52 ` sjenkin @ 2024-07-07 5:33 ` arnold 1 sibling, 0 replies; 38+ messages in thread From: arnold @ 2024-07-07 5:33 UTC (permalink / raw) To: tuhs, johnl "John Levine" <johnl@taugh.com> wrote: > These days we write code and compile it for x64 or ARM or RISC-V and > for the most part, it just works because the data formats and addressing > are all the same. I have to agree with this. My experience is that for most[1] user level code, the architecture simply doesn't matter. I started working on gawk on vaxen, moved to MC68010, then to Sparc, then to 32-bit x86, then to 64-bit x86, with a side segue to 32-bit PPC. Other people compile it on everything else: ARM, S/390, Alpha, Itanium, RISC-V, you name it. OS differences matter more than architecutre differences. This list's membership is heavily weighted with compiler writers and OS porters, which is fine, but that's a very small percentage of the number of people out in the world writing code. Those folks (including me in my $DAYJOB) all work in C++, Java, Python, Rust, and Go, and the architecture simply doesn't matter to them. (C# is nominally portable as well, but hasn't caught on outside of Windows like the others.) I *do* think that studying a nice architecture, like the PDP-11, is important for people learning software development. In college I took data structures and algorithms together with PDP-11 assembler, and it was only when I saw how recursion worked in assembler with the stack that I finally understood it. It was a real epiphany. My two cents, Arnold [1] Architecture does come into play if you're writing _binary_ data, which is why RPC/XDR were invented for NFS and why Google has it's RPC language and libraries. ^ permalink raw reply [flat|nested] 38+ messages in thread
* [TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? 2024-07-05 21:38 ` [TUHS] Re: mental architecture models, " John Levine 2024-07-05 21:49 ` Larry McVoy @ 2024-07-05 22:10 ` Dan Cross 1 sibling, 0 replies; 38+ messages in thread From: Dan Cross @ 2024-07-05 22:10 UTC (permalink / raw) To: John Levine; +Cc: tuhs, peter.martin.yardley On Fri, Jul 5, 2024 at 5:47 PM John Levine <johnl@taugh.com> wrote: > It appears that Peter Yardley <peter.martin.yardley@gmail.com> said: > >The DG Nova had a pretty nice architecture. 2 accumulators, 2 index registers, 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 simplified 386 > leaving out the dumb or useless stuff. I ignore the segments which are useless > other than for 286 emulation, and some of the strange instructions like decimal > 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. ^ permalink raw reply [flat|nested] 38+ messages in thread
end of thread, other threads:[~2024-07-10 21:18 UTC | newest] Thread overview: 38+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2024-07-10 2:20 [TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? Douglas McIlroy 2024-07-10 2:36 ` [TUHS] Re: machine code translation,as mental architecture models John Levine 2024-07-10 4:59 ` Lars Brinkhoff 2024-07-10 12:53 ` John R Levine 2024-07-10 11:56 ` Paul Winalski 2024-07-10 14:12 ` Marc Donner 2024-07-10 16:58 ` segaloco via TUHS 2024-07-10 17:15 ` Dan Cross 2024-07-10 19:23 ` Marc Donner 2024-07-10 19:38 ` Clem Cole 2024-07-10 20:04 ` Marc Donner 2024-07-10 21:18 ` Adam Thornton -- strict thread matches above, loose matches on Subject: below -- 2024-07-07 13:57 [TUHS] Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? Noel Chiappa 2024-07-07 16:43 ` John Levine 2024-07-05 7:36 [TUHS] " Dave Horsfall 2024-07-05 10:18 ` Peter Yardley 2024-07-05 21:38 ` [TUHS] Re: mental architecture models, " John Levine 2024-07-05 21:49 ` Larry McVoy 2024-07-05 22:08 ` Charles H Sauer (he/him) 2024-07-05 22:24 ` Larry McVoy 2024-07-05 23:17 ` John Levine 2024-07-06 12:52 ` sjenkin 2024-07-06 14:02 ` John R Levine 2024-07-06 15:58 ` Clem Cole 2024-07-06 20:56 ` John R Levine 2024-07-06 21:32 ` Charles H Sauer (he/him) 2024-07-06 23:46 ` Peter Yardley 2024-07-07 17:43 ` James Frew 2024-07-07 1:39 ` John Levine 2024-07-08 21:39 ` Aron Insinga 2024-07-08 22:14 ` Paul Winalski 2024-07-09 1:04 ` Aron Insinga 2024-07-08 22:17 ` Rik Farrow 2024-07-09 0:08 ` Adam Thornton 2024-07-09 2:40 ` Dave Horsfall 2024-07-09 2:43 ` Warner Losh 2024-07-09 4:23 ` Adam Thornton 2024-07-09 5:06 ` Aron Insinga 2024-07-07 5:33 ` arnold 2024-07-05 22:10 ` Dan Cross
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).