search

akkartik / mu

Soul of a tiny new machine. More thorough tests → More comprehensible and rewrite-friendly software → More resilient society.
http://akkartik.name/akkartik-convivial-20200607.pdf
Other
1.35k stars 47 forks source link

Add functionality to support labels as imm32 arguments to opcodes #19

Closed charles-l closed 5 years ago

charles-l commented 5 years ago

Add support to move label address into register. Useful for higher-order functions and such.

akkartik commented 5 years ago

Thanks! Looks good.

BTW, I emailed you to show you the LoC your previous PR saved: https://github.com/akkartik/mu/commit/0b91d25cf591888252d5e99e7986e2544de31695. However, the email bounced. So thank you :)

charles-l commented 5 years ago

Oh cool! Glad that helped simplify some stuff :)

Yeah my email server isn’t quite configured properly on my site yet. Thanks for the reminder - I’ve let that sit broken for too long :P

akkartik commented 5 years ago

@charles-l I'm curious if you're working on something in particular that requires label addresses. If so I'd love to hear more details about your project.

Also let me know if you're looking for opportunities to program on SubX. I've been working on the bootstrap SubX translator in SubX, and would love to get any help.

charles-l commented 5 years ago

@akkartik yeah, I'm (very slowly) working on implementing a forth in assembly based on jonesForth. The pre-subx, half-finished implementation is here: https://git.sr.ht/~nch/onward/tree/master/onward.s

I'm working on porting it to subx before finishing it off. One of the advantages of subx (that I didn't really have with a normal x86 assembler) is being able to control every byte that goes into the binary. I wanted to sort of demoscene the implementation and build a really tiny forth binary at the end of it. The constraints of subx actually make that more straightforward :)

I'd love to help bootstrap subx! Getting foundational code right (like having properly auditable seed binaries) is something I'm very interested in.

akkartik commented 5 years ago

@charles-l: Excellent. I'm not sure what you may be interested in, so I'll just throw out a brain dump of the current state, see if anything catches your fancy.

I'm basically building a SubX translator using 3 syscalls: read, write and exit. It's going to read from stdin and write the final binary to stdout. The plan is to divide up the work into the following phases:

$ cat file1.subx file2.subx ... |dquotes |assort |pack |survey |hex > a.out

Each phase is an ELF binary constructed out of a corresponding .subx file.

(Since the translator isn't fully assembled yet, the ground truth for building each phase is currently in test_apps.)

(There's zero plans for error-checking at the moment. That's still left to the C++ implementation.)

(Hmm, as I write this out I realize I probably need another phase, to generate run-tests which calls all the test-* functions.)

Basically, I think ergonomic programming has certain prerequisites that are more fundamental than high-level syntax:

  1. Comments.
  2. Freedom to organize code and data as people wish, rather than to suit the computer. (assort)
  3. A test harness that doesn't require registering every. single. test.
  4. Literals. Particularly string literals.

Anyway, I'm starting to ramble :) As you can see, I've been working on dquotes.subx, support for string literals. Most recently that involved building a function to convert integers to string. You can sort of see a sketch of what's left to do in dquotes.subx. Alternatively we could start on survey.subx, which honestly scares me the most.

Maybe a first step would be just to get the current state building and running its tests. I'm hoping everything 'just works' for you. Try running test_apps and let me know?

charles-l commented 5 years ago

Maybe a first step would be just to get the current state building and running its tests. I'm hoping everything 'just works' for you. Try running test_apps and let me know?

Looks good -- everything seemed to work! :)

dquotes.subx seems like it'll have some approachable, defined tasks (which might be easier to coordinate for now), but survey.subx definitely interests me a lot.

What features still need to be implemented for dquotes? It looks like string literals are lifted into the data section, and you mentioned numerical literals are in place. Do you have a list of functionality (or test case that fails) that needs to be implemented next?

akkartik commented 5 years ago

I just remembered that test_apps stops at the first failure and unfortunately sometimes failures are silent. Now fixed. Could you do a git pull and rerun test_apps?

"test case that fails" is a good idea. I'm going to stop writing code for a bit and focus exclusively on writing test cases. I'll make each failing test a branch/PR that you can add code to.

I'm kinda sick for the last couple of days, though. While I think about the right sequence of tests, do you want to try reimplementing something I recently built for dquotes, both as an exercise and to see if maybe my approach wasn't the best? It's a function to print an integer to a byte stream: https://github.com/akkartik/mu/pull/20. That PR has some instructions and hints.

It's kind of an involved example, so here are a couple of simpler exercises that will hopefully help build out prerequisites:

Totally optional and for your own benefit; if you want to just work on #20 that's totally fine.

charles-l commented 5 years ago

Cool -- thanks for the clear writeup. I'll get cracking :)

BTW -- test_apps still works (it didn't fail silently before), so no worries there.

akkartik commented 5 years ago

I've written some tests for the remaining work in dquotes.subx. The main branch is #23, and there are two sub-goals: #26 and #27.