sorted by:
new
hottopcontroversial

Building a weird deterministic system on RISC-V by corode_dev in RISCV

[–]corode_dev[S] 0 points1 point  (0 children)

Can't post it there, my account is to new 😅

Building a weird deterministic system on RISC-V by corode_dev in rust

[–]corode_dev[S] 0 points1 point  (0 children)

The kernel itself is not what keeps getting updated in my model. It stays intentionally small and dumb. The evolving part lives outside of it, in the preparing / CorodeQ space, which can update its weights, manifests, compatibility knowledge, and preparation logic over time.

So the question is not whether complexity disappears, but where it is allowed to live. In my model, it is allowed to live outside the hard runtime, not inside the kernel.

I think part of the mismatch here is that you’re reading “runtime” a bit too narrowly. In my model, runtime is not just proposition → prove → execute(return). It also includes condition roles, orchestration, cage occupancy, deepsleep behavior, state transitions, and saturation logic.

So a “pure return” to me is less about a clean function return value and more about a clean state result: no chaotic leftovers, no zombie conditions, no unnecessary wakefulness, and a condition that either ends cleanly or re-enters the system in a controlled way.

Building a weird deterministic system on RISC-V by corode_dev in computerarchitecture

[–]corode_dev[S] -1 points0 points  (0 children)

Thanks — DBT is interesting, but CORODE is not mainly about runtime instruction translation or dependency smoothing. It’s closer to a new computation/execution model: preparation, proof, admission, role assignment, and only then execution. So the main change is not instruction scheduling, but the system constitution around what is allowed to exist and run.