fuhsnn (u/fuhsnn) - Readit News

fuhsnn commented on Linear scan register allocation on SSA bernsteinbear.com/blog/li... · Posted by u/surprisetalk

o11c · 5 days ago

> In fact, you might even consider not allocating a register greedily. What might that look like? I have no idea.

One case I'm aware of: if your ISA supports arbitrary memory operands like x86, rarely-used variables can be operated-on entirely on the stack. Historically this was something ICC did better than GCC, though it became much less relevant with the shift to 64-bit bringing more registers.

fuhsnn · 4 days ago

x86 memory operands are also nice for binary size, my amateur compiler sometimes produces smaller objects than peers despite having no load-store elimination, all by greedily opting for memory operands during instruction selection; kinda amusing 'cause I'm now worrying my future optimization backend might actually cause a regression in size.

fuhsnn commented on Comparison of different C libraries providing generic containers capabilities github.com/P-p-H-d/c-stl-... · Posted by u/lemper

mananaysiempre · 8 days ago

The first two should be fixable by invoking make WCFLAGS_GCC= and make LDFLAGS= respectively.

(An assignment like FOO=bar in the makefile is a default[1], overridable by passing FOO=baz as one of the arguments to make. FOO?=bar can additionally be overridden by setting FOO to a different value in the environment.)

[1] https://www.gnu.org/software/make/manual/html_node/Overridin...

fuhsnn · 8 days ago

Thanks for the tips! Yes it can always be worked around, however the intuition I developed from doing it for over a hundred of projects [1] is that, with script like that there usually would be more compiler assumptions in C code as well, then I just move on to other projects.

(And it also feels awkward whether to report portability issues to projects with such script because it's like a clear "not for other compilers" message, similar to projects that adopted Meson)

[1] https://github.com/fuhsnn/slimcc/blob/94dde1b8080e02b188ea89...

fuhsnn commented on Linear scan register allocation on SSA bernsteinbear.com/blog/li... · Posted by u/surprisetalk

fuhsnn · 8 days ago

Another great overview of Go compiler's register allocation: https://developers.redhat.com/articles/2024/09/24/go-compile...

fuhsnn commented on Comparison of different C libraries providing generic containers capabilities github.com/P-p-H-d/c-stl-... · Posted by u/lemper

fuhsnn · 8 days ago

I'd love to have some of these libraries in slimcc's test pool, but almost every one of them have hard-coded assumptions to gcc/clang/msvc/tcc in their scripts that are tiresome to undo. For example:

MLIB: assumed GCC https://github.com/P-p-H-d/mlib/blob/4b9c213831624486814a483...

STC: assumed -fopenmp https://github.com/stclib/STC/blob/de7313a58f748d9a6da751eb9...

CC: assumed clang https://github.com/JacksonAllan/CC/blob/main/tests/run_unit_...

fuhsnn commented on Generic Containers in C: Safe Division Using Maybe uecker.codeberg.page/2025... · Posted by u/uecker

throw-qqqqq · 14 days ago

You don’t always get to choose your language. Especially in the embedded/firmware area of software development, C is the most widely available option, if not the only option besides ASM shrugs

fuhsnn · 14 days ago

The said library is a bit farther away from the C that is widely available. It relies on C23 features, GNU statement expression, GNU nested function, sanitizer runtimes, VLA types and a very niche pattern of sizeof executing its statement-expression argument; only platforms that provide latest GCC/Clang would be able to use this.

fuhsnn commented on Jank is C++ jank-lang.org/blog/2025-0... · Posted by u/Jeaye

caim · a month ago

Just parsing C++ is already a freaking hell.

It's no wonder that every other day a new mini C compiler drops in, while no one even attempts to parse C++.

fuhsnn · a month ago

There is one pretty serious C++ parser project: https://github.com/robertoraggi/cplusplus

fuhsnn commented on Tree Borrows plf.inf.ethz.ch/research/... · Posted by u/zdw

fuhsnn · 2 months ago

I wonder if Rust or future PL would evolve into allowing multiple borrow checker implementations with varying characteristics (compile speed, runtime speed, algorithm flexibility, etc.) that projects can choose from.

fuhsnn commented on I write type-safe generic data structures in C danielchasehooper.com/pos... · Posted by u/todsacerdoti

el_pollo_diablo · 2 months ago

None, but that is not my point. Before C23, fn() already meant the same thing as fn(void) in function definitions, which the situation under discussion here.

C23 changed what fn() means outside a function definition.

fuhsnn · 2 months ago

Oh, yeah, the codegen for the fn() itself would likely be the same, but the prototype of that definition is still a K&R function. https://godbolt.org/z/Psvae55Pr

fuhsnn commented on I write type-safe generic data structures in C danielchasehooper.com/pos... · Posted by u/todsacerdoti

el_pollo_diablo · 2 months ago

C23 does not change anything in this situation, because we are talking about the definition of main(), not a forward declaration. More details here:

https://news.ycombinator.com/item?id=38729278#38732366

fuhsnn · 2 months ago

In what situation fn() doesn't mean fn(void) under C23?

fuhsnn commented on Parameterized types in C using the new tag compatibility rule nullprogram.com/blog/2025... · Posted by u/ingve

cb321 · 2 months ago

While long-def's might be nice, you can even back in ANSI C 89 get rid of the backslash pattern (or need to cc -E and run through GNU indent/whatever) by "flipping the script" and defining whole files "parameterized" by their macro environment like https://github.com/c-blake/bst or https://github.com/glouw/ctl/

Add a namespacing macro and you have a whole generics system, unlike that in TFA.

So, it might add more value to have the C std add an `#include "file.c" name1=val1 name2=val2` preprocessor syntax where name1, name2 would be on a "stack" and be popped after processing the file. This would let you do types/functions/whatever "generic modules" with manual instantiation which kind of fits with C (manual management of memory, bounds checking, etc.) but preprocessor-assisted "macro scoping" for nested generics. Perhaps an idea to play with in your slimcc fork?

fuhsnn · 2 months ago

> `#include "file.c" name1=val1 name2=val2`

That's an interesting idea! I think D or Zig's C header importer had similar syntax, I'm definitely gonna do it.