etcimon

I've been looking forward to RISC-V for a long time and seeing as the semiconductors industry has typically been heavily gated, it came as a surprise that nobody had yet tried adapting a build environment to start your own CPU company with Claude if you want it. So I've been reading a lot about SystemVerilog, the RISC-V specs covering everything about cpu design, how it works through controllers to get to the boards, and I wrote a repo with all agentic features, build-platform, etc. licensed as MIT for anyone interested in the subject.

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...

It does have a use but not in the colloquial sense, history is plastered with bad winners yielding to their predatory instincts and a malicious Jinn is one of infinite ways you can visualize something that pulls/pushes into the abyss for a competitive comparative sense of superiority. Understanding it doesn't make it happen less because the phenomena exhibits in circles that mock thought itself. But taking it into consideration in thought does tend to improve the outcome of novelty the same way an engineer looks as Murphy's Law as a warning not to seek positive thoughts for the sake of it but look at failure modes because they're central to good design

There's multiple ways to look at the economy, the raw exchange of dollar currency in a debt chase (shit I need to run faster & pay down this stuff!), there's the productivity of industrial output (shit we need to sell more junk and useless crap!), and there's the stock and productivity in optimal life cycles (Damn, that Nokia is a tank!)

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

All those software turds getting liquidated and replaced by open source would be the best thing for humanity altogether

Tutorial / Guide

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.

With token prices going up for many of the smarter models, I was pondering about how to be more efficient with prompts. Also, there IS an infinite loop possibility in coding agents.

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

Power and control over people's lives and public image is what they get off on, how can anyone feel like they have purpose working on that is beyond me, so it's true that innovation would be thwarted by procrastination - if they give them the "next big thing" it'll be monopolized and weaponized rather than given to the people like tcp/ip initially was. The key term is decentralization, and it's being blown up in favor of locked up datacenters behind layers of digital policing.

Would probably need a few more benchmarks to determine if it scales or if it's a bottleneck

The coroutines (fibers/tasks) work in the same way threads do in a kernel. Vibe.d is a reimplementation with something called "fibers", with task-messaging, task contexts, context switching.

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.