How is Ultrassembler so fast? (jghuff.com)

Neat, but it's not like assembly is really a bottleneck in any but the most extreme cases. LLVM and GAS are already very fast.

I feel like this might mostly be useful as a reference, because currently RISC-V assembly's specification is mostly "what do GCC/Clang do?"

Hi everyone, I'm the author of this article.

Feel free to ask me any questions to break the radio silence!

I wonder if you thought about perfect hashing instead of that comparison tree. Also, flex (as in flex and bison) can generate what amounts to trees like that, I believe. I haven't benchmarked it compared to a really careful explicit tree though.

Exceptions in C++ are never zero-overhead. There is a time-space tradeoff for performance of uncaught exceptions, and G++ picks space over time.

“Here's one weird trick I haven't seen anywhere else.” … describes a simplistic lexer. Hmm.

> Additionally, in C++, requesting that heap memory also requires a syscall every time the container geometrically changes size

That is not true - no allocator I know of (and certainly not the default glibc allocator) allocates memory in this way. It only does a syscall when it doesn’t have free userspace memory to hand out but it overallocates that memory and also reuses memory you’ve already freed.

Nice to have something really fast, maybe we can have something as good as TurboPascal and other early Borland tools again.

I also have to ask where all this assembly code is coming from, that has to be compiled fast. If it's compiler output, maybe you could hack the compiler back end to generate tokenized assembly code, eliminating a lot of scanning and stuff. It would still be human readable through a simple program that converted the tokens back to mnemonics. The tokens could be 4 digit hex numbers or something like that, so it would still be an easily handled text file.

Lots of simple compilers generate object code directly instead of assembly code, so the above is not so bad by comparison.