17 comments
@rml i don't know about the rest but GCC's codebase is obscenely large. It's insane. It's still kind of easier to read than badly written smaller projects :) @ekaitz_zarraga yeah, I started diggin in when I was considering getting involved in #gccrust, but dear lord is it gnarly. I think thats where the gn- may actually originate. @rml I am backporting gcc 4.6 to RISCV. I managed to make it output RV binaries but there's still work to do... It was way easier than I thought it would be. But it was still difficult :) bootstraps itself in less than a minute. produces statically linked binaries. makes up the core foundation of many of todays most innovative programming languages, and everyone who uses it has a blast. but yeah I guess working with heavy duty infrastructure that can't feasibly be forked has its merits. not that chez would be particularly easy to maintain, but I already spend a good deal of free time studying the source just because its one of the coolest code bases I've ever seen (much like guix, except a totally different philosophy), and i'm eager to learn the concepts. I'll take a 70k LoC over a million+ any day. I am currently using Mecrisp Forth on a STM32WLE5 (64kB RAM, 256kB Flash) target. Compiler (to machine code) built-in and running on target, has a disassembler on target. REPL-over-serialport on target. All in ~40-50kB of the Flash. FreeRTOS + LoraWAN stack in C occupies ~130-140kB of Flash. Back in the days; GEM was a Windowing system running in 1MB RAM computers. Nowadays, few websites are less than 10x that. Are we doomed? @donkeyblam @donkeyblam oh snap I forgot Chicken, which is probably the best for systems programming and is an impressive14mb |
my compiler is just as fast as your super strong and manly systems programming language compiler, and smaller than your compiler's documentation.