raphlinus

Oooh, I hadn't seen that. It's very cool.

The main difference is that it primarily targets 8-bit chips, so often has to expand a statement into multiple instructions, while I'm targeting ARM, which can get quite a lot done in a single instruction. But I absolutely will cite it as precedent.

Blackfin is one of the things I looked at. I go quite a bit farther, with named variables, richer types (struct fields are named), block syntax, and generally capturing as much programmer intent as possible while maintaining an almost 1-1 mapping between statements and assembler instructions.

Time is a circle. Assembler could come back if it's an appealing target for LLMs. Currently it's not, but that's my hypothesis.

I haven't implemented debugging yet, but I expect the situation to be good, for the following reasons:

* It's possible to embed variable names into the debug info, so your debugger inspects those rather than just numbered registers.

* Optimizing compilers can do transformations which highly obscure the relationship between source and binary code. Here they closely match.

Thanks for your interest!

I don't allow such rewrites, you have to be explicit. If you write something that doesn't have a valid assembler encoding, its rejected at compile time.

It helps that I'm currently targeting ARM (Cortex M33, RP2350 specifically). Old-school x86 would be much less pleasant, as it's got so many arbitrary-seeming rules of what works and what doesn't. One quirk, when optimizing for file size, are the rules for which instructions have 16 bit encodings and which need 32. But again, the plan is to have a tight feedback loop.

Dioxus -> Cognition

This really feels like full circle for me. Back around 2012, I started "music synthesizer for Android" and put an app on the Play Store. This was a 20% project for me – I was on Google Fonts at the time, but I really wanted to play with Android. I decided to emulate DX7 because I had really wanted one as a teen (I did have a CX5M, so I was familiar with FM synthesis).

I set myself the goal of putting a DX7 in the hands of a million people. My little app only got a fraction of that, but now that the engine is in Dexed and now the M-VAVE, it seems like that might well happen.

I wonder if they'd send me one. But for $60 I can just get one :)

I disagree with this advice, and consider it outdated.

Arguably, seq_cst is helpful for informal reasoning, because it's not hard to imagine all permutations and interleavings. But in my opinion, nobody should be doing lock-free programming based on informal reasoning. Algorithms should be considered incorrect unless they've been rigorously validated, ideally with formal methods or at least model checking.

Very few lock-free algorithms require sequential consistency. There are exceptions, such as Chase-Lev queues, but they are rare.

The added confidence that seq_cst gives you if the algorithm hasn't been properly validated is IMHO worthless.

You've got a point but are overstating it considerably. There is a big gap between just autovectorization and the portable primitives a library like Highway or Fearless SIMD will give you. For example, I haven't seen autovectorization do select or swizzle.

But there's another point in the tradeoff space. One of the explicit design decisions in Fearless SIMD is to support "downcasting," or specialization to a specific microarchitecture. At least for the kind of problems I've worked on, even when you're doing something fancy with arch-specific permutations or what not, the majority of the operations will be pretty vanilla, and can be expressed well in the portable subset.

So you can think of a library like Fearless SIMD as enabling your extreme optimization use case, just more ergonomically.

Of course, this depends on LLVM compiling intrinsics to assembly efficiently. That hasn't always been the case, and is not perfect now (a number of issues have been filed against rustc and LLVM while developing Fearless SIMD), but is pretty good.

As always, though, you do have to measure performance, and I frequently look at the assembler output to double-check that it's doing the right thing. The day of "fire and forget" portable SIMD has not yet arrived.

Yes, four cores in the chip. And yes, there's additional muxing, but I think that adds a fairly small amount of chip area compared with the crossbar. In addition to the two core slots, there are a lot of peripherals contending for single cycle bus access.

I had a sense. Pangram identifies this as AI.