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.

Thanks. LCC is only for 32 bit x86 (unless something changed very recently). And a Windows compiler doesn't help me. :-) Arnold Luther Johnson <luther.johnson(a)makerlisp.com> wrote:

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)

Besides which x86 or other machine models you want, and how much of which sort of optimization is enough, the other challenge is which C language variant, exactly, you want. Simple C compilers that do one thing well, often, well, do just one of these things. On 05/25/2025 04:46 PM, Bakul Shah via TUHS wrote:

Bakul Shah via TUHS <tuhs(a)tuhs.org> wrote: On Ubuntu 24.0, neither of these gets through gawk's configure script, although they both compile hello world. Sigh. Thanks for the pointers though. Arnold

"Roberto E. Vargas Caballero" <k0ga(a)shike2.net> wrote: Much thanks. Feel free to contact me off list. scc tried to use its own libc, instead of the standard one, so things wouldn't link. In any case, let's continue off list if needed. Arnold

Thanks. My mirror of the CVS repo was last updated on Mon Oct 30 06:14:56 2023 +0200. That's a bit ahead of the other. But I did not attempt to import the CVS repository. Rather, ~ 2016, I imported what current into Git and then went from there. What I have has a bug and won't compile gawk anymore. :-( (https://github.com/arnoldrobbins/pcc-revived, if anyone cares.) Thanks, Arnold "Greg A. Woods" <woods(a)robohack.ca> wrote:

"Greg A. Woods" <woods(a)robohack.ca> wrote: It all depends upon what you want / need, doesn't it? I just want the compiler to be working again for my code. It used to, but the most recent code base doesn't. I have enough history that I was even able to identify the diff where it broke --- a rather large one. But I don't have the cycles or interest in trying to fix it myself. Arnold

I have https://github.com/johnsonjh/pcc-revived which is a fork but it includes that and has some local changes/fixes of mine in a branch. -- Jeffrey H. Johnson trnsz(a)pobox.com On Sun, May 25, 2025, at 3:51 AM, arnold(a)skeeve.com wrote: