VonTum

If they could raise rents by the amount they would've been taxed, they would have. I'm happy to see more incentives against buying up houses for literal rent seeking.

If you're going for "turns", then I would go even further and argue that it shouldn't be represented as a float, but rather a fixed point (signed?) integer. With 0x00000000 being 0°, 0x40000000 90°, etc. You get modular overflow for free, and the precision is consistent all around the circle.

Do you have a link to Shakey's publication?

What is a "half degree of freedom" in the matter field? (5.5 DOF from the article) Does anyone here know?The article glossed over it very quickly

I believe the "Odin" language has this simd-awareness built-in.

I find especially painful the tradeoff between productivity and visibility. Every minute I spend trying to advertise my project is a minute I'm not spending making it better.

If you want to spawn multiple threads, all with access to a mutex, but without putting it behind an Arc, then you can simply spawn all your threads in a std::thread::scope(||{...}). These let you pass references &'scope Mutex<...> I find Rc or Arc almost never the right tool for a job where I want to "share state" or such

You had me on the first three paragraphs, but the last two veer so far off course that I've no idea what you're trying to say. Mind clarifying?

Well still, why tie this kind of processing to the registers themselves? Sure having a shorthand to instantiate a queue of writes I could see, but float to fixed conversion has no place being part of a memory mapped register bank.

Wouldn't it be more sensible to have one module for converting the AXI-Lite (I presume?) memory map interface to the specific input format of your processor, and then have the processor pull data from this adaptor when it needs it? That way still all handling of inputs is done in the same place.

Edit: maybe, what it comes down to is: Should the register bank be responsible for storing the state the compute unit is working on, or should the compute unit store that state itself? In my opinion, that responsibility lies with the compute unit. The compute unit shouldn't have to rely on the register bank not changing while its working.

I find it odd the author adds all these extra semantics to their input registers, rather than keeping the FIFOs, "drain + FIFOs", "float to fixed point converting register", etc as separate components, separate from the task of being memory mapped registers. The central problem they were running into was one where they let the external controller asynchronously change state in the middle of the compute unit using it.

I'm noting down this conetrace for the future though, seems like a useful tool, and they seem to be doing a closed beta of sorts.

Well both can be true, money is only made (or lost) on market swings. It is precisely the rich who can capitalize on such swings

Whereas for regular people, an upswing means nothing, whereas a downswing means job loss, mortgage rate hikes, etc.

God Roko's Basilisk is the most boring AI risk to catch the public consciousness. It's just Pascal's wager all over again, with the exact same rebuttal.

Oh hi Rachit, long time no see. I sadly didn't have time to submit something to LATTE this year as I've been spending all my time building infrastructure for SUS.

I think improving the safety of hardware design is a noble goal, and certainly there is much that can be improved over Verilog & VHDL's incredibly brittle baseline.

Though for dynamic latency safety, my intuition tells me the problem space is undecidable. Sure one could prove the correctness of various kinds of dynamic latency pipelines, and as research progresses you'll include more and more such constructs, but it'll always remain possible to construct a correct but unprovable dynamic pipeline.

Given that, shouldn't we take a leaf out of Rust's book, and instead give the user tools to build abstractions which internally contain unprovable but correct black magic, yet on their interface provide a safe, static latency count.

Take for instance SUS' SlowState. It abstracts over an internal state, and the user provides a pipeline to update this internal state. Now, if we were to update the state twice, before the change has had time to propagate through the pipeline, that would be an error. SlowState prevents you from doing so by statically measuring the length of the update pipeline, and only allowing updates once it has cleared. Implementing SlowState requires some unsafe, but it can provide a safe interface upholding its requirement.