Rendered at 20:26:02 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
vzaliva 1 days ago [-]
I think it is fantastic to have more compiler implementations. It was probably also a fun project to code. What I find lacking in web pages is a motivation. What makes it different from popular compilers? Where is this project heading? What would be potential benefits/use-cases for using this compiler vs others, lessons learned, etc.?
LeFantome 14 hours ago [-]
> What I find lacking in web pages is a motivation
From those pages:
"The purpose of Kefir project is producing an independent C17/C23 compiler with
well-rounded architecture and well-defined scope that is feasible for implementation by a single developer."
He wants a third compiler to vet code portability. He wants it simple enough to build and maintain himself.
fuhsnn 18 hours ago [-]
I have found portability bugs in many projects with slimcc just because it exposed different preprocessor defines, some gate critical __attribute__ behind __GNUC__ check, some have buggy fallback to __builtin functions or VLA that nobody noticed in years, these could have been avoided with just an automatic build job in the CI with kefir or slimcc, (tcc is awesome but less suited for being a drop-in).
It is also important to have more independent implementations of the C standard, not only to sort out dark corners in the specification (current WG14 have been doing great), but to prevent it turning into GCC-Clang power struggle.
aktau 13 hours ago [-]
I remember when we still had tcc in Neovim CI. I think it got removed eventually for being too much of a burden to maintain.
How are slimcc/kefir different/easier to drop in?
fuhsnn 12 hours ago [-]
Can't speak for kefir; slimcc has been `make unittest`ing Neovim v0.10.4 with no source modification in a Debian VM (so it's pretty portable, thanks!)
On tcc, the most common dealbreaker is no thread local support, having independent assembler/linker is a wonderful feat but not being feature parity with binutils could lead to build failure, contributors generally less willing to support the correct behavior for ABI, C standards and GCC extensions.
I hope these don't sound like a diss, if I had been better at reading its coding style I would definitely try to contribute to mob branch.
aktau 11 hours ago [-]
Thanks for the notes. Different as/link is definitely a way for incompatibilities to creep in.
adamrt 1 days ago [-]
I agree on it being fantastic.
For your other questions I found these in the linked text
Those sections don't really provide details on the author's motivations to be honest
applfanboysbgon 23 hours ago [-]
I think they provide enough information to take a reasonable guess. It seems likely to me that the author is the type of programmer who prefers to understand what their code is doing, with as little magic involved as possible. Using other people's compilers is very magical, all kinds of transformations are being applied to the code you wrote and you are relying entirely on abstractions without really knowing how your code translates to controlling the hardware. Some people prefer to know exactly that.
sylware 11 hours ago [-]
[dead]
nine_k 1 days ago [-]
It's amazing how much one motivated person can achieve. Also, how competent the result seems to be. The test suite alone is pretty impressive.
edwcross 15 hours ago [-]
c-testsuite is not made by the author of Kefir.
fuhsnn 14 hours ago [-]
c-testsuite itself was curated from simple-cc and tinycc's test files, the latter originated from picoc.
degurechaff 10 hours ago [-]
c-testsuite is amazing. i use it to test my compiler, but even after passing the test. my compiler still choke on some real world project. also the tests lack many of arcane preprocessor rules. so you still need to read https://www.spinellis.gr/blog/20060626/ in order to understand hideset and its macro expansion algorithm.
fuhsnn 2 hours ago [-]
Yeah, to get arcane macro tricks right I probably spent more than a full month total fighting with linked lists, never want to touch that part again.
anta40 16 hours ago [-]
Very impressive for a single dev project.
Nice to see someone started the work from zero instead of piggybacking LLVM.
InfiniteRand 12 hours ago [-]
This is something that intrigues me:
"Is able to output internal representations (tokens, abstract syntax tree, intermediate representation) in machine-readable JSON form."
I'm not sure what I can do with that information but I wish I had an excuse to use it
sylware 11 hours ago [-]
You could use cproc/qbe, tinycc, scc, etc. The more real-like C compiler implementations the better.
fuhsnn 19 hours ago [-]
Congrats for the new optimizing pipeline, and thanks for the acknowledgment! It's nice to have company in the non-__GNUC__ camp.
From those pages:
"The purpose of Kefir project is producing an independent C17/C23 compiler with well-rounded architecture and well-defined scope that is feasible for implementation by a single developer."
He wants a third compiler to vet code portability. He wants it simple enough to build and maintain himself.
It is also important to have more independent implementations of the C standard, not only to sort out dark corners in the specification (current WG14 have been doing great), but to prevent it turning into GCC-Clang power struggle.
How are slimcc/kefir different/easier to drop in?
On tcc, the most common dealbreaker is no thread local support, having independent assembler/linker is a wonderful feat but not being feature parity with binutils could lead to build failure, contributors generally less willing to support the correct behavior for ABI, C standards and GCC extensions.
I hope these don't sound like a diss, if I had been better at reading its coding style I would definitely try to contribute to mob branch.
For your other questions I found these in the linked text
Nice to see someone started the work from zero instead of piggybacking LLVM.
I'm not sure what I can do with that information but I wish I had an excuse to use it