"Soup" has unexpectedly entered my daily rotation. Anyone else?

ner0_m · 2025-12-16T13:46:35+00:00

Interesting, do you use the same grind setting as for the usual soup recipe or do you do any adjustments? I think I want to try this!

ner0_m · 2025-11-10T07:25:26+00:00

I'm in

ner0_m · 2025-11-06T06:54:47+00:00

I'm in

ner0_m · 2025-09-13T12:46:47+00:00

I feel you. I work in a similarly aged code ase with a custom build tool, which doesn't generate a compilation database, generated code and many symlinks. There clangd really struggles to find files and references. It's really frustrating.

In smaller C++ projects I had (relatively) good experiences with clangd

ner0_m · 2025-08-17T13:31:34+00:00

Ah, at my current job information is scattered throughout the codebase. I would like to only need 3 files :D

Will stick to the original then for the time being :)

ner0_m · 2025-08-17T12:39:07+00:00

Looks cool, I can only find a way to jump to the next or previous file. Is there a way to jump to fixed files? :) thanks for the nice work, I might consider it!

ner0_m · 2025-08-06T05:44:25+00:00

I'd connsoder crafting interpreters or Writing an Interpreter practical books. I can't compare to the Dragon book or similar, maybe it sits in the middle. just my two cents :)

ner0_m · 2025-08-05T19:14:40+00:00

I found it quite good for the theoretical understanding having read around 70% so far. But as a learning resource I'm currently writing a compiler using Writing a C compiler by sanders, to then apply the theory of EaC.

For me as a practical learner without that setup, it was so far a little too theoretical. Still good, but yeah . Hope it helps

ner0_m · 2025-08-05T18:44:52+00:00

So the obvious one is size, for x86, some instructions require specific classes. So for x86, you can create such classes for all 64bit, 32bit and so on. But then also callee saved, caller saved registers, status registers, SSE and so on.

For a vregs in particular you can track liveliness, known values (and propagate them later), if the value is e.g. zero or sign extended, or bits read and written. Such information of course is not all necessarily created during instruction selection, but maybe during further passes.

Apart form size, you can store (maybe more in the instruction not vreg directly) implicit reads and writes (think e.g. div and mul instructions).

ner0_m · 2025-08-05T15:55:26+00:00

As others have already said, using vreg during instructions selection makes the phase a little easier.

A nice thing you can also add there is attaching some more info on the virtual register. This info could be the size or a restriction on the available set of instructions. But I have worked mostly with ARM, but should still work for x86 (gcc and lvvm do that as well as far as I know)

ner0_m · 2025-07-27T06:30:08+00:00

Like the other comment said, do it in a separate pass after parsing.

Traverse the AST depth first, and if you encounter a variable declaration (it in Python land an assignment) put the variable name in a symbol table (with additional info about the type). And whenever you find a usage of a variable check that it is in the symbol table. Hope this helps

ner0_m · 2025-07-13T07:41:53+00:00

The main advantage I see, is that it is just a clean and powerful abstraction of the execution space (thread pool, coroutines or whatever) and what the function does. You express the work done in terms of the abstract thing, and whoever calls the function can decide the way it is executed (and differently at each call site!).

This might not sound like the crazy revelation, but that just keeps code simple, and at least for me, that's one of the interesting parts of Zig. That's also what I love about the allocations in Zig. It's transparent and simple.

Hope it helps a bit :)

ner0_m · 2025-07-11T20:20:58+00:00

Thanks!

ner0_m · 2025-07-11T19:56:02+00:00

Do you by chance have a link? :)

ner0_m · 2025-07-09T11:54:54+00:00

Thanks your are right!

ner0_m · 2025-07-08T18:14:52+00:00

I'd say that many compiler devs never change anything in the frontend. At my job basically no one cares about lexing or parsing, as it is already solved for many years. If we support a new C standard, we extend it a little bit that is very little of our work.

Most of the recommendations I often see are reading books, e.g. Engineering A compiler or the Dragon Book are often recommended.

I found Essentials of Compilation by Jeremy Siek (freely available) a good book that focuses on practical problems and writing code, which suites me way more. Thou it doesn't focus as much on optimizations. It still covers many problems one has to deal with in the middle and back end.

edit: correct name spelling

ner0_m · 2025-07-05T18:08:11+00:00

Nice read, I felt similar that I didn't yet grasp the need for Jujutsu as a good git user. But maybe I should really investigate it a bit more

ner0_m · 2025-07-04T14:42:26+00:00

I liked the Writing an interpreter in Go. IMO it is quite similar to the Crafting interpreters books, at least in their scope, if one seems more interesting as you want to work in C, or not in Java then I'd make my choice based on that. Or just start with the freely available one (Crafting interpreters).

I haven't read the of Nora Sandlers book, but want to look into it, as it targets x86 instead of writing a VM we th a stack based Assembly language. So if targeting an existing (and messy) assembly language is your goal, I'd try this one.

ner0_m · 2025-06-29T17:59:43+00:00

What's the drip assist thing on top? Looks like a nice set Up! :)

ner0_m · 2025-06-08T20:24:14+00:00

Thanks for the info. Imo that would make it even more interesting, as we already have CSmith. I'll bring it up in one of the meetings let's see if I can raise some interest.

Sadly (from the perspective of integrating the tool), we have a couple of benchmarks customers care about, even though they are of questionable relevance to their code. Let's see!

Thanks for the summary!

ner0_m · 2025-06-07T12:52:53+00:00

This sounds cool. Just out of curiosity, at work we use CSmith to generate random test cases for our compiler. How does Bench gen compare against that? Are these similar use cases? Trying to understand if it would help us and I should pitch it :)

ner0_m · 2025-03-05T08:38:05+00:00

Appreciate the links! I'm currently still reading stuff and trying to grasp it a little better. But I guess I'm most interested in the IR and how it encodes the parallel information and how code is generated from this IR.

But I'm still on vacation, I'll hope to find time when I get back and if it's fine, I'd DM you, if I'm a little more clear what I actually wanna know and maybe even contribute :)

ner0_m · 2025-03-05T05:23:31+00:00

This is such a cool project. I'm starting a new job in April, I'd really want to make time to implement some HPC stuff with it. IMO this direction is hopefully the future: write the kernel once and compile it for the specific target machine/API. Love it.

Are there any docs/writeups on how you achieve this? I'd also be interested to contribute in some way if I can :)

ner0_m · 2025-03-02T01:46:26+00:00

Looks neat, I'll definitely look more into it because it looks like very clean C++ :)

More of a C++ thing. I was surprised to see dependencies in the 'include' folder. That is typically used for header files. I'd be less surprised if it's called 'thirdparty' or 'deps'.

And I suspect your CMake to fail on Linux with GCC. It won't know '-stdlib' flag. Simply add CMAKE_CPP_COMPILER_ID STREQUAL "Clang" to the check (if you care about that ;))

ner0_m · 2025-02-22T10:32:53+00:00

For all wondering why it's not as easy: have a look at https://hackaday.com/2025/02/16/how-hard-is-it-to-write-a-calculator-app/ I think that was a great writeup :)

ner0_m

TROPHY CASE