Profile avatar
bgbtech.bsky.social
Hobbyist programmer (C, Verilog, ASM, etc), CPU and ISA design, have my own C compiler, 3D and GL, ..., and sometimes electronics. ASD/aspie, single (ace/demi), Gen Y. Currently lives in OK.
49 posts 18 followers 30 following
Regular Contributor
Active Commenter

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.