νδπ @ndpi@merveilles.town
I'm fascinated by learning, thinking, and computers.
At my day job I work at the intersection of autonomous systems and satellite engineering. I make some things on the side, when I feel like it. I travel when I can; I like to take photographs. Occasionally I'll have an interesting thought or two.
Joined Jan 2020
Eyeing The Open Book and wondering if it's worthwhile to try building one.
In other news, my Kindle auto-updated and now it will neither connect to my WiFi nor let me turn it off. Fuck off, FAANG, and quit trying to control what I do with my own damn devices!
Considering writing an email filter that will automatically delete anything with an emoji in the subject line
Ok, here’s what I’m thinking. Maybe I can create some read-only blocks of Forth source as a linkable ELF file and map them into the binary at the flash area. Then you could LOAD them from user programs and FORGET them when you’re done, doing application switching in the classic Forth manner. That would keep the newly defined dictionary words in RAM, but hopefully there’s not going to be too many of those. If it’s an issue I could look at compiling them as well.
Aww man, the flash is read-only. Can't use it for block storage apparently. That's a real bummer!
I wonder what other options there are. I had considered, for example, using an SD card since you can talk to them over SPI. That wouldn't work in the emulator but it would on a real board. I'm going to have to look at how you can compile the Forth source into the hex file so that it can be written to flash as part of JTAG programming.
Fleshed out most of the core assembly primitives, including NUMBER. I’m still running in the debugger for now, but I’ve verified that basic operations like addition and subtraction work! I’ll have a read through the Forth parts of Jonesforth later; I expect they should run mostly unmodified on my kernel.
Oh wait! It's not 512K, it's 512 MEGABYTES. Holy smokes, that's a lot of data.
Currently sitting at a little under 4K when assembled and linked. There's still a few primitives I haven't implemented, but I think there should be lots of space for libraries and for block storage on the flash chip (it's 512K)
After a few hours in the debugger, I now have INTERPRET/QUIT working! The top level loop is functional! 🎉
Now to flesh out the remaining assembly builtins.
One thing I hadn't considered when I started on this port is that it would be nice to store most of the "standard" library in the E310's onboard SPI flash memory. I could bake it into the object file, or figure out how to tell the interpreter to write the code there. (Not a problem to solve today though.)
Fleshed out a minimal interpreter and got it to assemble today. No support for reading literals, few built in words. It doesn’t run yet, which is unsurprising, so tomorrow will be a debugging day! Hoping to get to the point where I can at least print the version number.
😬 Feeling a bit antsy about all the assembly I'm writing with no testing whatsoever. Writing a test harness for this stuff feels like it'd be about as much work as finishing the Forth, so I'm just pushing along and hoping I get it mostly right. Right enough to debug, at least.
I have a few Forth primitives (colon interpreter, some stack manipulation operators, some memory words like !) defined in RISC-V assembly but no way to test them just yet. Before I get too far into implementation, I really want to exercise these. I might wind up writing a little test harness, or I might push forward and skip most of the rest of the primitives until I get to KEY/WORD/EMIT so I can test things interactively.
Today I learned about how assemblers and linkers do code relocation and how that affects macros in GNU ‘as’. Wound up having to modify the linked list feature in Jonesforth’s “defword/defcode” macros to compensate.
It's been fun teaching one of my coworkers #Rust by taking turns pair programming on a TUI app. Hoping we'll be able to make it open source sometime in the near-ish future.
Wishing there were something akin to Blinkenlights for RISC-V. It would help immensely as I'm learning the assembly language.
Taking a break from programming tonight. If I do it too much, my brain fixates on it and I dream in code. It's not a good way to get rest, so tonight I'm playing games instead.
Spent the past hour pondering how to translate two lines of x86 assembly into RISC-V. This is going to be quite a learning experience.
Printed out a hardcopy of the Jonesforth listing; looking forward to starting a port to bare-metal RISC-V tonight! 😋
Ok! Got the bones of a baremetal RISC-V assembly programming and emulation environment set up with QEMU, targeting the SiFive E310 chips. Looking forward to playing with this on days when I'm not feeling like Rust.
Another incident in my litany of hardware failures: my iPhone X, which previously survived a dive into a river, has stopped responding to touch input for no apparent reason. It may be residual damage from the fall, or from the repairs I made after.
Not looking forward to trying to repair it again... I wish the Mudita Pure would come out so I could justify replacing it!
Started on a new project today which I’ve been daydreaming about for a while: a spatial thinking tool, written in Rust against SDL2 with extensions plugged in via 9P. I’m trying to make the core as minimal as possible, and push most functionality onto helper programs through that interface.
I'm fascinated by learning, thinking, and computers.
At my day job I work at the intersection of autonomous systems and satellite engineering. I make some things on the side, when I feel like it. I travel when I can; I like to take photographs. Occasionally I'll have an interesting thought or two.
Joined Jan 2020
