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 <cr88192@gmail.com>
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: <v6cetg$3vrrp$1@dont-email.me>
References: <v66eci$2qeee$1@dont-email.me> <v67gt1$2vq6a$2@dont-email.me>
 <v687h2$36i6p$1@dont-email.me> <871q48w98e.fsf@nosuchdomain.example.com>
 <v68dsm$37sg2$1@dont-email.me> <87plrsultu.fsf@bsb.me.uk>
 <v68sft$3a6lh$1@dont-email.me> <87ed87v4wi.fsf@bsb.me.uk>
 <v6b5uf$3p1is$1@dont-email.me> <v6c3h5$3u078$1@dont-email.me>
 <v6c553$3tl33$3@dont-email.me>
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: <v6c553$3tl33$3@dont-email.me>
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 ==========