Kefir author here. Quite surprised to see it on HN. A few notes in response to Brian's post and comments:
- Kefir name is simply a reference to milk drink, no other connotation is intended. Updated project README with this information.
- The compiler is indeed quite primitive, especially, in terms of code generation. My main goal was implementing a C compiler that is reasonably compliant with language standard and platform ABIs, so I decided to simply ignore any performance considerations as I wouldn't compete with well-established compilers anyway.
Usage of threaded code is also caused by the same reason -- it is very simple to obtain assembly from intermediate representation when the assembly is mostly composed from references to runtime routines. Even without considering more sophisticated schemes of code generation, current approach is not optimal -- threaded code encoding scheme is very wasteful in terms of generated code (which was also noted in the blog post) and has awful runtime performance.
- I have tried to keep compiler compliant with the standard as well as compatible some of widespread C extensions (with some exceptions which I listed in README). Will try to address compilation errors found by Brian. Unfortunately, currently I do not have much time to work on the compiler. Identifying and fixing such bugs might also be quite tedious, so I expect that there are enough unnoticed compatibility problems there.
- Patches implementing OpenBSD support are appreciated. I plan to integrate those into the main code tree at some point.
bumping the author's chain and bluntly suggesting that others (like myself) without much/any stake in openBSD's C compilers should stfu with the name flaming now, because the fact that it's still continuing in replies at this point is more a matter of narcissism and disrespect for the submission than anything else.
Considering that the developer is saying "not for production" but the users are saying it works great in production, I'd say the comparison should be "unknown competence > unknown incompetence"
Ah, yes, love those, cobbled together embedded compilers. Not a word in the Release.Me about the quirks. Just a "STABLE!!!".
Like binary C-Operators will only work on the first 8 bits, the rest is up there and needs to be shifted in and out.. basically work it out yourselve, once it wont work.
Then explain to the manager, that his hot project tooling from the megacorp upstream was basically license-brokken copy pasted garbage from some hobbyist half way around the world). And get a no, when asking for at least posting the patches back.
Or the "Working feature" which is just some api header, going into a inlined binary blob returning some constant. Which is just some flytrap to get you to drive by develop it for them. Twelve angry part time devs, make up one full working project.
The only professional in some industries is looking at you every morning from the mirror, begging for a mercy killing.
not for the joke it isn't; i am not, in fact, thinking of the racial slur; we all have google (but not all of us will idly assume to know the etymology of a project's name based on this); semicolons are awful punctuation
Hey now, wait a minute. We can argue all day about kefir, kafir, and kaffir, but don't you impinge on the dignity of the semicolon just because the previous poster used one incorrectly.
I don’t think it’s an incorrect use of the semicolon. Semicolons are out of fashion these days, but using a semicolon to join two related clauses is perfectly fine, as far as semicolon usage goes.
Who said anything about "racial slur"s? In Urdu, one of the languages I speak, "kaffir" means "non-believer". Your suggestions 'mushrik' and 'neocon' seemed to fit pretty perfectly with that interpretation.
----
Aside: semicolons are pretty great once one learns to wield them. Try it; you'll like it. Just think of it as a shorter pause than a period, but longer than a comma.
the typical romanization of arabic كافر is "kafir". the typical spelling of the slur associated with apartheid-era south africa is "kaffir".
> one of the languages I speak
why would i care which languages you speak
you are not me
i am not you
neither of us are everyone else
>try it
perhaps instead of me doing any of that, you could simply stop arrogating reflexively in your internet comments and presuming to know the inner contents of others' minds (you do not)
>semicolons
the purpose of your original reply was to condescend in typical nerdsplaining fashion. the reason my reply to you, in turn, was written like it was, including the side mention of semicolons, was to escalate abruptly and unambiguously, such that there was no ambiguity as to what i thought of the situation. i was expressing contempt. it's merely a circumstantial convenience that semicolons do happen to be dogshit punctuation used as epistemic crutch notation in prose
Thanks for this. I don't know anything about compilers, but I really enjoyed reading this. Besides the technical insights it provided, I also loved the positive attitude of this article. Two excerpts that stood out for me:
> [...] if the code kefir produces is correct, then it is amazing that one person was able to create a complete C17 compiler and that fact should be celebrated.
> I'll admit this is not something I would have thought of but it appears to work just fine.
chibicc is great and also a very useful tool to do different kinds of C source code analysis and processing, such as https://github.com/rochus-keller/c2obx/
That looks like a very useful C library, thanks for the hint; as it seems it is much more than just a standard C library in that there are also threads, unicode and a lot (all?) of posix features; I do not have the full grasp yet, but it seems that I could use it as a runtime library for my Oberon+ language (which has a built-in FFI and can also transpile to C).
Is it just me, or is the first time that "OpenBSD" and "New" were in the same sentence? I love OpenBSD, but in fairness, its biggest virtue is usually its rock solid stability and security, derived from everything in it generally being long battle tested before ever going into OpenBSD. The idea of bleeding edge C compilers seems a bit strange, given that reputation.
The "new" in the headline refers to these compilers being newly ported to OpenBSD. OpenBSD also sometimes gets new features, sees new releases, etc. There's nothing weird about seeing "new" and "OpenBSD" in the same headline.
I would say that for a lot of daemons OpenBSD ends up with more interesting and cleaner versions than some of the ancient BSD ilk or with some of the complexity of the GNU replacements. It's often a lot easier to port part of/some of an OpenBSD daemon with just a little bit of hacking around instead of figuring out a bigger autotools chain.
The default install is stable and secure; the ports tree is much less so. People experimenting with things on their personal workstations is a complete free-for-all.
Thanks to the author for oksh (portable OpenBSD ksh). It is a pleasant alternative to Bash on Linux. 288KB vs 1.3MB. Wonder if oksh will compile on mips74Kc. I started to do something similar for NetBSD ash, for personal use only. Dash and busybox are OK, but I want both fc and command line history.
One of my main complaints about the BSDs is that they include the entire source trees for LLVM/clang and GCC. It seems like it's the only way for them to maintain the two golden BSD rules: "You shall have in your codebase everything needed to build a complete BSD system" and "You shall run on at least 30 or 40 different CPU architectures". I wish git submodules were more modular(!), so I could clone OpenBSD and LLVM/gcc would be an replaceable submodule, and instead drop in something like smallc.
- Kefir name is simply a reference to milk drink, no other connotation is intended. Updated project README with this information.
- The compiler is indeed quite primitive, especially, in terms of code generation. My main goal was implementing a C compiler that is reasonably compliant with language standard and platform ABIs, so I decided to simply ignore any performance considerations as I wouldn't compete with well-established compilers anyway.
Usage of threaded code is also caused by the same reason -- it is very simple to obtain assembly from intermediate representation when the assembly is mostly composed from references to runtime routines. Even without considering more sophisticated schemes of code generation, current approach is not optimal -- threaded code encoding scheme is very wasteful in terms of generated code (which was also noted in the blog post) and has awful runtime performance.
- I have tried to keep compiler compliant with the standard as well as compatible some of widespread C extensions (with some exceptions which I listed in README). Will try to address compilation errors found by Brian. Unfortunately, currently I do not have much time to work on the compiler. Identifying and fixing such bugs might also be quite tedious, so I expect that there are enough unnoticed compatibility problems there.
- Patches implementing OpenBSD support are appreciated. I plan to integrate those into the main code tree at some point.