Comment by raphlinus | Hacker News Reader

Comment by raphlinus | Hacker News Reader

I notice that assembly language is not on this list. I've been working on a modern syntax for assembler, with C-like types[0], something of a successor to qhasm. I've written a race-the-beam renderer[1], which is a good fit because of its incredibly tight performance constraints. I've been doing a combination of coding by hand and Opus 5.5. Anecdotally, I find Claude can code in it just fine, something I'd like to make more quantitative.

Dan Luu has done that kind of evaluation[2], and found that LLMs do well in a range of languages, but do underperform in assembler. My hypothesis is that expressing programmer intent clearly, and having the compiler verify things like consistent placement of variables in registers, will fix the problems that hold LLMs back.

This has been a hobby project, but it feels ready to break containment. I'm open to a research opportunity where I'd be able to work on it for real - get in touch.

[0]: https://github.com/raphlinus/symbolasm

[1]: https://github.com/raphlinus/vic-2350

[2]: https://danluu.com/pl-tokens/

This "symbolasm" looks exactly like what Blackfin did.

I think it's a very promising approach - it makes assembly a lot more intuitive, especially to people with background in higher level languages. It makes listings far more immediately readable, even without memorizing every instruction mnemonic. But it just came in too late. By the time Blackfin happened, coding in assembly was firmly an afterthought.

I'd like it to succeed, but I have my doubts that it will.

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.

> time is a circle

Or it is a self-similar fractal with significant and interesting variations

It is an appealing target for LLMs? Well, LLMs do make "handroll your hot paths in assembly for better performance" much more viable.

But that's a bit of a problem too?

Because, unlike humans, LLMs have no trouble whatsoever recalling all the mnemonics. Hell, they can often recall all the opcodes and encodings too and disassemble from hex "manually".

So if the primary advantage of this syntax is better human-readability and human-understandability? The need for it in a future where low level assembly routines are written by LLMs in a perf evaluation loop isn't that great.

For those who might wonder, Blackfin is a CPU architecture with an assembly language thas has a more pseudo-codeish syntax [1]:

    R0 = R1 + R2

[1]: https://en.wikipedia.org/wiki/Blackfin#Core_features

Check out Wiz too: https://github.com/wiz-lang/wiz

People have ported Atari 2600 games to it with the resulting ROM being byte-exact.

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.

Also check out: https://github.com/catseye/SixtyPical

Assembly with an effect system and flow typing.

Until recently leaving, somebody at Nvidia was working on a really cool PTX assembler with a pleasant syntax that had support for generic routines and types. I'm a bit sad that's seemingly abandoned now.

Symbolasm looks interesting. Without having tried it, the first thing that comes to my mind is that it would be a bit more complex for debugging, because you are using two different representations to do the same thing (one for writing code, one for reading it back). Not sure if this is an issue in practice.

Of course, the same issue exist in any compile language, say C, but you don’t expect to see C in a disassembly. Here you are working at the assembly level.

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!

Reply on news.ycombinator.com