Yes, it's all software, and FM synthesis is using the same engine as dexed. It's a Blackfin chip, which has pretty good throughput for DSP (digital signal processing). A ton more detail is at [1], including the operating system, which is a FreeRTOS-derived SMP kernel.
I get your point but disagree strongly. One topic that's been on my mind a lot is durability. The culture of LLMs is that everything is transitory. Why bother keeping a vibe coded codebase around for more than a few weeks, when the next big model iteration will be able to vibe code it better?
By contrast, free software in general, and Rust very much in particular, has cultural norms that things should last a while, rather than immediately being thrown away. I think that's worth preserving.
Yes, and? As the cost of code generation approaches zero, this starts to make more sense, especially if you do have mechanisms in place to ensure safety and correctness.
I did an experiment a couple weeks ago of having Opus 5.5 translate an MP3 decoder from Rust into Cortex-M33 assembly language, both raw asm and symbolasm. The code was 3x smaller and ~1.5x faster than Rust -O3. These seem like gains that are worth it.
As the cost of code gen approaches 0 the cost of the test suite actually grows. Not just in definition, but execution.
An MP3 decoder for a single target doesn't really run into that complexity, a UI components library for (Linux, Windows, macOS) * (x86-64, ARM64) suddenly has a 6x multiplier on what was already something with waaay deeper dependencies and integrations than MP3.
At least that's what I've noticed vibing my DE without external libraries. It went really fast when the complexity was small because most of the work was in adding code. Then it started taking longer to build and test, even with optimized builds and tests, than it took for the AI to do its part.
Yes that makes sense, but if you're iterating on software then I think C will generally win due to its ability to compile cross-platform until you want to build a "release" which you could do by having Fable translate it to ASM at that point.
Did you have it go directly to asm or emit the assembly from the Rust toolchain and then contract that? For small stuff, I have been having it write directly, or larger pieces I am having better results via contractions.
I should add, part of the experiment was to test whether having variable names and (C style) types would help the LLM. For a task of this size (about 1.5 kLoC Rust, 3k insn asm) it was inconclusive, but for larger projects I suspect it would make a difference.
And the plan for symbolasm is to move past C style types into Rust style and maybe dependent typing, specifically to facilitate automated proofs.
Thanks! I had a feeling there was something out there, but couldn't easily find it. I can see this is well optimized for speed, but the RAM usage looks scary from the perspective of a really memory constrained chip.
On the RP2350, a load from memory and a move-immediate both take 1 cycle, because there's a separate data bus to fast SRAM. If I did want more speed and didn't mind an expansion in font size, I could store each glyph in its own byte/word and avoid the ubfx instruction. But on this chip, for a reasonable speed/space tradeoff I'm going to optimize for space every time.
Indeed, it's not clear that my stuff would have any utility in today's higher-end CPUs, either. But it was fun and zippy in the Motorola 680x0 days (I miss writing to the frame buffer). Certainly this is just related to your stuff, but with different goals never mind wildly different time/space trade-off. (Hi, Raph!)
The text mode is generated per Scanline using an ARM core, Tile, image, and sprite layers are all DMA+PIO generated.
So a Tile Layer is
TileMapDMA
|
V
TileIndexPIO
|
V
TileDataDMA
|
V
UnpackPixelIndex_PIO
|
V
PaletteReadDMA
|
V
TransparencyPIO <-- ScanlineBufferReadDMA
|
V
ScanlineBufferWriteDMA (Yes this was as hard to debug as it looks)
To do the entire tile map with paletted tileset happens in a single chained DMA operation, the other layers are a little simpler. It could generate the entire display without using the CPU, but the memory for the display Descriptors would take up too much memory, so there is a simple interrupt at the start of each scanline that updates the pointers in the DMA descriptors for the source and destination addresses that change per scanline.
I did have a text mode running without CPU as well but it was cumbersome due to the attribute color lookup adding another map lookup. Now it is spending just a little CPU time per scanline to do the ReadChar, Read Attribute, read Font to convert it into a 1 bit-per-pixel image with a color per byte.
Performance is better that way, even if it does make a little more work for the CPU, the scanline renders quicker. Since they all render into the single scanline buffer, you can do as many layers as you have time for, so using no CPU is no good if it still takes too long.
I think you're right, but rather surprisingly I have some experimental data on this question that is inconclusive at best. My hobby project is symbolasm, which is intended to close exactly the gaps you describe: by naming variables and introducing types, it re-adds much of the context that assembly language erases. I ran a quick'n'dirty experiment to see if it would make the LLM more efficient at writing code than raw assembler.
The task was rewriting an MP3 decoder from Rust into ARM assembly language, Cortex-M33 flavor specifically, optimizing for both speed and code size. The output is approx 3k instructions. The tl;dr is that Opus 5.5 nailed the task, whether writing assembly or symbolasm. It took approximately 2x tokens for the latter, which I think is largely explained by the fact that it was dealing with a novel language nowhere represented in its training set.
The quality of the result was comparable; the raw asm was slightly faster and slightly less dense, which I consider insignificant because I think you can get the same effect just by tuning the prompt. In particular, if I were re-running the experiment, I might set a strict code size budget and then ask it to optimize for speed within that budget, allowing comparison on a single scalar.
The experiment was compelling in another way: the code was 3x denser and 1.5x faster than -O3 output from Rust. So for certain applications, going to assembler will be worth it, especially as the cost of generating the code goes to zero.
And there is the following critical advantage: you decouple your code from any compilers. Some compilers are sane of course, and their devs are doing an amazing job (look at cproc/qbe/etc), unfortunately the mainstream ones are c++ abominations (gcc and clang/llvm) which we should depart from.
If all this AI thingy is true, the decompiling and recompiling directly from the machine code is a sort of proof that what's the most important is the data model. Additionnaly, when I get into some software which I did not write, I must focus on this data model in order to understand it, and guess what, the direct memory one from 'human' assembly/C is usually much better than those giga-convoluted object oriented abstracted ones (I think the worst one was llvm, usually everything c++ is).
Some are generating "human" assembly code for their everyday software (I am following some of those projects I found here, on HN). Again, if all that is true, the killer feature: you could generate "human" assembly for several ISAs fitting one data model, for instance the IP UNlocked RISC-V (vectorized or not)!
Worth noting, WGSL does this too, and is mostly a bit stricter than Zig: `a + b & c` and `a << b & c` are errors in WGSL but accepted by Zig. (Quick: off the top of your head, how do those parse)?
[1]: https://github.com/AL-255/FM-1-RE
reply