4 ms·

Okay let's take your argument to the logical conclusion. If elegance is all that matters, let's write a kernel in Standard ML and run it on a virtual Turing mac

Okay let's take your argument to the logical conclusion. If elegance is all that matters, let's write a kernel in Standard ML and run it on a virtual Turing machine. But even the v6 learning Unix targets 32-bit x86, which is NOT elegant in any way (love that bootstrap assembly that switches from 16-bit 8086 mode to 32-bit 386 mode, but it's not elegant). What's missing from your theory is the ability to tinker. Nobody is going to try to improve upon an esoteric kernel that sacrifices all usability for theoretical purity. But a Rust kernel for x86-64 (which is not dying, BTW) is something students can run on real hardware, and that's cool and engaging in a way that is hard to put a value on.

kelas 3y ago
> elegance matters absolutely, but no need for strong violence. ANSI C and RISC-V are doing fine. > x86-64 which is not dying true. technically speaking, it is long gone - any Intel CPU since about Pentium Pro is actually a well-hidden RISC, because it is more efficient. Sure that requires a pretty beefy CISC decoder in front, but the sheer power of having a virtual 8086 mode next to amd64 must totally justify all that extra TDP. > [x86 is] something students can run on real hardware, and that's cool and engaging also true, but nothing compares to booting the real xv6 on a real RISC-V system for the first time, which is easy and fun (and cheap, if we’re talking value). i recommend.
- nine_k 3y ago
  I'd say that C is not elegant as a language at all. It's a good (as in "working") solution of many problems that other system languages had in late 1960s, and I'd hazard to say that the highly economical ways that were used to solve them are elegant. E.g. using #include is terrible from many angles, but is elegant as a highly minimalist way to solve the modularity problem (reduce the problem to one already solved).
  - kelas 3y ago
    > C is not elegant okay, tastes differ, but it remains what it was in one of its original definitions: a sufficiently portable assembly. > #include hell / modularity okay, so rust has cargo, so we’re all better now, right? but what if someone will dare to argue that C has a whole bunch of cargos, some less terrible than others, if we reframe the problem like so: $ [rpm|dpkg|dnf|yum|apt|brew|pkg-add] install libcurl libcurl-dev(el) (this makes me wonder how any software even works anymore in absence of universal cargo cult, but hey)
    - viraptor 3y ago
      Different things entirely. System-specific packages have no concept of C building or linking. Things work because of some agreement about paths + pkgconfig + others. This is very far from the idea of a dependency manager like cargo which is very much aware of project-specific and language features.
      - kelas 3y ago
        > Different things entirely yes, they are. > System-specific packages have no concept of C building or linking. every day i learn something new, but this time around I’m gonna go ahead a tell you that you are very mistaken. > Things work because of some agreement about paths + pkgconfig + others. True. By convention, we call it “convention”, or “standard” for short, e.g. POSIX or ISO C. Call us back once you have something like that in rustland. > This is very far from the idea of a dependency manager like cargo which is very much aware of project-specific and language features. All good and sound, and makes total sense for userland software. But what is being discussed here is an operating system and core userland. If you can imagine that to be your “project”, such as linux or OpenBSD, maybe my tongue-in-cheek comparison of a system-wide dependency manager suddenly looks less dissimilar to cargo. needless to say, things like Linux and OpenBSD will stay written in C for a little while longer. In case of BSD specifically, you can go as crazy as to bump and rebuild your entire system from source in place, kernel and userland. BSD is one pretty old cargo cult in that sense, and pretty cool, i might add. > language features right… rust 2018 edition is not really rust as of 2023, or is it? This where those pesky standards come very handy.
- phendrenad2 3y ago
  > nothing compares to booting the real xv6 on a real RISC-V system for the first time Why is that? > any Intel CPU since about Pentium Pro is actually a well-hidden RISC Well if it's well-hidden, it doesn't matter to the person learning to write an OS. ;)
  - kelas 3y ago
    > Why is that? you said it best - the “tinkering” part is a small thing that makes all the difference when one is first led up to a computer. > if it's hidden, it doesn't matter right… and if you ignore it, maybe it’ll go away. like Intel Management Engine, perhaps. Which OS does it run, if you know? :)
    - phendrenad2 3y ago
      > the “tinkering” part is a small thing that makes all the difference when one is first led up to a computer True, but when making an OS, assembly code is an incredibly small part of it. You basically need to run a few instructions to put the processor in the right mode, and you need ONE line of assembly code (often inline C) to allow usermode to call supervisor mode. When choosing an architecture for a learning OS, I think other factors would dominate, like availability of hardware (many people have a PC already, saving them $100-$200 on RISC-V hardware). > right… and if you ignore it, maybe it’ll go away. like Intel Management Engine, perhaps. Which OS does it run, if you know? :) I'm not interested in gatekeeping tech to only those who care about personal privacy, so I consider this line of thought completely irrelevant to the discussion. But that's just me...
      - kelas 3y ago
        > True, but when making an OS, assembly code is an incredibly small part of it. A few comments up this thread i briefly mentioned r/xv6 entry.S, so here’s what i meant: rv64: https://github.com/mit-pdos/xv6-riscv/blob/riscv/kernel/entry.S https://github.com/mit-pdos/xv6-riscv/blob/riscv/kernel/entr... amd64: https://github.com/dancrossnyc/rxv64/blob/main/kernel/src/entry.S https://github.com/dancrossnyc/rxv64/blob/main/kernel/src/en... > You basically need to run a few instructions to put the processor in the right mode, and you need ONE line of assembly code (often inline C) to allow usermode to call supervisor mode. Right… Please see above. Also, in riscv land we have machine, supervisor and user modes, with hypervisor mode being in the works. > When choosing an architecture for a learning OS, I think other factors would dominate, like availability of hardware (many people have a PC already, saving them $100-$200 on RISC-V hardware). yet, MIT PDOS thinks Fabrice Bellard’s ubiquitous qemu is a better, cheaper and more forgiving starting point, although i personally prefer to spend a few bucks on something as absurdly cheap and cool as kendryte k210/k510 SoC and enjoy the real deal. > Intel hate keeping tech is irrelevant [I don’t care] Yes, it’s just you. Also, it runs Minix.
