Well, recently I am experimenting with more fiddling on RISC-V in an attempt to improve the situation of code hot-patching (in place of always using trap-and-emulate). For this have ended up defining a new type of jumbo prefix, J52I, which expands immediate values to 64 bits and allows Abs64.

Elsewhere, had experimented with saving some line graphs as various formats. Annoyingly, none of the standard image formats is great; or at least, not good enough to solidly beat using a 16-color BMP image. Smallest file size was PNG, but PNG encoding is slow...

So, posted another experiment on here:
github.com/cr88192/bgbt...
Have recently gone and implemented a small interpreter for a simplified JavaScript like language in roughly 2.7 kLOC of C. In this case, the interpreter was written in a way to try to limit line counts...

So, status update: Not much new, most work in recent months in my project has mostly been trying to hunt down various bugs; and some work to allow my CPU core to at least try to emulate proper IEEE FPU stuff, and the idea of traps-only handling of Binary128; ... Yeah...

Work on my ISA has been slow recently. Recent "in the pipeline" features are mostly a new compressed block format (mostly for 8-bit floating point numbers) and considering a possible Horizontal-ADD instruction (but, doing H-ADD 'cheaply' is a harder problem...).

So, recently for possible loadable modules in my newer 3D engine, wrote an interpreter for a combination of my XG3 ISA and RV64G (both can coexist in the same encoding space, though XG3 and RV's C extension are not compatible). Initial testing was using a few of my Doom builds, TBD how far to go.

So, recently, have shifted temporarily to working on something 3D. In effect, trying to convert a 3D engine of mine into a sort of 3D adventure game, but for now needing to work on some relevant tech (like adding 3D model support, etc). Base colors will use a limited palette, etc...

Well, for my own uses I have ended up awkwardly gluing Verilog style number literals to C in BGBCC. Lacking anything better, I gave them the syntax like 0xABCi12 and 0xAzzi12... IMHO this is kinda ugly/wonk, but VL syntax (12'hABC or 12'hAzz) wont really work (and also still ugly). Any thoughts?

So, next random experiment: Have added Verilog style bitslicing as a C extension in BGBCC... So, basically things like "y[55:48]=x[19:12];" are now possible in my working version... Also an ISA extension to make it not slow (otherwise, it will fall back to shift-and-mask...).

Now evaluating a new/possible idea: "Jumbo-Mini-48" encodings. These would be intended for use with RVC, giving a sort of mangled version of the 32-bit base instructions with a 22 bit immediate field shoved into the RV 48-bit layout. TBD if it clashes with anything...

Grr... Had written a sci-fi story not that long ago, intended to be set decades in the future, and nearly every basic thing I had predicted for the future decades seems to be showing up IRL basically now... Seems I was maybe not "forward looking" enough? ...

So... I have decided to change my encoding scheme for jumbo-prefixes in RV64 from *-100-ddddd-00-11011 to *-100-ddddd-01-11111. Arguably, the prefixes are encoding 64-bit instructions, so this change is closer to being canonical for RV encoding rules. No one else seems to be using this space ATM.

OK, so the AMS Lite for my Bambu A1 showed up... Now printing the parts for top-mounting it on the 3D printer... But, besides taking a long time, they use a rather large amount of filament (a fair chunk off a 1kg spool). Despite not really a color match, using black as I have the most of this...

Feeling OK enough to work on it, went and assembled an alternate battery for my cordless Drill Master, using the power of 3D printing and NiMH AAs. Seems to hold up OK in basic tests, but can also note that this drill seems to have fairly low current draw, so was within power range of AAs...

So, not much getting done right now. Rather sick, probably COVID, have for the past few days not been able to do much beyond lay around. Even sitting at me PC is a bit much. If I move to much or too quickly, I start to black out... Parents here at least, more recovered...

Idle: Anyone have any thoughts for the best approach to Unicode/UTF-8 normalization in a filesystem?...
Say:
Minimal (only enforce that it is valid UTF-8);
Partial: Normalize to either canonical UTF-8 or M-UTF-8;
More: Deal with combining characters and so on;
...

Misc: I have re-licensed my C compiler (BGBCC) and emulator (jx2vm) from MIT to MIT-0 / MIT-NA. These are more permissive (one can do whatever, including discarding license), for those who complain that MIT is not permissive enough...

Copy/Paste from X:
I am left going back and forth on something:
Where I had put my RV64 jumbo prefix encoding conflicts with an older dropped "ADDIWU" instruction, and I am debating whether it is better to leave it where it is, or move the prefix elsewhere (probably into the same block as JALR).

New here, testing this out...
I have created a custom ISA, with emulator, Verilog implementation, and C compiler, here:
github.com/cr88192/bgbt...

Runs a custom ISA but now also can run RV64 (in userland), mostly targeting FPGA but aiming for OK performance. Mostly experimenting with ISA design.