A silly scheme for an assembler that never needs to backpatch:
1. The source text can only refer to previously-defined labels.
2. The source for each procedure is backwards: *last* instruction *first*.
3. The calling convention makes it so when you call or tailcall a procedure P, that also makes the address of P available in a register. If it needs to recur, it does an indirect call through that register. Like 'self' in a Smalltalk call.
(Prompted by another scheme in @kragen 's Dercuano.)

· · Web · 2 · 3 · 0

@abecedarius hmm, so what are you thinking of for conditionals? as opposed to loops

@kragen Conditionals are forward branches, so the target has already been assembled from the backward instruction order.
I'm sort of tempted to do this as a Forth dialect -- tailcalls would get nicer too -- but the ridiculous thing is, 'interpret' and 'compile' modes would be written in opposite orders.

@kragen if one were to actually do this, then how about, to finesse the interpret-vs-compile problem, just don't provide an interpret mode? Instead be able to demark snippets of scratch code that you run and then discard immediately once compiled? Someone once designed a Forth with no outer interpreter, but I could never find a copy of their paper.
This is probably not worth doing just for a small simplification of the initial bootstrap, but I think it's worth exploring weird ideas in general.

@abecedarius I was thinking about this on the UI side the other day as I watched a screencast of using RStudio. they wrote their code in the upper pane (the script editor) but used a hotkey to evaluate each line in the lower pane as they wrote it. what would an IDE be like if we made the debugger the central focus, and everything else secondary? instead of a REPL you would add new statements to the end of a procedure that you were single-stepping, like Minsky or Beck programming in the debugger

@kragen Yes, I don't have a good handle on UI, but I want to explore.
Did I show you my process for Python under Halp? It has no debugger integration, but for trying an example and refactoring it into a procedure I like it better than the repl.
I wrote a little bit about priorities for Cant at -- but it needs to be basically usable first.

@abecedarius I think you might have shown it to me on my laptop [where incidentally I've adopted your Emacs keybining of M-o for shell-mode]

@abecedarius I really like the set of goals you've set out. I wonder what the best way is for me to understand the language as it exists today....

@kragen I could get back on IRC and chat about it? plus the examples/ dir is supposed to make the language reasonably understandable to someone of your background, but I don't know if they succeeded. I'd welcome a note on what improvements would help the most. Also the language/library are not at all cast in stone.
Lately I'm busy looking for an apartment in Austin, so it's been fallow.

@kragen examples/games/ has some of the code easiest to get into without being trivial, I guess. (Does the cbreak-mode terminal stuff work on your system?) (The core of 2048.cant is too tricky though -- I should rewrite sometime.)
Oh, and I should draw up a list of stuff that can be compared on rosetta-code -- the rosetta-code dir only has the bits that I did intentionally, but it turns out there are more examples there that can be compared, like the huffman-coding example and so on.

@kragen nand-circuit-optimizer.cant derived from one of your C programs

@abecedarius I think the issue is that to learn a thing I need to try to use that knowledge somehow. I could read through all the code (and I have read through a lot of it, including the NAND optimizer) but I won't know what crucial aspects I'm missing until I try. I guess I need to *play* is waht I'm saying, but I somehow feel that I need an objective for that play...

@kragen it'd be fair to say you have better things to do than learn my toy language in its current state. :)
One idea, though: I've always wanted to make a little Datalog to learn Datalog better. If you started that I'd be happy to help.

@abecedarius Another theory of electricity which I prefer denies action at a distance and attributes electric action to tensions and pressures in an all-pervading medium, these stresses being the same in kind with those familiar to engineers, and the medium being identical with that in which light is supposed to be propagated.

@kragen OK, touché, I've noticed that not believing my projects could realistically get uptake was self-fulfilling earlier in my career. I'll try to adjust my attitude.


I seem to have lucked into an assembler without any forward references. Ingredients:

a) Structured programming using {} labels that get translated to gensyms. There is no goto, only break/continue.

b) Labels can only be at the start of {} blocks. Like in Java, break/continue instructions can take the label of a containing block.

d) The naming scheme for gensyms is well-defined, so you can break to a named block even though you haven't seen it yet.


@akkartik @kragen Neat! I think that structure maps directly to PEG or LL(1) parsing, too?
When you're assembling a 'break', that ends up making a note to patch the jump instruction's target to be after the loop, then performing the patch after you've assembled the block, right? (Or using two passes.)

@akkartik @kragen btw, I ported a little RISC-V emulator to Python a few days ago, going to use that to start playing with bootstrapping ideas. It's too bad the encoding has these 5-bit and 7-bit fields, etc. -- funny to say it's not as nice as x86 in that way.

@abecedarius The assembler maintains a stack of unfinished {} blocks. Each block has a globally unique id, and {} get translated to <id>:loop and <id>:break respectively. So a break gets translated immediately to a jump to <top id>:break. Even though the break label has not been emitted yet, we know what it _will_ be called. Does that make sense?


Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!