- astrange 3y ago
  > true. technically speaking, it is long gone - any Intel CPU since about Pentium Pro is actually a well-hidden RISC, because it is more efficient. Sure that requires a pretty beefy CISC decoder in front, but the sheer power of having a virtual 8086 mode next to amd64 must totally justify all that extra TDP. It is not, the µcode on an x86 is still often "CISCy" and rightfully so - a complicated instruction like "lea" is still perfectly suited to hardware.
  - adgjlsfhk1 3y ago
    this is true, but modern RISC cpus are also pretty CISCy now. The risc-V vector extension has an vfwmacc.vf which is a broadcasted vectorized widening fused multiply accumulate instruction.

kelas 3y ago

> elegance matters absolutely, but no need for strong violence. ANSI C and RISC-V are doing fine. > x86-64 which is not dying true. technically speaking, it is long gone - any Intel CPU since about Pentium Pro is actually a well-hidden RISC, because it is more efficient. Sure that requires a pretty beefy CISC decoder in front, but the sheer power of having a virtual 8086 mode next to amd64 must totally justify all that extra TDP. > [x86 is] something students can run on real hardware, and that's cool and engaging also true, but nothing compares to booting the real xv6 on a real RISC-V system for the first time, which is easy and fun (and cheap, if we’re talking value). i recommend.

nine_k 3y ago
I'd say that C is not elegant as a language at all. It's a good (as in "working") solution of many problems that other system languages had in late 1960s, and I'd hazard to say that the highly economical ways that were used to solve them are elegant. E.g. using #include is terrible from many angles, but is elegant as a highly minimalist way to solve the modularity problem (reduce the problem to one already solved).
- kelas 3y ago
  > C is not elegant okay, tastes differ, but it remains what it was in one of its original definitions: a sufficiently portable assembly. > #include hell / modularity okay, so rust has cargo, so we’re all better now, right? but what if someone will dare to argue that C has a whole bunch of cargos, some less terrible than others, if we reframe the problem like so: $ [rpm|dpkg|dnf|yum|apt|brew|pkg-add] install libcurl libcurl-dev(el) (this makes me wonder how any software even works anymore in absence of universal cargo cult, but hey)
  - viraptor 3y ago
    Different things entirely. System-specific packages have no concept of C building or linking. Things work because of some agreement about paths + pkgconfig + others. This is very far from the idea of a dependency manager like cargo which is very much aware of project-specific and language features.
    - kelas 3y ago
      > Different things entirely yes, they are. > System-specific packages have no concept of C building or linking. every day i learn something new, but this time around I’m gonna go ahead a tell you that you are very mistaken. > Things work because of some agreement about paths + pkgconfig + others. True. By convention, we call it “convention”, or “standard” for short, e.g. POSIX or ISO C. Call us back once you have something like that in rustland. > This is very far from the idea of a dependency manager like cargo which is very much aware of project-specific and language features. All good and sound, and makes total sense for userland software. But what is being discussed here is an operating system and core userland. If you can imagine that to be your “project”, such as linux or OpenBSD, maybe my tongue-in-cheek comparison of a system-wide dependency manager suddenly looks less dissimilar to cargo. needless to say, things like Linux and OpenBSD will stay written in C for a little while longer. In case of BSD specifically, you can go as crazy as to bump and rebuild your entire system from source in place, kernel and userland. BSD is one pretty old cargo cult in that sense, and pretty cool, i might add. > language features right… rust 2018 edition is not really rust as of 2023, or is it? This where those pesky standards come very handy.
