Path: ...!npeer.as286.net!npeer-ng0.as286.net!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: BGB Newsgroups: comp.lang.c Subject: =?UTF-8?Q?Re=3A_technology_discussion_=E2=86=92_does_the_world_need?= =?UTF-8?B?IGEgIm5ldyIgQyA/?= Date: Sat, 6 Jul 2024 17:01:08 -0500 Organization: A noiseless patient Spider Lines: 285 Message-ID: References: <871q48w98e.fsf@nosuchdomain.example.com> <87plrsultu.fsf@bsb.me.uk> <87ed87v4wi.fsf@bsb.me.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Sun, 07 Jul 2024 00:02:25 +0200 (CEST) Injection-Info: dont-email.me; posting-host="f7c16b2fffd87ab0346ebf4c8e11259c"; logging-data="4190073"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/gmoQQn9PhX0LDkC5gTu2NUqOdpXPEbZU=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:CQbmfV4xW5oXYZUYDk6ArKMhS70= In-Reply-To: Content-Language: en-US Bytes: 11702 On 7/6/2024 2:15 PM, bart wrote: > On 06/07/2024 19:46, BGB wrote: > >> But, yeah, for most people, writing the compiler is always "someone >> else's problem". >> >> >> Granted, even with as much suck as it was to write my own C compiler >> to target my ISA, it is still likely a better experience than it would >> have been trying to retarget GCC or Clang. >> >> GCC is sort of a tangled mess of code, trying to add a new target >> would likely involve weaving it in all across the codebase, which is >> comparably fairly large (well into MLOC territory IIRC). >> >> >> Any desire to retarget Clang is limited by the issue that it would >> involve needing to edit and recompile LLVM a large number of times, >> and LLVM takes an absurdly long time to recompile... >> >> They are like "well, use -j N". >>    But, like, "-j 1": It takes like 4 hours; >>    "-j 4": It still takes around 1 hour, PC still usable. >>    "-j 8": It takes 45 minutes, but PC is made unusable. >> >> Doing so also eats most of the RAM, on a PC with 112 GB... (Can't >> install a full 128GB with my MOBO/chipset it seems). >> >> At "-j 8", the HDD with the pagefile is basically running at full >> capacity. > > Those figures are extraordinary. > > But do you really need to recompile everything in LLVM even when > changing only target-specific components? > I haven't looked into it too much, but as I understand it, changing target stuff will require rebuilding LLVM each time. Either way, I didn't feel terribly inclined to find out. Seemingly the usual answer is "have a Linux box with some absurd hardware stats to use as a build server". This is, not ideal... Like, I don't exactly have the money to afford on a "Dual socket Threadripper with 256GB of RAM" or similar in order to try to get semi-fast LLVM rebuilds. > How much of it is due to it using C++ rather than C? > Probably a fair bit. When I looked at the LLVM code before, it seems like they are writing C++ in a similar way to how one would write code in Java. This sort of thing seems "kinda evil" for build times... > Maybe you should consult with David Brown who doesn't believe in the > benefits of fast compilers, and always knows some tricks to get a > build-time in seconds no matter how slow the compiler. > I can generally recompile BGBCC in a few seconds... Though, for the most part, it is a monolithic unity build, for better or for worse. Could potentially split it up into multiple components, but doing so would make it more of a hassle than leaving it as a single monolithic entity. > > With my own tools, that run on one core with 8GB (2GB of which seems > tied up with the display for some reason, even though the HD display > needs only a 0.006GB frame buffer), I can't do anything else when > compiling, because it will have finished before I've taken my finger off > the Enter key! > > This is largely thanks to machines now being so fast rather than my > coding skills, but also because I've never managed to learn how to write > huge, bloated, inefficient software. > Code tends to get kinda bulky in my case, but still fairly small vs a lot of OSS projects. As noted, BGBCC is around 250 kLOC. Overall project is around 2 MLOC, but around half of this is from ported software. So, say (very loosely): 250 kLOC: BGBCC 100 kLOC: jx2vm (CPU emulator) 200 kLOC: TestKern "OS" and runtime libraries. Highly modified PDPCLIB Stuff for memory management, filesystem, etc. A makeshift GUI of sorts; An OpenGL 1.x implementation; ... ... Then, say, other stuff: 50 kLOC: Doom 75 kLOC: Hexen 150 kLOC: ROTT 300 kLOC: Quake3 ... Comparably, Doom 3 is around 1 MLOC, but like, it is also C++ and has no chance of running on BJX2 as-is, so not worth bothering. I had just barely crossed the threshold to where it seemed worthwhile to resume an effort to port Quake3 (after looking at it a few years ago, and noting that at the time, I didn't have a lot of the infrastructure needed for a Quake3 port). Nevermind an open question of whether it has any hope of being playable on a 50MHz CPU. Though, if anything gives hope here, it is that ironically Quake3 seems to throw significantly less geometry at the OpenGL backend than Quake1 did (mostly I suspect because QBSP carves all the map surfaces into little pieces along all of the BSP planes, whereas Quake3 tends to leave surfaces intact across planes, duplicating a reference to each surface within each leaf rather than carving it up). So, for example, Quake3 tended to average (IIRC) around 300-500 polygons per frame (despite the much more elaborate scenery) vs around 1000-1500 per frame for Quake1 (also it has LOD for the 3D models, so models use simpler geometry as they are further from the camera, etc). But, to really see what happens, I need to get it fully working... My porting effort did make some aggressive corner cutting in a few areas, like replacing the ZIP based PK3 files with WAD4, and replacing most of the use of JPEG images with ".DDS" files. Where WAD4 is effectively: Similar to the WAD2 format, but supporting directory trees and 32-character names. Where, WAD2 was a format originally used in Quake 1 for storing various graphics (and for textures in the QBSP tools). The WAD2 format was also used for similar purposes in Half-Life. I had also used it for various purposes in my compilers and in my "OS". Technically also the ".rsrc" section in my PE output is also based on the WAD2 format (replacing the original format used by Windows, which seemed hopelessly convoluted). It still serves the purpose though of mostly holding BMP images and icons. Or, like: IWAD/PWAD: Used in Doom and friends No compression 8 character lump names (nominally upper case). WAD2: Used in Quake and Half-Life Optional compression 16 character lump names (nominally lower case). Names will omit file extensions, which are stored as a 1 byte lump type. WAD3: ========== REMAINDER OF ARTICLE TRUNCATED ==========