Mu: A minimal hobbyist computing stack • Hacker News Board

Re: Mu: A minimal hobbyist computing stack

#31

Post by e12e » Sat, Oct 19, 2019, 3:38 PM UTC

akkartik wrote: post #26

e12e wrote: post #24

Earlier quoted context omitted.

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…

Thanks for taking the time to reply. Is there really a 32 bit mode without segments ? I missed that last time I looked at assambly - I thought it was the other way around - you didn't escape them until you went 64bit.

As for needing needing 32bit in 64bit - I guess it would depend a bit on if you could settle for a "all 64bit all the time" subset or not (ie: no 32bit integers)?

Now, for mnemonics - I certainly don't know. I suppose I see why they're generally implied in most assemblers...

I think add_i is still a lot more readable than 0x83 or whatever. Is there a system to the numbers? Could one "mask" immediate etc (eg ADD|I MEDIATE, MUL|IMMEDIATE or some such? Where the pipe implies xor or something (forgive me, I haven't touched shifts etc in years)).

I generally prefer descriptive names to terse names - but for an assembler I don't think it fits to go overboard - not unless you expect to end up with a Forth-like quick ascent to abstraction (like building a macro/substitution that abstract away the add_immediate back to just add).

I guess I'm starting to see why primitive text macros a la m4 made its way into no just C (the C preprocessor), but also in various forms in various assemblers...

Anyway, as your system needs to to some parsing and expansion (eg: strings to binary numbers, loops, label computation) - would not exposing that as a macro/meta facility make sense?

Maybe it's more of a level 2 thing in your design?

Re: Mu: A minimal hobbyist computing stack

#32

Post by e12e » Sat, Oct 19, 2019, 4:02 PM UTC

todd8 wrote: post #29

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…

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 key…

I seem to recall an old text file on programming with just debug.exe - I thought it was an early phrack magazine article - but I can't seem to find it now. The idea was similar to 5a here:

http://phrack.org/issues/62/7.html

But the text I'm thinking of was more a how-to on bootstrapping development under win 3.11 if you had no outside resorces, and just a plain install with no other development tools.

Re: Mu: A minimal hobbyist computing stack

#33

Post by akkartik » Sat, Oct 19, 2019, 4:39 PM UTC

e12e wrote: post #31

akkartik wrote: post #26

Earlier quoted context omitted.

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…

Thanks for taking the time to reply. Is there really a 32 bit mode without segments ? I missed that last time I looked at assambly - I thought it was the other way around - you didn't escape them until you went 64bit. As for needing needing 32bit in 64bit - I guess it would depend a bit on if you could settle for a "all 64bit all the time" subset or not (ie: no 32bit integers)? Now, for mnemonics - I certainly don't…

Yeah, a simple token-based search/replace is certainly realistic to implement in level 1. The questions for me are:

a) Does it really make the code easier for newcomers to read? On the one hand the names are familiar. On the other hand it may make cross-referencing with the Intel manual harder. And you do still end up needing to do that to a certain extent. My online help refers to the standard names in parens: https://github.com/akkartik/mu/blob/3a2d36a93680f2e9eb2bd2a3...

b) Is it useful in enough places to be worth the lines of code it takes to implement?

In any case, this seems worth exploring. Perhaps we should continue on the project site? I've opened a ticket: https://github.com/akkartik/mu/issues/39. Perhaps the first step is to just hand-translate some function (say https://github.com/akkartik/mu/blob/master/apps/factorial.su...) and see how it looks.

---

One final word on 32-bit vs 64-bit. I didn't realize when I wrote the comment from a year ago how easy it is to run 32-bit code on 64-bit machines. The reverse is obviously impossible.

Re: Mu: A minimal hobbyist computing stack

#34

Post by kbob » Sun, Oct 20, 2019, 1:29 AM UTC

This reminds me very much of 1970s Unix. Unix was also an research exercise into OS and userland minimalism and a new, streamlined language (yes, C) that created a new niche in the "like asm but better" space.

In other words, it had nothing in common with today's Linux. (-:

Re: Mu: A minimal hobbyist computing stack

#35

Post by akkartik » Mon, Oct 21, 2019, 3:37 AM UTC

kbob wrote: post #34

This reminds me very much of 1970s Unix. Unix was also an research exercise into OS and userland minimalism and a new, streamlined language (yes, C) that created a new niche in the "like asm but better" space. In other words, it had nothing in common with today's Linux. (-:

Indeed, much of Mu's design was motivated by the question, "if we imitated the codesign of OS and language that led to Unix and C, given what we know now, what would we create?" This question doesn't seem to be often asked in recent decades, with languages and OSs evolving separately.