phendrenad2 3y ago
> nothing compares to booting the real xv6 on a real RISC-V system for the first time Why is that? > any Intel CPU since about Pentium Pro is actually a well-hidden RISC Well if it's well-hidden, it doesn't matter to the person learning to write an OS. ;)
- kelas 3y ago
  > Why is that? you said it best - the “tinkering” part is a small thing that makes all the difference when one is first led up to a computer. > if it's hidden, it doesn't matter right… and if you ignore it, maybe it’ll go away. like Intel Management Engine, perhaps. Which OS does it run, if you know? :)
  - phendrenad2 3y ago
    > the “tinkering” part is a small thing that makes all the difference when one is first led up to a computer True, but when making an OS, assembly code is an incredibly small part of it. You basically need to run a few instructions to put the processor in the right mode, and you need ONE line of assembly code (often inline C) to allow usermode to call supervisor mode. When choosing an architecture for a learning OS, I think other factors would dominate, like availability of hardware (many people have a PC already, saving them $100-$200 on RISC-V hardware). > right… and if you ignore it, maybe it’ll go away. like Intel Management Engine, perhaps. Which OS does it run, if you know? :) I'm not interested in gatekeeping tech to only those who care about personal privacy, so I consider this line of thought completely irrelevant to the discussion. But that's just me...
    - kelas 3y ago
      > True, but when making an OS, assembly code is an incredibly small part of it. A few comments up this thread i briefly mentioned r/xv6 entry.S, so here’s what i meant: rv64: https://github.com/mit-pdos/xv6-riscv/blob/riscv/kernel/entry.S https://github.com/mit-pdos/xv6-riscv/blob/riscv/kernel/entr... amd64: https://github.com/dancrossnyc/rxv64/blob/main/kernel/src/entry.S https://github.com/dancrossnyc/rxv64/blob/main/kernel/src/en... > You basically need to run a few instructions to put the processor in the right mode, and you need ONE line of assembly code (often inline C) to allow usermode to call supervisor mode. Right… Please see above. Also, in riscv land we have machine, supervisor and user modes, with hypervisor mode being in the works. > When choosing an architecture for a learning OS, I think other factors would dominate, like availability of hardware (many people have a PC already, saving them $100-$200 on RISC-V hardware). yet, MIT PDOS thinks Fabrice Bellard’s ubiquitous qemu is a better, cheaper and more forgiving starting point, although i personally prefer to spend a few bucks on something as absurdly cheap and cool as kendryte k210/k510 SoC and enjoy the real deal. > Intel hate keeping tech is irrelevant [I don’t care] Yes, it’s just you. Also, it runs Minix.
astrange 3y ago
> true. technically speaking, it is long gone - any Intel CPU since about Pentium Pro is actually a well-hidden RISC, because it is more efficient. Sure that requires a pretty beefy CISC decoder in front, but the sheer power of having a virtual 8086 mode next to amd64 must totally justify all that extra TDP. It is not, the µcode on an x86 is still often "CISCy" and rightfully so - a complicated instruction like "lea" is still perfectly suited to hardware.
- adgjlsfhk1 3y ago
  this is true, but modern RISC cpus are also pretty CISCy now. The risc-V vector extension has an vfwmacc.vf which is a broadcasted vectorized widening fused multiply accumulate instruction.