etcimon

Releasing GSys LibreCore today, includes a bios, sv-timing adjustments (3ghz+) configurable to multi-core, multi-issue with QEmu and heavily tested for SMT2.

The AI Processor has shown promising results with 40x speed improvements on VA-Turbo

Agentic-friendly RISC-V development with state-of-the-art features

Read more on Github https://github.com/etcimon/GSys-LibreCore

Essentially, I had Claude analyze the specs and build up summarized chapter-based sections on status with CV6, towards modelling the development and making Claude write through my instructions how it needs to navigate everything as it develops in SiliconVerilog or even using SKiDL to create a custom board. It's still passing all the CV6 tests but the agentic boilerplace is pretty much in place and ready to tinker with processor development!

https://cimons.com/article/developing-a-risc-v-processor-soc...

If 10% of the population went away, it would affect 1 & 2, but in any true practical lens, there's a ton of cheap empty houses, while on the other hand building repairable stuff that lasts or enough cheaply is where economies move to more complex technologies by saving time and effort in useless endeavour of debt chases or consumption-oriented wasteful productivity

There's a certain level of proper model selection where leveraging the capabilities prove optimal in certain tasks with Claude 5.8 excelling in structuring and a mid-tier such as GLM 5.2 can get a lot of heavy lifting done with relatively reasonable better returns given the prompt is crafted according to the way those models work.

So, knowing what I want was usually the most accurate predictor for costs (other than the small tricks) amongst other things. Here's an outline of some of those solutions about optimizing Claude tokens on my blog

When using poll or select kernel functions, your thread "yields" and allows other processes to do some work while your process waits for i/o data. Fibers work the same way but the waiting happens within your process.

Basically, when all fibers are waiting, there's going to be events in the kernel (using epoll or iocp) with the associated fiber pointer to wake it up when something comes up. The fiber (aka task) is called with Fiber.call() when there's news and automatically restores its stack and context, but maybe it has more data in the circular buffer or the manual event you were waiting for was triggered, so the routine can go forward (otherwise, Fiber.yield() is called again and waits for an event from the kernel).

This allows the code to stay linear somewhat. Low-level buffers are all meant to yield when data is not available. Every time a new connection happens, a new fiber is created, same goes when you call runTask.