SoylentNews is people
SoylentNews
from the please-let-the-vapors-condense dept.
From the lowRISC project's blog:
A high quality, upstream RISC-V backend for LLVM is perhaps the most frequently requested missing piece of the RISC-V software ecosystem… As always, you can track status here and find the code here.
RV32
100% of the GCC torture suite passes for RV32I at -O0, -O1, -O2, -O3, and -Os (after masking gcc-only tests). MC-layer (assembler) support for RV32IMAFD has now been implemented, as well as code generation for RV32IM.
RV64
This is the biggest change versus my last update. LLVM recently gained support for parameterising backends by register size, which allows code duplication to be massively reduced for architectures like RISC-V. As planned, I've gone ahead and implemented RV64I MC-layer and code generation support making use of this feature. I'm happy to report that 100% of the GCC torture suite passes for RV64I at O1, O2, O3 and Os (and there's a single compilation failure at O0). I'm very grateful for Krzysztof Parzyszek's (QUIC) work on variable-sized register classes, which has made it possible to parameterise the backend on XLEN in this way. That LLVM feature was actually motivated by requirements of the Hexagon architecture - I think this is a great example of how we can all benefit by contributing upstream to projects, even across different ISAs.
[...] Community members Luís Marques and David Craven have been experimenting with D and Rust support respectively.
[...] Approach and philosophy
As enthusiastic supporters of RISC-V, I think we all want to see a huge range of RISC-V core implementations, making different trade-offs or targeting different classes of applications. But we don't want to see that variety in the RISC-V ecosystem result in dozens of different vendor-specific compiler toolchains and a fractured software ecosystem. Unfortunately most work on LLVM for RISC-V has been invested in private/proprietary code bases or short-term prototypes. The work described in this post has been performed out in the open from the start, with a strong focus on code quality, testing, and on moving development upstream as quickly as possible - i.e. a solution for the long term.
(Score: 3, Interesting) by DannyB on Thursday October 05 2017, @02:08PM (1 child)
Instead of focusing on 128 bits. Then 256 bits, etc. I wish they would focus on putting MORE CORES into cpus. How about 16 cores. 32 cores. 64 cores. Etc. IMO, that is where the future lies as it becomes harder and more turgid to squeeze out the last drops of performance from a single core.
After years of thinking about how to do it, we software dudes1 have accepted that we need to recognize and look for opportunities where things can be turned from loops into "work units" of smaller loops. These work units can then be queued and spread out across cores. Then the results combined, and then the main thread continues about its business. Of course, this works best if you have tens of millions of items you are going to process in a loop. Like some big data set. Modern languages have modern libraries that make it easy to ForkJoin and other approaches to solve this problem. And yes, if you have enough items in a loop to significantly exceed the cost of the multi threading overhead, then it adds a significant speedup. Even in a desktop application. (Trust me, I did it this just a few months back.)
1not intended to exclude females
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 0) by Anonymous Coward on Thursday October 05 2017, @02:17PM
Would be a far better solution, although it would cause variance in code size and execution, as well as issues with current languages that make assumptions about pointer and other type sizes.
A number of processors over the years have used 'chunks' or 'segments' for this exact reason. The problem being some code/problems just works better with larger address spaces, the chunk swapping is time and bandwidth consuming, and both capacity is always increasing and many programmers are either sizing their code to match, or writing code sloppy enough to need the added ram, rather than engineering it efficiently to scale, regardless.