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: 2) by DannyB on Thursday October 05 2017, @02:30PM (4 children)
As soon as I read that much, I was immediately going OMG . . . . yikes! I see your point there immediately.
Even without the caffeine from drinking a Lake made of Coffee1, I can see the possibilities. If a TLA can interfere with the compilation process, as in the famous Trusting Trust, which I read many aeons ago, they can compromise even trusted systems by compromising the binaries of the OSes, the compilers, etc. Of course such an attack would be immensely sophisticated.
You misspelled trollkeepers.
I remember the daze of
NeVRNeXT. In hindsight, it doesn't surprise me that a huckster would try to steal an open source compiler, or at least the massive work that went into it, without contributing back important changes. (eg, "think different") Now that I consider what you pointed out, it just reinforces my deep dislike of Steve Jobs and Apple. To think in my younger more naive days I was an Apple fanboy back in the 80's and early 90's. Wow.I like to work at a much higher level than that. But I remember my C++ days in the 90's. I realized the ABI incompatibilities back then. Not to mention that every vendor compiler was a (different) subset of the overall C++ language. I fled to Java and have remained there, including higher level languages on top of the JVM. So that also makes me very interested in ways that JIT improvements can benefit me. (or my employer)
1lets call it a Coffee Lake
The people who rely on government handouts and refuse to work should be kicked out of congress.
(Score: 0) by Anonymous Coward on Thursday October 05 2017, @03:27PM (3 children)
Yeah.
Mind you you might have a predisposition to root for assholes if you chose to jump from Apple and C++ to first Sun then Oracle and Java :P
Not really a big fan of Java as a language, although I do appreciate the work it has lead to in VMs, especially JamVM. The promised write once run anywhere never really became compelling over write once compile anywhere, as both the systems monoculture and the number of platform specific java apis increased.
(Score: 2) by DannyB on Thursday October 05 2017, @05:47PM (2 children)
I don't root for Sun. I especially don't root for Oracle. Back when I did root for Apple, they were leading the industry in every way. But then Apple stumbled. Steve Jobs was brought back. And then everything became about fashion. Now Apple products aren't necessarily even user friendly. Let alone being leading tech. (using the highest end components is not leading tech) I could elaborate about how Apple was way ahead of PCs back in the day, the list of ways is long.
Java is okay as a language. But if you don't like Java, then what you're probably not using is the tooling of modern IDEs. Modern IDEs do amazing things with Java source code. The compiler isn't an "executable". The compiler is a library with an API. The compiler executable is quite small but uses this huge library. The source editor is deeply integrated with the compiler. It keeps a database about the AST of all code in your project. Want to rename a method? The IDE precisely renames it everywhere. (Not by doing a dumb search and replace.) But precise renaming based on understanding of the AST of all other references to this identifier. You could use the same identifier name in some other context in the same project. Perhaps another class has an unrelated method of the same name. It won't be touched because the editor knows, just as the compiler knows, that it is something different. And renaming is just the tip of the iceberg of source code manipulations that the editor can do for you.
I'm glad you recognize the VM. It is industrial strength. Choice of GC algorithms. Many tuning parameters. There are vendors such as Azul that have specialized GC's to offer. You can have dozens or hundreds of gigabytes and still have short GC times. I don't think most other language runtimes can boast that yet.
The Java VM JIT is something. Two compilers C1 and C2. When your code becomes "hot" enough (using enough CPU according to dynamic profiling) it is rapidly compiled to native code using C1, and it is scheduled to be compiled later with C2. When C2 comes along, it will do a high quality compile of that method, spending more time optimizing. This is why Java applications seem to "warm up" and become very fast.
The C2 compiler aggressively inlines. What if your method calls my method. Your method got compiled with C2 and aggressively inlined code from my method. Now, for whatever reason, a new version of the class containing my method is dynamically reloaded. Oh, no! Your method now has stale code inlined from my method. Not to worry. The JVM immediately invalidates your method's compiled code, and it goes back to interpreted mode again. If your method is hot enough to get recompiled again, it will go through the C1 / C2 process again.
If you don't like Java, there are other languages that run on the JVM.
Here is something I've seen before. People want something. With gobs of amazing features. Eventually somebody builds it. It has all your wish list items. But then the complaint is that it is big and complex. I want a simple text editor instead of an IDE. An IDE is too big an complicated. That's like complaining that you'd rather dig a ditch with a shovel instead of the noise and complexity of operating a backhoe. Or this . . . I don't like this big complex word processor compared to a simple text editor. Okay, but that word processor has a lot of features not in the text editor.
Similarly with languages and runtimes. When languages get to be high level and offer tons of abstractions, some people, who like to work closer to the hardware, complain about the cost of those abstract languages. It's the same battle from the 1970's about using Pascal or Fortran vs Assembly language. Guess which languages won? The thing is: human productivity is a cost also. Would you rather have your new whizbang program six months sooner if it only used twice as much memory and 50% more cpu? A lot of people would say yes. But here's a better argument: if I can write in Java and get to market six months (or more) sooner than the C++ guy, my boss won't blink an eye if I want six times as much RAM. Memory is cheap -- in these terms. You can't buy back opportunity.
The people who rely on government handouts and refuse to work should be kicked out of congress.
(Score: 0) by Anonymous Coward on Thursday October 05 2017, @07:03PM (1 child)
... then you're not working on something worthwhile. It's just consumer crap.
Anyway, as a language, C++ is superior because one of its guiding design principles is that you shouldn't have to pay for a feature you don't use; this has led to a language that can be used for coding from the lowest levels of abstraction to the highest, and without any overhead being imposed unnecessarily.
That is why people don't like C++; it actually provides nearly everything that everyone wants, and people hate both having to make choices and having to deal with other people's choices.
(Score: 2) by Wootery on Friday October 06 2017, @06:38PM
Generally true, but LLVM's coding standards ban RTTI and exceptions, precisely to avoid bloating their binaries. They even rolled their own alternative to RTTI.
https://llvm.org/docs/CodingStandards.html#do-not-use-rtti-or-exceptions [llvm.org]