[HN Gopher] Mu: A Human-Scale Computer
___________________________________________________________________
Mu: A Human-Scale Computer
Author : finite_jest
Score : 104 points
Date : 2021-12-08 15:08 UTC (7 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| bvrmn wrote:
| Some generic registers (r1, r2...) would be easy to implement and
| allocate on translation step.
| akkartik wrote:
| 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 wrote:
| 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 wrote:
| 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 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.
| monocasa wrote:
| That's real neat. It sort of reminds me of the high level goals
| of TempleOS. Pining for the days of earlyish microcomputers where
| you truly owned and could understand the software stack sitting
| in front of you on your desk.
| spicybright wrote:
| I feel like the idea could be covered by commodore 64. Even
| adding basic networking in any way opens up an absolutely massive
| amount of un-abstracted concepts and processes to keep in one
| head.
|
| That said I flippin love people re-inventing a computer into
| something not derived from a VAX timeshare machine from the 70s.
| stephbu wrote:
| Yes, it reminded me a lot of when I first started in computing.
| Today we are so abstracted from the horsepower that produces
| our experiences, to the extent that most Software Engineers
| don't actually know how their code works. Not saying that is a
| bad thing, not saying that it is mandatory, it's just an art
| and science that is eroding rapidly.
|
| I started as an 8yr old, reading computer magazines, and
| initially coding in BASIC in 1K of RAM. I into Z80 Assembler
| and Machine Code at 10yrs - learning primitives like NMI's,
| Display DMA and Sound IO by hand with pencil, paper, and lots
| of reboot-causing mistakes. It was bruteforce, but still very
| influential in my understanding of a then-modern computer
| system.
|
| Z80 was a simple-enough chip instruction set that I still
| remember most the mnemonics today, and many of the
| architectural principals are still valid even after so much
| time.
| fwip wrote:
| > most Software Engineers don't actually know how their code
| works.
|
| This is only true when you decide that the specific level of
| abstraction that you learned is the important one.
|
| Sure, you knew the machine code. Did you know how the
| instruction set was implemented on the chip? The decode logic
| at a transistor logic to set the right signals to route your
| register to the ALU? Did you care about the equations that
| governed the flow of electrons through silicon?
|
| Or did you trust the machine code to be your level of
| abstraction that Worked?
| throw10920 wrote:
| This is a little bit reductionistic.
|
| You can slightly the alter the claim to "most software
| engineers don't actually know how their code works at a
| level that's relevant for them to make good software" and
| it becomes solidly true.
|
| Most (web) software engineers don't know anything about
| assembly, CPU cache, virtual memory, or pipelining, and
| application of knowledge of those things would change web
| applications from their current _abysmal_ levels of
| performance to something acceptable.
|
| Very, _very_ rarely is knowledge of the microarchitecture,
| microcode, transistors, or physics necessary to make modern
| software reasonably correct and performant.
| [deleted]
| AnIdiotOnTheNet wrote:
| The world isn't as black and white as "all abstractions
| bad" or "all abstractions good" though. There are levels of
| abstraction that are objectively useful and levels of
| abstraction that are so separated from reality that a 3Ghz
| multicore computer is somehow incapable of keeping up with
| a human's typed input.
| klelatti wrote:
| Colour Maximite seems like a practical piece of modern hardware
| that takes a similar approach to the classic 80s home
| computers.
|
| https://geoffg.net/maximite.html
| selfhoster11 wrote:
| The main issue with older machines is that the resolution isn't
| great for writing. I like reasonable letter shapes, and you
| kind of need 640x480 for that at least.
| akkartik wrote:
| Yeah, this was definitely a concern for me when building Mu.
| What do you think of the one font Mu has? It's
| http://unifoundry.com/unifont. I was trying to get to some
| minimum level of legibility while otherwise optimizing for
| simplicity. 1024x768 seemed like a reasonable compromise,
| though adjacent resolutions are also fine.
| carapace wrote:
| Unifont seems very useful. Not pretty but definitely
| legible.
|
| - - - -
|
| FWIW, I ran across this the other day: "4x4 ASCII Font"
|
| > Small fonts have always been fascinating to me, so I
| decided to make the smallest font possible, which turned
| out to be 4x4 pixels per character. The font covers the
| entire range of visible ASCII characters, and most are
| immediately recognizable.
|
| https://simplifier.neocities.org/4x4.html
|
| - - - -
|
| For display from small machines I keep going back and forth
| between simple memory-mapped raster screens vs. emitting a
| stream of, say, SVG to an external "display processor"
| (following the "Wheel of Reincarnation": "On the Design of
| Display Processors"
| http://cva.stanford.edu/classes/cs99s/papers/myer-
| sutherland... )
| ExtraE wrote:
| In principle wouldn't 3x3 be the theoretical limit?
| That's 9 bits/char which is enough for twice ASCII.
| selfhoster11 wrote:
| I'm actually fond of the Unifont letter shapes. It might
| be just that I'm used to this font from using Linux, but
| I actually like it.
| andai wrote:
| I like that font: I once saw it in a screenshot and spent a
| good amount of time trying to figure out which font it was.
| magios wrote:
| I actually use a slightly modified unifont exclusively on a
| linux system, deleted all other fonts, disabled browser
| font downloading, and use firefox to get proper rendering.
| If you use a tiling wm, without borders or spaces between
| windows, then three windows of 80 columns of 8x16 font
| works.
| magios wrote:
| sorry for the late reply, also forgot to mention that I
| use a fontconfig file, .xresources, other config files
| for i3 (the tiling wm), termimal (xst) and vim that
| specify the unifont font specifically.
|
| here are a few images showing the setup and sites using
| unifont. https://imgur.com/a/5gAZau3
| akkartik wrote:
| Wow!
| spicybright wrote:
| I've never heard of deleting all fonts before, but I
| supposed that would work well for what you're going for!
|
| Wish general computing was more customizable like that...
| aethertron wrote:
| I would love to see a screenshot!
| Shared404 wrote:
| Seconding this!
| yorwba wrote:
| Note the limitations section:
|
| > Unifont Limitations
|
| > Unifont only stores one glyph per printable Unicode code
| point. This means that complex scripts with special forms
| for letter combinations including consonant combinations
| and floating vowel marks such as with Indic scripts
| (Devanagari, Bengali, Tamil, etc.) or letters that change
| shape depending upon their position in a word (Indic and
| Arabic scripts) will not render well in Unifont. In those
| cases, Unifont is only suitable as a font of last resort.
| Users wishing to properly render such complex scripts
| should use full OpenType fonts that faithfully display such
| alternate forms.
|
| So if your intention when choosing unifont was to support
| all of Unicode, it would be good to make it not too
| difficult to add more fonts.
| akkartik wrote:
| I definitely prioritize supporting all languages. (I
| don't care about flags and emoji and crap like that.)
| However I don't know enough yet. The current list of
| supported languages is enumerated at
| http://akkartik.github.io/mu/html/103glyph.subx.html#L98
|
| It's not just a matter of supporting more fonts. I need
| to support smarter fonts with ligatures and more. I think
| we could preserve the constraint of a single font and
| just make it smarter. But it'll take me some time to
| learn enough to do that.
| yorwba wrote:
| Yeah, ligatures are required for many languages.
|
| E.g. you list Myanmar, where it's possible to construct
| something like ng[?]ngngngng[?]eeeeeeeeaaaaaaaaaaaaaaaa,
| which has "nga" ng, "asat" [?], "virama" combined to put
| ng[?] on the following consonant, which in this case is
| four "nga" ng separated by three "virama" to form a
| cluster ngngngng (Noto Sans Myanmar apparently supports
| stacking up to height 3, the fourth "nga" ng awkwardly
| overlaps), then there's a "medial ra" [?] which puts a
| box around the preceding consonant without overlapping,
| then 8 copies of "e" e which should be rendered _to the
| left_ of the consonant it follows and then 8 copies of
| "aa" aa which attach to the right.
|
| You're not going to encounter something crazy like this
| in the wild (in Burmese, there's at most one of each
| vowel sign on a consonant, and I don't think stacking
| four consonants is ever necessary) but it serves as a
| demonstration of the edge cases that a font needs to
| handle. The lookup tables end up getting quite large,
| which I think is one of the reasons Noto isn't usually
| used as one file with all scripts.
| akkartik wrote:
| Yes, the vowel diacritics are definitely an issue. I'm
| familiar with Hindi and Tamil. Hindi's _matras_ are
| pretty regular, and Unifont is designed so you can just
| type a single diacritic in the same spot as a consonant
| and have the thing look right (albeit terrible).
|
| Tamil, however, doesn't have this property. Does Myanmar?
|
| At the moment a single diacritic is the extent of my
| ambition.
| yorwba wrote:
| There are vowel signs that attach to the left, right,
| top, bottom or wrap around the preceding consonant. You
| could maybe emulate it by manually placing characters
| into a grid, but that would be very much not Unicode.
|
| Anyways, if you could get Tamil to work with a generic
| approach, I guess most of the edge cases for Myanmar
| would be covered by that as well. (Edit: seems like Tamil
| only has at most one diacritic, so it would have to be
| more general for Myanmar still.)
| akkartik wrote:
| Yeah, that does sound like Tamil. Ligatures become
| necessary even for combining just 2 code points.
| selfhoster11 wrote:
| Unifont is perfectly fine. Linux uses it in various places,
| so I don't mind it. In fact, I rather like its letter
| shapes.
|
| 1024x768 is more than reasonable. Almost luxurious in a
| "small"/"personal" computing context, but in a good way. I
| still use computers with that resolution sometimes.
| finite_jest wrote:
| :-) 640x480, also known as God's preferred resolution: https:
| //en.wikipedia.org/w/index.php?title=TempleOS&oldid=10...
| mdp2021 wrote:
| You can start with the C64 definition as a base and rewrite
| it expanding it (e.g. instead of 40x25 cells, 320x200 pixels
| on 1000 bytes pointing to 8x8 sized chars, you could provide
| a similarly working mode but 120x64 cells, 1920x1024 pixels
| on 7680 bytes pointing to 16x16 sized multicolor chars). Have
| four SID instead of one, 64 sprites, use a large number of
| switchable 64Kb regions as modules (and/or a huge disk in
| physical RAM) etc. You can just take inspiration from the
| original and see how the traditional ideas could be adapted
| for current hardware.
| thingification wrote:
| From my skim of the README this sounds like (in part) a system
| for generating unikernels, is that correct?
|
| Would anybody like to compare/contrast this with
| https://mirage.io/?
| akkartik wrote:
| I was certainly aware of unikernels (on a pretty superficial
| level) when I started Mu. A shared goal is minimizing attack
| surface. However, Mu also has a second goal: minimizing the
| build time supply chain and making it more auditable. There Mu
| has more in common with http://bootstrappable.org which is
| building https://www.gnu.org/software/mes. In service of this
| goal I've ended up leaving all C behind.
|
| As I understand it, unikernels want to let you bring your own
| application sources, and try to compile it to their substrate.
| Mu requires you to build your application _for_ it. There 's no
| compatibility with anything beyond the x86 instruction set (and
| Unicode).
| dang wrote:
| One past thread:
|
| _Mu: A Human Scale Computer_ -
| https://news.ycombinator.com/item?id=21242190 - Oct 2019 (12
| comments)
| Stampo00 wrote:
| See also uxn, uxntal, and varvara, which I feel have similar
| design goals. I love this movement. I miss _personal_ computing.
|
| https://wiki.xxiivv.com/site/uxn.html
|
| https://wiki.xxiivv.com/site/uxntal.html
|
| https://wiki.xxiivv.com/site/varvara.html
| VikingCoder wrote:
| Has anyone gotten DCPU-16 [1] to run directly on hardware?
|
| [1]: https://en.wikipedia.org/wiki/0x10c
| marcodiego wrote:
| Suppose someone plans to create a multitasking OS for a z80 based
| computer lacking memory protection. With the goal of saving
| memory and to guarantee memory isolation between processes, it is
| decided that the OS would actually be a byte-code interpreter
| capable of running multiple programs at the same time.
|
| So, a byte-code must be chosen to the project. Brainfuck is
| considered at first: it is extremely simple to implement but is
| rejected because has very little code density. Then, Chip-8 is
| considered: it is simple to implement and there are many programs
| and tools already available. Then p-code is looked at, but it is
| nowhere near as popular as Chip-8 and apparently not as simple to
| implement. Other vm's are considered but are rejected because
| they are not simple or not very popular: SWEET16, ijvm and
| tinybasic.
|
| Now, what is a good choice for such a situation? What is a good
| byte-code for such an endeavor? Restrictions are: 64kb of RAM not
| counting graphics or overlays for drivers that can be dynamically
| loaded, possibility of running 3 to 10 tasks at the same time,
| with a good balance of code density and performance, easy to
| implement and possibly with available tools or good example
| programs?
| akkartik wrote:
| Have you looked into CollapseOS? It might fit your criteria if
| you're willing to put up with cooperative multitasking.
|
| http://collapseos.org
| AnIdiotOnTheNet wrote:
| I've thought along similar lines a lot recently, and I think
| you end up wanting something like WASM, but without all the
| design-by-committee that comes with that. Specifically, ditch
| the parametric instructions, add arbitrary bit-width ints,
| multiple memories, a way to allocate and free memories, and
| hints[0]; and make the binary format simpler to parse by
| removing the completely unnecessary integer compression.
|
| [0] by which I mean the ability to tag functions and variables
| with an indication of what they're used for so the
| interpreter/jit is able to replace them with an efficient
| implementation if one is known to it. For instance, you
| possibly don't even need float types, just have routines for
| doing soft-float arithmetic tagged such that the interpreter
| knows they implement IEEE floating point operations that the
| processor may be able to handle on its own.
| akkartik wrote:
| If you're interested in playing with Mu, there's a guided tour
| where I try to make the process as painless as possible:
| https://github.com/akkartik/mu/blob/main/tutorial/index.md
___________________________________________________________________
(page generated 2021-12-08 23:01 UTC)