4 ms·

Some generic registers (r1, r2...) would be easy to implement and allocate on translation step.

by bvrmn 5y ago

akkartik 5y ago
Perhaps I should rename the registers to generic r1-r6. The trouble with automatically allocating registers is that you sometimes need to spill. And that means instructions need to work with either registers or memory. That feels like a very different kind of language, closer to C. You lose the largely 1:1 mapping with machine code that I was aiming for. Code generation gets more complex -- and my whole goal was to implement it in unsafe machine code (the SubX notation) and avoid metacircularity. Instead Mu makes you allocate registers -- but verifies your allocation so you have a reasonably decent experience.
- nyanpasu64 5y ago
  I want a software stack an application developer (me) can fully understand. I don't want it to depend on a heavy opaque runtime obscuring control flow, requiring both native and VM-level debuggers, and resulting in unpredictable performance (Java/C#/JS). I don't want it to rely on GPU APIs, which expose hardware and driver implementation details (making software behave differently on different computers, and even malfunction on some hardware or with the wrong drivers installed), and lose support on newer hardware (you can't play Touhou 6 without a DX8 emulator). I don't want deep dependencies on heavyweight OSes and daemons and IPC (D-Bus desktop portals and drag-and-drop keep malfunctioning, playing Touhou or running Japanese software requires juggling Windows app locale emulators). I don't want heavyweight apps built on thick GUI frameworks or sprawling OS APIs, resulting in apps which can't run on OSes 10 years in the future (since they're missing GTK2 or Qt4 or WPF, or have an incompatible libstdc++), and also can't run on bare-metal emulators unless you install the full OS. Maybe Mu is it. I don't know. My concern is that low level code with manual register allocations is too unproductive, and even C (not to mention C++ or Rust) is complex enough that I don't know what the compiler is doing at -O2, with or without TBAA, with or without restrict, etc. Is it even possible to get a small understandable stack, and full Unicode support, OS-like text editing and keyboard shortcuts, system fonts, system font rendering and fontconfig, tab navigation to jump between widgets, maybe even OS file dialogs and accessibility? Lagrange is a Gemini client which depends on not much more than SDL (good), but doesn't use OS fonts rendering and text editing (bad).
  - akkartik 5y ago
    It's hard. Building Mu has given me more of a flavor for just how hard it is. Some limitations of Mu: * It still requires firmware. There's a whole lot of C down there. How deep do you want to go? * No mouse. This is just my own ignorance. I can't get the damn IRQs and interrupts figured out. * Doesn't work yet on real hardware. I live in Qemu. Debugging that is a whole new set of skills I need to learn. * No networking, almost no persistent storage. Mu has a very simple and slow driver for ATA disks, but that probably won't suffice on most real-world machine configurations. There's 0 network drivers right now. I probably need a dozen to get any sort of coverage. The stuff you mentioned around graphics and OS file dialogs, that feels easier once you're willing to put up with constraints like Mu's 1024x768 and so on. But yeah, there's major challenges on this road. Partly due to these challenges, I've actually started to hedge my bets and make some compromises. My new project is https://github.com/akkartik/teliva https://github.com/akkartik/teliva which doesn't try to eliminate C, just minimize it. Linux kernel, libc, Lua (12k lines of C), some libraries for https. A gemini client is actually on my todo list there. I think I have everything I need to build it.

Some generic registers (r1, r2...) would be easy to implement and allocate on translation step.

by bvrmn 5y ago

Some generic registers (r1, r2...) would be easy to implement and allocate on translation step.

Perhaps I should rename the registers to generic r1-r6. The trouble with automatically allocating registers is that you sometimes need to spill. And that means instructions need to work with either registers or memory. That feels like a very different kind of language, closer to C. You lose the largely 1:1 mapping with machine code that I was aiming for. Code generation gets more complex -- and my whole goal was to implement it in unsafe machine code (the SubX notation) and avoid metacircularity. Instead Mu makes you allocate registers -- but verifies your allocation so you have a reasonably decent experience.

nyanpasu64 5y ago
I want a software stack an application developer (me) can fully understand. I don't want it to depend on a heavy opaque runtime obscuring control flow, requiring both native and VM-level debuggers, and resulting in unpredictable performance (Java/C#/JS). I don't want it to rely on GPU APIs, which expose hardware and driver implementation details (making software behave differently on different computers, and even malfunction on some hardware or with the wrong drivers installed), and lose support on newer hardware (you can't play Touhou 6 without a DX8 emulator). I don't want deep dependencies on heavyweight OSes and daemons and IPC (D-Bus desktop portals and drag-and-drop keep malfunctioning, playing Touhou or running Japanese software requires juggling Windows app locale emulators). I don't want heavyweight apps built on thick GUI frameworks or sprawling OS APIs, resulting in apps which can't run on OSes 10 years in the future (since they're missing GTK2 or Qt4 or WPF, or have an incompatible libstdc++), and also can't run on bare-metal emulators unless you install the full OS. Maybe Mu is it. I don't know. My concern is that low level code with manual register allocations is too unproductive, and even C (not to mention C++ or Rust) is complex enough that I don't know what the compiler is doing at -O2, with or without TBAA, with or without restrict, etc. Is it even possible to get a small understandable stack, and full Unicode support, OS-like text editing and keyboard shortcuts, system fonts, system font rendering and fontconfig, tab navigation to jump between widgets, maybe even OS file dialogs and accessibility? Lagrange is a Gemini client which depends on not much more than SDL (good), but doesn't use OS fonts rendering and text editing (bad).
- akkartik 5y ago
  It's hard. Building Mu has given me more of a flavor for just how hard it is. Some limitations of Mu: * It still requires firmware. There's a whole lot of C down there. How deep do you want to go? * No mouse. This is just my own ignorance. I can't get the damn IRQs and interrupts figured out. * Doesn't work yet on real hardware. I live in Qemu. Debugging that is a whole new set of skills I need to learn. * No networking, almost no persistent storage. Mu has a very simple and slow driver for ATA disks, but that probably won't suffice on most real-world machine configurations. There's 0 network drivers right now. I probably need a dozen to get any sort of coverage. The stuff you mentioned around graphics and OS file dialogs, that feels easier once you're willing to put up with constraints like Mu's 1024x768 and so on. But yeah, there's major challenges on this road. Partly due to these challenges, I've actually started to hedge my bets and make some compromises. My new project is https://github.com/akkartik/teliva https://github.com/akkartik/teliva which doesn't try to eliminate C, just minimize it. Linux kernel, libc, Lua (12k lines of C), some libraries for https. A gemini client is actually on my todo list there. I think I have everything I need to build it.