Re: Stealing a Great Idea from the 6600

On 4/28/2024 2:11 AM, BGB wrote:

On 4/28/2024 12:56 AM, BGB wrote:

On 4/27/2024 8:45 PM, MitchAlsup1 wrote:

BGB wrote:
>

 ...
 

>

I guess some people are dragging their feet on FDPIC, as there is some debate as to whether or not NOMMU makes sense for RISC-V, along with its associated performance impact if used.

>

In my case, if I wanted to go over to simple base-relocatable images, this would technically eliminate the need for GBR reloading.

>

Checks:
Simple base-relocatable case actually currently generates bigger binaries, I suspect because in this case it is less space-efficient to use PC-rel vs GBR-rel.

>

Went and added a "pbostatic" option, which sidesteps saving and restoring GBR (making the simplifying assumption that functions will never be called from outside the current binary).

>

This saves roughly 4K (Doom's ".text" shrinks to 280K).

>
Would you be willing to compile DOOM with Brian's LLVM compiler and
show the results ??
>

>

Will need to download and build this compiler...

>

Might need to look into this.

>
Please do.
>

>
Extracting the ZIP file and "git clone llvm-project" etc, have thus far taken hours...
>
Well, and then the commands to CMake were not working, tried invoking cmake more minimally, and it gives a message complaining about the version being too old, ...
>
Seems I have to build it with a different / newer WSL instance (well, I guess it was either this or try to rebuild CMake from source).
>
>
Checks, download for compiler (+ git cloned LLVM) is a little over 6GB.
>
>
Well, OK, now LLVM is building... I guess, will see if it compiles and doesn't explode in the process. Probably going to be a while it seems.
>

   A little over an hour later and it still hasn't broken 50% yet...
 I think LLVM rebuilds may have actually gotten slower than in the past...
  Well, at least my 112GB of RAM means it isn't swapping too much...
 Computer is a little sluggish and the "System" process seems kinda pegged out though...
   I guess I will know sometime later whether or not all of this builds...
 

Still watching LLVM build (several hours later), kinda of an interesting meta aspect in its behaviors.
Sub-stage 1:
cc1plus processes, they start out mostly idle, sit around idle for a few seconds, CPU activity spikes and then they terminate (and a new one spawns to take its place).
During this sub-process, PC is generally sluggish.
Sub-stage 2:
"llvm-tblgen" runs; these processes are short lived and run at high CPU load; but PC stops being sluggish for the brief moments it is running these (but, soon enough, it is back to the former stage).
Overall CPU load is fairly modest, and HDD activity is also fairly reasonable. Seems like there is a bottleneck that "cc1plus" steps on.
The "System" process runs at somewhat higher than usual CPU load (~ 8%), process description "NT Kernel & System", where spikes in this process seem correlated with the "general sluggishness".
Seems likely related to the "teh crapton" of files it contained...
Also does not escape my notice that on the build drive in question, it has seemingly eaten over 100GB of disk space during the build project...
Like, seemingly, LLVM has managed to somehow become more absurd than it was in the past...
Dunno, maybe all this seems like pretty reasonable project design to some people, but at least to me, it all seems a little absurd.
Well, unless some people experience it building quickly and not eating huge amounts of HDD space.
Dunno, maybe related to me running the build on a drive with "Folder Compression" enabled?... (Often times, folder compression makes things faster, but this might be one of the times where it doesn't).
Some of this is kind of a disincentive to trying to build a compiler based on LLVM though. Trying to have this as a normal part of the build process seems implausible.
Like, if it makes Vivado synthesis and implementation seem fast and lightweight in comparison, this is not an ideal situation...
GCC is an ugly mess, but at least it builds moderately faster.
...