Steffen Nurpmeso wrote in <20250523121039.lH0RzUyf(a)steffen%sdaoden.eu>: |Aharon Robbins wrote in | <E1uIQYa-0000000168u-0s7X(a)gleep.local>: ... |[.] That we lost [.] | it, and are left with only gigabyte monsters that |go universes beyond Ken Thompson's "reasonable optimizations" Brian Kernighan should this have been (quoting Plan9 compiler manual page unless i am mistaken). --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)

On Fri, May 23, 2025 at 8:56 AM Steve Nickolas <usotsuki(a)buric.co> wrote: Well, there's https://github.com/rui314/chibicc, which is pretty small and seems decent (caveat that I haven't used it, though). - Dadn C.

Steve Nickolas wrote in <alpine.DEB.2.21.2505230843170.7423(a)sd-119843.dedibox.fr>: |On Fri, 23 May 2025, Steffen Nurpmeso wrote: |> It is *such* a pity! I said similar sad words just two days ago |> when shortly touching linux-man@. That we lost (i only track your |> git mirror of) it, and are left with only gigabyte monsters that |> go universes beyond Ken Thompson's "reasonable optimizations" |> (iirc), and tcc (luckily this we have). Here the built gcc ball |> is 243 times larger than tcc's, and clang is 284 times larger |> even! | |I wish I had any idea what I was doing when it came to language |interpreters and compilers... These swiss-army-nukes epitomize "no kill |like overkill", but I prefer small, single-purpose tools. | |A new lightweight C compiler with a focus on various varieties of x86 is |something I think would be useful and would do if I had any idea how to go |about it. I never did a C compiler myself. It .. you know, i read Knuth's TeXbook i think there it is, and, if i recall this correctly (~25 years), there is a homework item "write an operating system". I think this is hm spiritually interesting, in that you do not have that many opportunities really. Some people get mortally ill, survive it, and things changed. Maybe something other horrible like the "famous" crash [1] make you turn around. Maybe an operating system is an easy thing for homework when you are 18 (even more so around Y2K, *possibly*), but for an elder it is clear that things turn out to be more complicated than thought first. (In that spirit one may also remember Tso's narrative on Ext* and BTRFS as seen on this list. And i think this very topic here was also on the table already.) There is also neatcc by Iranian human Ali Gholami Rudi[2] that i never really used myself: It supports a large subset of ANSI C but lacks some of its features, the most important of which are struct bitfields, inline assembly, and floating point types. But the thing with pcc, beside its very long history, is that it is an optimizing compiler that compiles pretty fast. And it also produced warnings pretty well. The entire git repo is 2.3MB. This is even smaller than tcc's, which is even faster, but does not optimize at all. Compile speed during development matters for me. It is not as bad as say 20 years ago, i now have four cores and lots of RAM, and NVME (that I/O performance makes me happy over and over again, it was unthinkable in the past). [1] https://www.corvetteforum.com/articles/corvette-z06-owner-survives-horrific… [2] https://github.com/aligrudi/neatcc So for me, whereas i wish i would have more time for programming, it surely would not be a compiler, but more MUA and roff. The thing is also, you know, that the language development really distracts me more and more. This is not "my C" anymore, and it long is not the C++ i spent so much time in. (It never was the way i would loved to have, but creating an entire language environment is even more impossible; like QT, a preprocessor maybe, but ... then not.) And perl obsoleted goto at times. Ie, i was informed on the linux-man thing i mentioned that C may get forward declarations for parameters (see [3]), like so: size_t mbrtowc(size_t n; wchar_t *restrict pwc, const char s[restrict n], size_t n, mbstate_t *restrict ps); whereas i am used to size_t mbrtowc(wchar_t *restrict pwc, const char *restrict s, size_t n, mbstate_t *restrict ps); though in fact scratch that "restrict" that i never used and dislike. Or that i have to turn to memmove more and more because memcpy now "asserts" any overlap, regardless of the direction, and regardless the fact that memory utility implementations of memmove simply start at the end instead of the begin on overlap. Regardless of non-temporal moves, and whatever hardware optimization there is. Because there is no language-side possibility to express the situation, you have to use the library function memmove not memcpy, for nothing. And more such. Whatever, and all off-topic. [3] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3433.pdf --End of <alpine.DEB.2.21.2505230843170.7423(a)sd-119843.dedibox.fr> --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)

At Fri, 23 May 2025 14:39:03 +0200, Arno Griffioen via TUHS <tuhs(a)tuhs.org> wrote: Subject: [TUHS] Re: Off topic: Does anyone know what's going on with the PCC Revived project? In recent (March 26) private email Anders told me that indeed the CVS repository went unreachable because the machine it was hosted on was shut down. He said he has a plan to move it to https://github.com/PortableCC and that there are some pending fixes for it but that he hasn't had time to make the move yet. I asked him about the Git import at https://github.com/didickman/pcc and he said that looks like a good version to reference for now. That repository seems to me to be a faithful conversion of the original CVS repository. It has a DATESTAMP of 20230830 (which is ~7.5 years ahead of the version that was imported into, and is still in, the NetBSD source tree). -- Greg A. Woods <gwoods(a)acm.org> Kelowna, BC +1 250 762-7675 RoboHack <woods(a)robohack.ca> Planix, Inc. <woods(a)planix.com> Avoncote Farms <woods(a)avoncote.ca>