Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mu: A minimal hobbyist computing stack

akkartik.name

Post reply on HN
Print view View original

21–30 of 35 posts

Re: Mu: A minimal hobbyist computing stack

#21

Post by akkartik »

carapace wrote: post #14

I find this really inspiring! I've got a similar hobby project (that I've been neglecting recently...) but with some different design choices. I don't want to hijack the thread but I thought it might be interesting to compare and contrast. Instead of targeting x86 it uses Prof. Wirth's RISC CPU for Project Oberon. This is a really simple chip, there is a model function for it written in Oberon that is less than a pag…

This sounds really interesting. I'm very happy you shared it. I'd love to see it when you publish it. Based on your description it seems like a lot of code, so I'm curious to see how tight we can keep the dependency chain.

Re: Mu: A minimal hobbyist computing stack

#22

Post by akkartik »

bitminer wrote: post #17
akkartik wrote: post #9

Author here; I just found this thread. Feel free to ask me anything.

What's old is new again. Your thoughts on the benefits of language slightly higher level than assembler are interesting. Others have trod this path before. Bliss32 was the systems language for vax/vms back in the 1980s through 2000s. Most of vms was written in it. It was heavily influenced by PL/360 from the days when IBM 360 or 370 mainframes were mostly programmed in assembler. Both languages emitted very predictab…

Fascinating. Glad to have this on my radar.

Re: Mu: A minimal hobbyist computing stack

#23

Post by eterps »

akkartik wrote: post #20
eterps wrote: post #19

akkartik, I see the following 3 syntaxes for 'MOV ESP, EBP': 89/ Only the last one contains all information needed to encode the instruction. And the first one is used in the factorial example. Can you explain why all the 3 syntaxes are in use?

Yeah, the last one is the 'ground truth' that both translators understand. sigils.subx adds some syntax sugar so you can say 89/ By my self-imposed rules I can't use this sugar until I build it, so there's little code that uses it at the moment. But any future Subx code will use it, such as the implementation of Level 2. You can also see it used in calls.subx, which is another later layer of syntax sugar. Could you p…

In http://akkartik.name/post/mu-2019-1 if you search for the pattern '/89' you'll find the first two versions.

The 3rd one is here: https://github.com/akkartik/mu/blob/master/apps/factorial.su...

Can you explain in a sentence what rules are used to complete the encoding for the variant:

> 89/<- %ebp 4/r32/esp

Re: Mu: A minimal hobbyist computing stack

#24

Post by e12e »

akkartik wrote: post #18
e12e wrote: post #15

Earlier quoted context omitted.

Some interesting parallels to choices made in Pascal in the second level language, too. I'm not convinced that this approach is the best - the first level language is a bit like "literal programming" machine code (not assembler) - but I think a level of simple substitution would help a bit (think m4 as an assembler) - allowing at least mnemonics. The insitence on numbers seem somewhat arbitrary as they still need to…

