ARM also does something similar, many instructions has a flag bit specifying whether flags should be updated or not. It doesn't have the multiple flag registers of POWER though.
Which at least back in the day neither the IBM compilers nor GCC 2.x - 4.x made much use of. I've seen only a few handoptimzed assembler routines get decent use out of them. Easy to fuse pairs a probably a good compromise for carry calculation e.g. add + a carry instruction. That would get rid of one of the additional dependencies, but it would take a three operand addition or fusing two additions to get rid of the s…
Which feature are you saying was not used much? Addition with carry; or addition without carry; or multiple flag registers?
No argument from authority is needed. Anyone is free to download the disk images for a large body of software such as the same versions of Ubuntu or Fedora, and compare the binary sizes -- using the "text" output from "size" command, not raw disk files as there are also things such as debugging info in there. Here's an example, using (ironically) the GMP library itself. https://news.ycombinator.com/item?id=29423324 H…
That could be confounded by gcc not enabling -funroll-loops, alignment of branch targets, etc for some architectures.
Conceivably, different ISAs could have the code compiled with different size/performance tradeoffs. One assumes that the Ubuntu and Fedora etc people would make sensible choices, consistent across ISAs. I don't know any reason why they would both make the same bad choices (which by "bad" here I am talking about small code at the expense of speed).
Gcc certainly supports unrolling, alignment of labels / loops / functions on all targets I'm aware of.
This of course utter nonsense. There's nothing different about the performance of compressed instructions.
For competitive performance in 2021 with CPUs that can be used at performance levels at least as high as those required for mobile phones, it is necessary to decode simultaneously at least 8 instructions per clock cycle (actually more for RISC-V, because its instructions do less than those of other CPUs). The cost in area and power of a decoder for variable-length instructions increases faster with the number of simu…
8-wide is the absolute state of the art. Last I checked, AMD’s fastest core was 4-wide, and Intel’s was 6-wide. I only know of Apple doing 8-wide, and not anyone else. So branding this as the minimum necessary for mobile devices when even most desktops do not achieve it is silly.
> I don't think they even tried to read the ISA spec documents. If they did, they would have found that the rationale for most of these decisions is solid: Evidence was considered, all the factors were weighted, and decisions were made accordingly. It's perfectly possible to have read the spec and disagree with the rationale provided. RISC-V is in fact the outlier among ISAs in many of these design decisions, so ther…
The size of the files can be very misleading, because a large part of the files can be filled with various tables with additional information, with strings, with debugging information, with empty spaces left for alignment to page boundaries and so on. So the size of the installed files is not necessarily correlated with the code size. To compare the code sizes, you need tools like "size", "readelf" etc. and the data…
Once again, you’re comparing the compressed instructions without telling anyone that that’s what you’re doing, because you are convinced that the compressed instructions will never be performant on a mobile or desktop core. The foundation disagrees, and every manufacturer competing in mobile-class RISC-V chips disagrees. Even if you think that they are wrong, that is the plan they are going forward with. Real world RISC-V chips targeted at the mobile space support the compressed instruction. Even if you think that they are wrong to do so, the support is there. So what you are doing is refusing to compile for the instruction set the chips actually support, instead targeting what you think they should be doing instead, and then declaring that the code density is worse. This is nonsense.
Hmmm... I think this argument is solid. Albeit biased from GMP's perspective, but bignums are used all the time in RSA / ECC, and probably other common tasks, so maybe its important enough to analyze at this level. 2-instructions to work with 64-bits, maybe 1 more instruction / macro-op for the compare-and-jump back up to a loop, and 1 more instruction for a loop counter of somekind? So we're looking at ~4 instructio…
> RISC-V has a bunch of competing vector instructions.
There is only one standard V extension. Alibaba made a chip with a prerelease version of that V extension which is thus incompatible with the final version, but in practice that just means that the vector unit on that chip is not used because it is incompatible, not that there are now competing standards