Re: Why VAX Was the Ultimate CISC and Not RISC

On 3/3/2025 2:06 AM, Anton Ertl wrote:

Thomas Koenig <tkoenig@netcologne.de> writes:

The VAX is still supported with gcc and binutils, with newlib as
its C library, so building up a tool chain for assembly/disassembly
should be doable with a few (CPU) hours; you can then compare
sizes.

 Good.  While the CPU hours are not the problem, I cannot spare the
human hours for such a project.
 

Similar for why I am not doing full comparisons...
Can note in my case, a few targets for Dhrystone (".text" size):
   x86-64, GCC   :   3.3K  (dynamically linked)
   SH-4,   GCC   :  90.5K (static linked, old binary, TestKern)
   XG2,    BGBCC :  71.3K (static linked, TestKern)
   RV64G.  GCC   : 144.9K (static linked, TestKern)
Doom:
   x86-64, GCC   : 244.2K (dynamically linked)
   XG2,    BGBCC : 296.4K (static linked, TestKern)
   RV64G.  GCC   : 460.6K (static linked, TestKern)
Doom ("-Os"):
   x86-64, GCC   : 174.2K (dynamically linked)
   RV64GC. GCC   : 352.1K (static linked, TestKern)
Can't directly compare against Thumb2 at the moment, in past tests, it was the leader, but for accurate results would require it to also use the same C library (similar issues at present with comparing against x86 or x86-64). Also, being 32-bit, they aren't really in the same category.
Though, XG2 isn't doing too badly vs x86-64, given the x86-64 versions are dynamically linked.
Though, it would appear so much in my own testing that it isn't so much that XG2 gets amazing code density, but that RISC-V output tends to be bulkier than some seem to claim (and neither "-Os" nor RV64GC seem to make all that drastic of a difference to the final ".text" size).
So, RV64GC gets around 370K instead (or 352K with RV64GC + "-Os"), still doesn't put it in the lead.
The "-Os" option seems to make a much bigger difference with x86-64 though.
Generally, I am counting ".text" specifically, rather than the overall size of the binary (can note that generally, ELF objects burn a considerable amount of space on metadata).
I am also leaving out MSVC output at the moment, as it tends to be an outlier in terms of bloated ".text" sections (Doom with VS2022 gives a size of roughly 1MB).
In many cases, doesn't make a huge difference, except when trying to shoe-horn stuff into ROMs, or annoyance about large code/data wasting RAM or increasing loading times (or both: the RV64G+ELF binaries combine the powers of bulkier code, bloated metadata, and being uncompressed; to give much worse loading times in the Verilog simulations...).

- anton