Add functionality to support labels as imm32 arguments to opcodes

[charles-l]

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

[akkartik]

Thanks! Looks good.

BTW, I emailed you to show you the LoC your previous PR saved: 0b91d25. However, the email bounced. So thank you :)

[charles-l]

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]

@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]

@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]

@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.

• hex.subx converts a sequence of bytes in hex into a binary. (done)
• survey.subx will turn labels into addresses, and also slap on ELF headers. It's called 'survey' because the act of imposing a coordinate system on a program feels somewhat like surveying terrain and determining various distances and heights. (not started)
• pack.subx converts bitfields in instructions into whole bytes in the right order. For example, 0/mod 1/rm32 1/r32 is turned into the single byte 08. (done)
• assort.subx just reads in many segments starting with == and containing lines of code or data, and concatenates all segments with the same name. (done)
• dquotes.subx moves string literals in the code segment to the data segment. (in progress)

(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]

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]

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: #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:

• adding two numbers: @charles-l's solution: add two numbers #21
• writing a string to a stream: exercise: reimplement writing a string to a stream #22

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

[charles-l]

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]

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.