💾 Archived View for gemini.sensorstation.co › ~winduptoy › project.x.log.gmi captured on 2023-06-14 at 13:54:07. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
I'm finally at the point in my life and career where I can set down the typical grind work and pursue something really unique, something that really pushes my limits and creativity, something that when I look at even now I think "there's no way I'll ever be smart enough to pull that off." I currently struggle to see a future for myself with much fulfillment if I were to follow a safer career path.
I'm not ready to publicly disclose the full nature of this project, but I'm keeping track of the work I accomplish on a daily basis to remain motivated and look at how far I've come.
started thinking about how to encode pushing literal values onto the stack.
tried the following simulators to execute armv6m instructions with no luck. they either fail to compile or vomit on the assembly I throw at them. I've tried everything on Google/GitHub and I'm stunned that I can't get any of them to work. makes me wonder why ARM doesn't supply an official simulator; maybe to sell more hardware dev kits.
at the end of the day I just gave up and ordered some hardware. luckily the RP2040 and Pico Debug Probe are cheap.
validated bl instruction encoding (33 instructions!) using cemu. not beautiful but it got the job done. implemented encoding of 32-bit literals into dictionary definitions (loading forward in memory, pushing to stack, and then jumping over the literal).
started implementation of offset-to-bl-instruction encoding. investigating a faster-simpler armv6-m emulator that supports Thumb 2.
working on moving to a subroutine threaded forth. inlining code into a definition is straightforward, but encoding a call to each subroutine seems to be tricky because with Thumb instructions you can't just put a 32-bit address down and jump to it. You can either `ldr` it from a static pool somewhere (slow), mash one together with a bunch of `mov`s and shifting (lame), or `bl` to a PC-relative address. opting for the latter, ARM's encoding scheme is a lot more complicated than just [opcode][offset]! so while trying to decipher this with a test case, I ran a disassembly on an object file with `objdump -D`. after tedious bit manipulation and head scratching, I realized that the offset in a `bl` instruction is meaningless until after it's linked. wasted a few hours on that one. all good now though: the PC is assumed to be AFTER the 32-bit `bl` instruction.
refamiliarized myself with the JonesForth code. decided to move to a subroutine threaded forth after reading Brad Rodriguez's "Making Forth."
just finished reading Starting Forth and Thinking Forth.
I spent the last few days documenting the memory layout I expect the system to have and the interaction among the core forth systems (dictionary, scheduler). I think this will help me pick a target for what to work on next rather than just opening the text editor and making a guess every day.
I used Richard Hipp's awesome pikchr tool to create inline diagrams.
I spent a few weeks getting the Unicorn emulator up and running in a python environment. the python version is easy to install with pip, but has slower than expected execution. I suspect there's a high cost of crossing the C/Python barrier to run memory callbacks.
I experimented and built the core of JonesForth, translating from x86 to ARM as I went. it accepts input over UART, although waiting in a busy loop so it's not pretty. things I learned during this period: