fuhsnn

6 ms·

31.
by fuhsnn 8mo ago
Intel's next gen will add 16 more general purpose registers. Can't wait for the benchmarks.
32.
by fuhsnn 8mo ago
They definitely have access to the source code, look at the binutils entry [1], Claude was debugging compilation of "preprocessor #define inside #ifdef"'s in binutils's code. [1] https://github.com/anthro
33.
by fuhsnn 8mo ago
Didn't see people mention this in the initial discussion, but despite not having access to internet, the agents actually had access to the source code of GNU binutils (has assembler, linker and readelf), and many C compilers (SDCC, PCC
34.
by fuhsnn 8mo ago
FIl-C, the new memory-safe C/C++ compiler actually achieved that through introducing a GC, with that in mind I'd say D was kind of a misunderstood prodigy in retrospect.
35.
by fuhsnn 8mo ago
Maybe the strategy from TCC itself is useful here: emit case bodies as a giant block first then jump back with cascaded if's at end. https://godbolt.org/z/TdE11jjxb > Did you know that C has a keyword that is o
36.
by fuhsnn 9mo ago
- Non-capturing isn't that much simpler to implement for the front-end, because they still need to distinguish between a file-scope name or a shadowing local in parent function. And once you have the code to do that distinction, it&#x2
37.
by fuhsnn 9mo ago
I did a version with explicit capture objects for fun: https://github.com/fuhsnn/c-extensions#extended-capture Basically, with each capturing lambda, a context type _Ctxof(fn) is created that users can then declare on
38.
by fuhsnn 10mo ago
Looking forward to the release! What I found troublesome were not really the caching of array count, but when and where should the side effect be represented in AST, for example this one: https://godbolt.org/z/rcT1d8WWe
39.
by fuhsnn 10mo ago
This one[1] is similar in style and supports a bit more C constructs. [1] https://github.com/Lulzx/sectorc/blob/master/stage5/cc.c
40.
by fuhsnn 10mo ago
I would love to see how you handle variably-modified types, the way I retrofitted them onto chibicc never felt quite right, and I've never seen another non-gcc/clang compiler fully support noplate's VM type patterns.
41.
by fuhsnn 10mo ago
Not until we discover the hidden code in their logs, scheming on destroying humanity.
42.
by fuhsnn 10mo ago
It does rely on binutils, but by this standard GCC is not a complete C compiler either.
43.
by fuhsnn 10mo ago
> Heap-allocated trampolines have an obvious deallocation problem; it would be interesting to see what strategy is used for that. With -ftrampoline-impl=heap, GCC automatically insert[1] pairs of constructor/destructor routines from
44.
by fuhsnn 10mo ago
I dreamed up a similar idea[1] upon reading the author's closure proposal, it's also really close to async coroutines. [1] https://github.com/ThePhD/future_cxx/issues/55#issuecomment-...
45.
by fuhsnn 10mo ago
IMO the C way is to allow users to explicitly manage context area, along the lines of posix ucontext.h or how the author's closure proposal handle closure allocation[1]. [1] https://thephd.dev/_vendor/future_cxx&#x
46.
by fuhsnn 10mo ago
Honestly as a hobbyist programmer I'm more interested in knowing which exact platforms/compilers that don't support the non-dependable patterns and why should I care about them. Even better if the author can host a list of &q
47.
by fuhsnn 10mo ago
Clang is working on a different version with annotations https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3656.pdf
48.
by fuhsnn 11mo ago
TinyCC supports cleanup[1], onramp[2] supports C2y defer (which is a superset), slimcc[3] supports both. [1] https://godbolt.org/z/hvj9vcncG [2] https://github.com/ludocode/onramp [3] https:&#x2F
49.
by fuhsnn 11mo ago
Also clang's https://clang.llvm.org/docs/AttributeReference.html
50.
by fuhsnn 11mo ago
> C23 gave us [[cleanup]] attributes C23 didn't introduce it, it's still a GCC extension that needs to be spelled as [[gnu::cleanup()]] https://godbolt.org/z/Gsz9hs7TE
51.
by fuhsnn 11mo ago
> though some may feel the wrong way around Microsoft C behavior being permitted The same extension can be enabled with `-fplan9-extensions`, might be more appealing to some!
52.
by fuhsnn 11mo ago
Examples from this article[1] frequently yield inconsistent result across implementations, particularly the ones that put parenthesis in macros, it is indeed a very corner-case-y thing to do though. [1] https://www.scs.stanford.e
53.
by fuhsnn 11mo ago
I played with a lot of preprocessor implementations and did my own (redesigned chibicc's expansion algorithm), not many of them even have paint-blue behavior exactly right (the standard text is vague, to me it was more "matching G
54.
by fuhsnn 11mo ago
I wonder if the author is aware of the __VA_TAIL__ proposal[1], it covered similar grounds and IMO very well thought out, but unfortunately not accepted into C2Y (judging from committee meeting minutes). [1] https://www.open-std.
55.
by fuhsnn 11mo ago
Interested in why you consider Zig's precompiled WASM blob full source bootstrapping, is it because it's shipped by first party?
56.
by fuhsnn 1y ago
The tree-like syntax interested me but unless this new layer enforces it, there's no guaranteed evaluation order among its backends[1], which IMO kind of defeat it's usability as general purpose IR. [1] https://github.c
57.
by fuhsnn 1y ago
I believe Mesa's llvmpipe backend can do that to a degree, never tried, though.
58.
by fuhsnn 1y ago
There is current interest in adding __VA_COUNT__ https://github.com/llvm/llvm-project/issues/155234 The __VA_TAIL__ proposal might simplify the map macros (as well as expanding more efficiently) https:/
59.
by fuhsnn 1y ago
It's been implemented in GCC(in review)[1], onramp[2] and my own slimcc[3]! [1] https://patchwork.ozlabs.org/project/gcc/list/?series=470822 [2] https://github.com/ludocode/onramp [
60.
by fuhsnn 1y ago
You didn't make the tasks difficult, you make them easier. The entire coreutils is reduced to one utility (sha1sum) and the test doesn't even try to feed a real file to it (just a stdin string)[0], same goes to the jq task, there

More ›