I like the spirit of this article, but I find it strange that they open their article by quoting me, but then don't include Dusk OS's C compiler in the list.

Fairly counting SLOC is a tricky problem, but my count is 1119 lines of code for the C compiler (written in Forth of course), that's less than 8x the count of chibicc, described as the smallest.

▲

fallat a day ago | parent | next [-]

(typing from phone) i simply had not known. it is a great example of a short path to a c dialect then! merci pour votre travaille au dusk et collapse! i will add a paragraph about it to the essay. this took me many days to write and many revisions and still i see it isnt perfect!

note the point of that section was really that anyone using gcc or clang should ack. the real cost when using them.

▲

kragen a day ago | parent | prev | next [-]

That's a good point, thanks. How complete is it?

▲

entaloneralie a day ago | parent | next [-]

It's complete in sofar as being capable of compiling C programs, but it has a few quirks.

https://git.sr.ht/~vdupras/duskos/tree/master/item/fs/doc/co...

▲

kragen a day ago | parent | next [-]

Possibly this is why it wasn't mentioned? There are enough differences in that list that I can't imagine any existing C library would compile unchanged.

	▲	entaloneralie a day ago \| parent [-]
		After using cc<< for non-trivial programs, it's about as quirky as the Plan 9 C compiler, the lack of multi-dimensional arrays is the one thing that trips me up the most with cc<<

▲

NooneAtAll3 a day ago | parent | prev [-]

> The "&&", "||" and "?:" operators do shortcutting.

is shortcutting different from short circuiting?

	▲	vdupras a day ago \| parent [-]
		It's the same thing, I used the wrong term.

▲

norir a day ago | parent | prev | next [-]

From what I can tell chibicc, unlike tcc, is not a complete c compiler in and of itself. Looking at its source code, it relies upon external tools for both x86_64 code gen and linking: https://github.com/rui314/chibicc/blob/90d1f7f199cc55b13c7fd...

▲

fuhsnn a day ago | parent [-]

It does rely on binutils, but by this standard GCC is not a complete C compiler either.

	▲	kragen 15 hours ago \| parent [-]
		Relying on binutils and an assembler is fine. I don't think it really affects the internal complexity of the compiler much, but having textual assembly to look at can be handy for debugging the compiler, so it might reduce the human effort to get it working.

▲

vdupras a day ago | parent | prev [-]

By design, it's not a fully compliant ANSI C compiler, so it's never going to be complete, but it's complete enough to, for example, successfully compile Plan 9's driver for the Raspberry Pi USB controller with a minimal porting effort.

So, Dusk's compiler is not apple-to-apple comparable to the other, but comparable enough to give a ballpark idea that its code density compares very, very favorably.

▲

kragen a day ago | parent [-]

It can be hard to tell how much extra complexity would be introduced by unimplemented features.

▲

vdupras a day ago | parent [-]

Indeed, and it might be why the author didn't try, but I still find it odd to not at least mention how small this C compiler is, even if it is to say that it's not apples-to-apples comparable. I mean, 8x smaller than the smallest C compiler listed is still something notable...

	▲	kragen a day ago \| parent [-]
		It certainly sounds like a perfectly usable C dialect.

▲

entaloneralie a day ago | parent | prev [-]

Came here to say exactly that, cc<< blows these numbers out of the water. Strange choice from the author.