This is a very acute critique, so it seems like the perfect place to elaborate on why I chose numbers. We tend to think of Assembly programming as using mnemonics, but really the names of instructions in x86 are more than that: there are 14 different kinds of add instructions ( https://c9x.me/x86/html/file_module_x86_id_5.html ) If a single name can map to this many distinct cases, it's not a mnemonic anymore, it's a…

Maybe I skimmed, but I didn't note anything on this (anything this clear at any rate) in the text.

It certainly is a justification for exposing the different op codes.

I still think symbolic names for symbolic numbers make sense,though. And I'm not sure a table in one place looses out on clarity.

I do think it's good to re-think assembly notation (que gas/masm/nasm/x86/6800 notation wars).

I guess I feel at the level of level 1 - there is some symbolic manipulation and meta programming already (eg loops, labels for computed jumps) - and that "dumb" replacement might even turn out to me more clear.

Comments go away (replace with nothing), jump-to-labels become jump-to-offset, opcode mnemonic become binary numbers, numbers become binary numbers etc.

I confess I wonder at the choice of 32bit as I find amd64 to be both clearer, more sane (better? Calling convention) - and it should be more powerful (eg more registers) - faster and allow addressing more memory (if/when that becomes and issue - say mapping an entiere 6tb drive into contiguous memory?).

Re: Mu: A minimal hobbyist computing stack

#25

Post by akkartik »

eterps wrote: post #23
akkartik wrote: post #20

Earlier quoted context omitted.

Yeah, the last one is the 'ground truth' that both translators understand. sigils.subx adds some syntax sugar so you can say 89/ By my self-imposed rules I can't use this sugar until I build it, so there's little code that uses it at the moment. But any future Subx code will use it, such as the implementation of Level 2. You can also see it used in calls.subx, which is another later layer of syntax sugar. Could you p…

In http://akkartik.name/post/mu-2019-1 if you search for the pattern '/89' you'll find the first two versions. The 3rd one is here: https://github.com/akkartik/mu/blob/master/apps/factorial.su... Can you explain in a sentence what rules are used to complete the encoding for the variant: > 89/<- %ebp 4/r32/esp

Ah, I see. Yes, I mentioned in the post that I was dropping some magic numbers. Mu is intended to be read in a text editor, and I didn't want to scare people too much while reading the post in a browser. Slightly evil, I know.

The concrete rules are illustrated at https://github.com/akkartik/mu/blob/469a1a9ace9b290658beb9d0.... In this case `%` always translates to `3/mod /rm32`.

Re: Mu: A minimal hobbyist computing stack

#26

Post by akkartik »

e12e wrote: post #24
akkartik wrote: post #18

Earlier quoted context omitted.

This is a very acute critique, so it seems like the perfect place to elaborate on why I chose numbers. We tend to think of Assembly programming as using mnemonics, but really the names of instructions in x86 are more than that: there are 14 different kinds of add instructions ( https://c9x.me/x86/html/file_module_x86_id_5.html ) If a single name can map to this many distinct cases, it's not a mnemonic anymore, it's a…

Maybe I skimmed, but I didn't note anything on this (anything this clear at any rate) in the text. It certainly is a justification for exposing the different op codes. I still think symbolic names for symbolic numbers make sense,though. And I'm not sure a table in one place looses out on clarity. I do think it's good to re-think assembly notation (que gas/masm/nasm/x86/6800 notation wars). I guess I feel at the level…

You're absolutely right, this wasn't in OP. It seemed like a minor detail at the time.

What should the mnemonics be called? SubX is already quite verbose. Would you be willing to put up with long names like `add_immediate`?

32- vs 64-bit is certainly a subjective choice. I outlined some reasons for my choice a year ago: https://lobste.rs/s/jkmwer/what_are_you_working_on_this_week.... But 64-bit is certainly a valid processor to target.

Re: Mu: A minimal hobbyist computing stack

#27

Post by carapace »

akkartik wrote: post #21
carapace wrote: post #14

I find this really inspiring! I've got a similar hobby project (that I've been neglecting recently...) but with some different design choices. I don't want to hijack the thread but I thought it might be interesting to compare and contrast. Instead of targeting x86 it uses Prof. Wirth's RISC CPU for Project Oberon. This is a really simple chip, there is a model function for it written in Oberon that is less than a pag…

This sounds really interesting. I'm very happy you shared it. I'd love to see it when you publish it. Based on your description it seems like a lot of code, so I'm curious to see how tight we can keep the dependency chain.

Cheers! The project is here: http://joypy.osdn.io/ FWIW.

The Prolog code is under the ./thun subdir. I apologize for the state of the repo & docs. I need to go through and update everything.

If you look at the Python code the vast majority of it is the type inference module and the library of functions and combinators. The parser, main loop, and most of the library are trivial. Most of the joy.utils.types module is a crude re-implementation of a subset of Prolog and can be discarded. The Prolog version of Joy is even shorter than the Python version.

The Joy compiler (which is only about half done) is really tight and simple (Joy doesn't use variable so no need for a symbol table; Joy doesn't use subroutines so no need for a call stack) and the last half of the functionality won't require double the code.

Meta-programming in both Joy and Prolog is really easy and powerful, and Joy in particular lends itself to a kind of Huffman encoding of your graph (Joy code forms a simple DAG.)

- - - -

I want to repeat, Mu is really inspiring. I'm looking forward to watching your progress. :-)

Re: Mu: A minimal hobbyist computing stack

#28

Post by radEd »

akkartik wrote: post #12
radEd wrote: post #11

Earlier quoted context omitted.

Would you recommend this for someone who hasn't yet officially learned operating systems/compilers, but is looking to break into the realm?

I hope so! It's new so you may find breakage, but I'll try to be very responsive answering questions. Mu doesn't have its own OS at the moment. It runs on Linux and on Soso ( https://github.com/ozkl/soso ). I don't know either well, but hopefully I'll at least be a good study partner. And you can definitely ask me questions about the language side and the interface with the OS. Mu doesn't have every feature of modern…

"Mu doesn't have every feature of modern compilers and OSs, but it should hopefully give you a view of something simple working from end to end that you can then carry with you when making sense of more complex systems."

Awesome, that's what I was hoping for: something that will lower the entry bar but still provide useful education for the greater world.

Re: Mu: A minimal hobbyist computing stack

#29

Post by todd8 »

e12e wrote: post #15
eterps wrote: post #4

Interesting project. So far the only desktop OS + compiler I know that can be reasonably understood in its entirety is http://www.projectoberon.com

Some interesting parallels to choices made in Pascal in the second level language, too. I'm not convinced that this approach is the best - the first level language is a bit like "literal programming" machine code (not assembler) - but I think a level of simple substitution would help a bit (think m4 as an assembler) - allowing at least mnemonics. The insitence on numbers seem somewhat arbitrary as they still need to…

An interesting thought experiment that I've pondered is what I would do if I was given a system that I had to program without even an assembler.

I've programmed on systems where the only access was through direct memory access to the machines memory, and other systems that had a boot loading initiated by a button that started a paper tape reader. I've also used minicomputers that had to have instructions manually keyed in on binary panel switches directly into memory to start a card reader where the cards contained machine instructions to bootstrap the rest of the boot loader off of the remaining cards.

In every case though, somewhere I had an assembler to write the code I needed. What would I do if I didn't even have an assembler? I could write one, but I don't want to do it in machine code. Now days, the easy way would be to simply construct a cross-compiler or cross-assembler that was written in say python on a different machine.

One alternative is to build a hand assembled, really simple macro system. m4[0] or Calvin Mooers' TRAC[1] are possible prototypes, but these flexible macro systems would be difficult to hand compiler into machine code so one might get by with a really basic, more limited macro system. Then each machine instruction could be encoded as a macro and then a primitive assembler could be written as macros.

However, real assemblers do more work, they generally take two passes because they allow symbols to be used instead of literal addresses. So the next step would be to program a real assembler using the primitive assembly language.

After that I suppose a compiler for a simple language like Pascal, basic Lisp, or Per Brinch Hansen's Edison[2] language could be written in assembly language.

Per Brinch Hansen provides the basic directions for construction a very simple operating system from scratch, including the assembler and compiler in the book Programming a Personal Computer[3].

[0] https://www.gnu.org/software/m4/

[1] https://dl.acm.org/citation.cfm?id=365270

[2] http://brinch-hansen.net/papers/1981b.pdf

[3] https://www.amazon.com/Programming-personal-computer-Brinch-...

Re: Mu: A minimal hobbyist computing stack

#30

Post by akkartik »

e12e wrote: post #24
akkartik wrote: post #18

Earlier quoted context omitted.

This is a very acute critique, so it seems like the perfect place to elaborate on why I chose numbers. We tend to think of Assembly programming as using mnemonics, but really the names of instructions in x86 are more than that: there are 14 different kinds of add instructions ( https://c9x.me/x86/html/file_module_x86_id_5.html ) If a single name can map to this many distinct cases, it's not a mnemonic anymore, it's a…

Maybe I skimmed, but I didn't note anything on this (anything this clear at any rate) in the text. It certainly is a justification for exposing the different op codes. I still think symbolic names for symbolic numbers make sense,though. And I'm not sure a table in one place looses out on clarity. I do think it's good to re-think assembly notation (que gas/masm/nasm/x86/6800 notation wars). I guess I feel at the level…

I went back and added a couple of paragraphs about the opcodes in OP (section 'instructions'). Thanks for the feedback!
Post reply on HN