What does a "front-end" mean exactly, in this context?
Old compilers didn't use this concept. So a C->x86 compiler and a Fortran->x86 one couldn't share code as easily. And if you wanted to expand to, say, ARM, Alpha, etc. targets, it gets worse. You end up needing O(l*t) compilers[a] to be homogenous. It gets even worse if you want to add optimization. With this model, the whole system is working on an AST, and therefore, the optimizers are tailored to the individual compiler varient, so they end up being just as unportable.
However, with a modular design (front and back end), you can have C->IR and Fortran->IR front ends, then a single back end for each target: IR->x86 and IR->ARM. If you want to add, say, Ada support, you only need to write an Ada->IR module, and the back ends handle the rest. In the end, you only need O(l+t) modules. You also get the benefit of agnostic optimizers as they only need to support your internal IR.
[a]: 'l' is languages and 't' is targets
LLVM's original purpose was something analogous to the JVM, but it's obviously evolved to be more of a compiler platform, debugging toolchain, etc these days
(No direct hardware support, though, as cool as that sounds)
Meanwhile normal instruction sets are just a bytecode optimized to run quickly.
LLVM-IR at least also isn't stable, so not a good thing to bake into a chip - but you could conceivably make a stable intermediate language.
Intermediate code tends to have downsides that make it hard to work with in an actual hardware implementation. Infinite registers, for example, which makes encoding instructions challenging.
However they apparently don't want to keep fixing upstream changes and is now deprecated going forward.
As Blackthorn mentioned, specifically it can be done. There was a chip that ran JVM bytecode directly. There was an entire Lisp Machine which was very influential... but not because of its high performance.
Wikipedia has a page on this: https://en.wikipedia.org/wiki/High-level_language_computer_a...
Many people decry the lack of innovation in computer architecture over the past 50-60 years. There is a legitimate reason for that, though: Any such innovation had to outrun the exponential increases conventional architecture was experiencing. We had it for so long we could take it for granted, but while computing wasn't the first and won't be the last to see periods of exponential growth, I can't think of anything else that had the length of run that computer chips had. (And even now, it's only slowed down. There's still multiplicative advances rather than additive ones every year. The base on the exponent is just smaller than it used to be.) There's been a number of architectures based on running IR (or an equivalent directly) that didn't pan out, but there's also some that did run OK, but they just couldn't keep up with the exponentially accelerating behemoth.
I think if silicon continues to plateau, there is some hope that this could change. However, a new challenger has appeared! Now it's not good enough to just outrun what a "conventional" architecture can do with CPU and RAM and peripherals... now you also need outrun what a GPU-based architecture can do! This sucks up a lot of the oxygen. For instance, right now you see some tentative steps towards special-purpose AI silicon, but it has to do something amazing to beat out a GPU, and you also have to be really, really sure that the AI technique you are committing to silicon will still be the state-of-the-art in the couple of years it'll take you to bring it to market. AI hasn't been moving as fast as, say, JS front-end frameworks, but it's still moving fast enough that I'd be nervous in investing in that vs. the same amount of effort poured into optimizing a GPU algorithm on GPUs that are still advancing a lot every year.
The bigger issue (IMO) is that the IR for compilers tends to evolve rapidly while hardware is stuck in the mud. Moving the problem of finalizing the IR into the hardware will effectively make it so you'd change your compiler to emit IR that targets old IR.
This is why, for example, x86 will get a new instruction which will effectively go unused for 5 to 10 years (except in extreme cases where the performance gains are worth the cost of writing code to detect and use those new instructions... For example, FMA). Those who compile code want it to be able to run most anywhere in not so surprising fashions, so they'll target the LCD.
Now, imagine someone was building a JVM bytecode chip today. The JVM is on a 6 month release schedule. That's incredibly hard for a hardware manufacturer to want to keep updating their chips at that rate. Further, even if they targeted "LTS" versions, they've moved that to a 2 year cycle. Again, hard to really expect customers to want a new JVM chip every 2 years.
The likes of GCC and LLVM IR change and expand just as rapidly (if not moreso) than than JVM.
There is the option of something like FPGA or programmable hardware leaking into more places, but IMO, the HDLs and their tools simply suck too bad to expect FPGA on an ASIC to really take off. We need a first mover here and after that happens, I expect at least 5 to 10 years before the tools get to a level that doesn't completely suck. Even then, while access to GPGPUs is now pretty much universal, GPGPU programming still feels like it is in the stone ages. Despite being a thing for over 10 years. So how can we expect HDLs to evolve at a faster pace?
I'm not sure that the vaporware Mill CPU acts as an existence proof for anything, to be honest.
The problem of infinite registers is pretty easily solvable. Heck x87 already has that basic concept down with the stack registers. The only missing piece is moving overflow values onto and off of the stack. It's a fairly easy to solve problem.
That's effectively what Mill proposed in their docs. The "belt" notation was their cute way of doing that.
You still have a limited window of 8 registers. Need 9 simultaneous live values? Oops, too few registers! In order to encode infinite registers, you need to be able to support referring to an arbitrary number of registers at once, which means you need an arbitrary-length register number specifier... have fun handling that in hardware!
Already addressed and not really that hard of an issue to solve. Hardware already has all the logic embedded in it to be able to load or store memory into/from registers.
The logic would mirror the logic done by compilers when they are allocating registers and deciding what needs to be evicted to the stack.
The only missing piece is where that memory should be, but that's really as simple as having either the OS or the application logic allocate a special memory region for the purpose of register evictions and loads.
I'd be interested in reading an article from someone who has been doing it for 10 years as to why that is the case. I have theories but nowhere near enough direct experience to evaluate.
(My hypothesis is that the extreme parallelism makes it so very tiny mistakes have catastrophic performance impact by introducing accidental serialism, and as a result, it is very difficult to create an "easy to use" framework that doesn't abstract too much away and make it trivially easy to introduce even a tiny such error and crash performance. We actually make this mistake all the time in conventional CPU code, it just generally just costs you small integer multiples of performance instead of large integer multiples of performance.)
We have 4 major GPGPU manufactures (Apple, Intel, AMD, nVidia) and none of them want to make creating an open standard easy. There is no reason why nVidia should support OpenCL the same way that AMD does, they want people to write CUDA. There's no reason for Apple to support OpenAAC like Intel does, they want people to write Metal... etc. These 4 companies are trying to push everyone into their proprietary ecosystem or into an open ecosystem where they have a large say.
I had hoped that SPIR-V would be a good inroad to start fixing some of these problems, but alas, it seems like Apple and nVidia aren't big fans. It's early still, though, so maybe that changes?
OpenCL 2.x was a failure, hence why OpenCL 3.0 is basically 1.2 with everything else from 2.x marked as optional.
Short answer, it’s feasible in theory, but usually suboptimal.
https://en.wikipedia.org/wiki/Jazelle
Jazelle was an instruction set extension to allow natively running java bytecode on Arm processors. Arm never seemed to give it any proper care and attention necessary for it to make any actual market impact, they didn't even publish the ABI.
Transmeta, that used to employ Linus Torvalds at one stage, had Code Morphing Software: https://en.wikipedia.org/wiki/Transmeta#Code_Morphing_Softwa...
It was built in to the silicon, that essentially operated as a full JIT for x86 software, translating to back-end VLIW instruction set. Transmeta seemed heavy on the marketing and buzz (hiring Linus was very much a marketing move), light on the actual execution. Crusoe didn't even remotely live up to their own buzz and it just about killed off their chances of success.
I think Rust on LLVM has a major example of this? IIUC, it's a big problem to turn on strict aliasing because LLVM doesn't actually implement it correctly, it just works well enough for C/C++ etc.? (But I'm no expert.)
Still, the frontend/backend split gets you a lot closer to supporting all of the l*t pairs than the all-in-one approach. Porting is a matter of fixing bugs and filling in missing parts rather than starting from scratch.
AIUI, the solution wasn't that Rust smuggled the language-level construct through the intermediate layer, but that they simply held off on expressing these constraints until bugfixes could be merged upstream into LLVM. The only downside to disabling this was simply that compiled code would potentially be a bit less optimal than otherwise, so such tactics weren't really necessary.
It's noalias (C99's restrict code, in essence), that you're thinking of, not C/C++ strict aliasing rules.
This is most common where C++ (as the main consumer of these semantics) doesn't define certain semantics, or, the semantics it standardises are just impossible to optimise so nobody really delivers them (ie they don't always work in your C++ programs when you compile them with actual modern C++ programs)
As I understand it an example when it comes to aliasing would be what happens if somebody typed a bunch of ASCII into a prompt and then the program... uudecodes the ASCII to get an integer, and begins just using that as a pointer to rummage around in some data structure.
Is that... OK? Obviously you can't do this in safe Rust, but even unsafe Rust says er, no, that's definitely not allowed (it might actually work but it isn't OK). But the ISO C++ standard says that so long as the ASCII string happened, by some cosmic accident, to be a "valid" address for a pointer after this transformation this works fine even if it now magically aliases a pointer we otherwise had no reason to believe could be aliased.
If we allow this, many optimisation opportunities vanish. So, LLVM doesn't allow it. Our "correct" C++ pointer uudecoding program doesn't work. However, a blanket prohibition blows up real tricks that people actually do, such as hiding flag bits in address values (unlike uudecoding ASCII inputs to make pointers). So LLVM provides behaviour that's not formally standardised anywhere but can be thought of as something akin to PNVI-ae (Provenance Not Via Integers - Address Exposed). If the program "exposes" addresses from pointers, then the compiler assumes it could see those addresses "magically" appear from somewhere else (e.g. a uuencoded string) and so it must choose optimisations accordingly.
One day perhaps C++ will actually document PNVI-ae or some similar scheme in the ISO standard. That day is not today (nor next year, this will not happen in C++ 23) but meanwhile you've got the problem that, in unsafe Rust you actually get whatever arbitrary semantics that were delivered by LLVM. Since they're not just "This is what C++ does" but only "This is how C++ works in Clang" that's even less portable.
As I wrote, this only burns unsafe Rust. If you don't write unsafe and just depend on other people's stuff to use that as necessary (e.g. obviously the standard library is full of unsafety) then it's not your problem to fix this when it breaks. But it sure would be nice if the people writing unsafe code would have more certainty on this sort of topic.
Rust is experimenting with "Strict Provenance" rules to see what happens if, instead, it makes its own provenance rules and dispenses with waiting for C and C++ programmers to actually decide what the rules are in their languages. https://doc.rust-lang.org/std/ptr/index.html#strict-provenan...
Essentially, C and C++ already have a version of provenance for pointers and references, but it isn't identical to the Rust version.
Because some old codebases pull tricks of this kind (messing with pointers, doing casts without going through unions, etc), gcc (and clang) have a flag, -fno-strict-aliasing , to disable some optimizations that would be enabled by taking aliasing/provenance into account.
* Rust doesn't have strict aliasing/tbaa
* Rust does have "restrict" semantics (in C via the keyword and in C++ via common vendor extensions)
And yeah, Rust is considering a provenance model that's different than PNVI-ae.
None of this matters in Rust without unsafe. Pointers technically exist outside unsafe, but you can't do very much with them (you cannot, for example, dereference a pointer). And yes, Rust says that the attempted type pun you describe, which you would need unsafe to create, is Undefined Behaviour.
> you could use unions and get implementation-defined behavior
Type punning with unions is also Undefined Behaviour in C++. The sanctioned way to perform type punning is to memcpy() the data from type A to type B. C++ 20 provides a built-in way to ask for this to be done std::bit_cast
The C++ Standard is OK with this magic trick. Executing this trick in the C++ abstract machine is no problem at all.
However in a real world compiler this is a huge problem - because the optimiser assumes I can't possibly have such a pointer. Where would I get it from? This is where provenance comes into the picture. Where did my pointer come from, that's what provenance means. The C++ standard has nothing to say about provenance but your compiler depends on it.
I've been doing this stuff for a long time, going back to egcs and even before.
Nope, it says nothing whatsoever on the subject of provenance. Periodically people make a run up and try to get this fixed. N2676 is currently in front of WG14 (ie the C standards committee) with the long term hope that if WG14 takes this fix, or something like it, WG21 (C++) could be persuaded to eventually take a similar fix - although lots of people don't like N2676 and want something else (the more vague your "something else" the more popular). If the standard had "a whole lot" to say about provenance you'd be able to quote some of it. but I suggest reading N2676 for an example of what is not yet standard
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2676.pdf
> has detailed aliasing rules and rules about which pointers are valid
Aliasing rules forbid some type punning shenanigans, but again, and I will repeat myself, that's not what's going on here.
DR260 (Defect Report number 260, about twenty years ago) asks WG14 what their standard says about such magic tricks, and their response basically says well, compilers are allowed to somehow know about provenance, so actually our Standard is correct and this is working as intended. What's working as intended? Well, whatever your compiler actually does.
What a great standard! Note that this response isn't incorporated into subsequent versions of the standard, it's just basically known in the industry, oh yeah, that's DR260, don't worry about it.
> I've been doing this stuff for a long time, going back to egcs and even before.
That's nice, but it's not terribly relevant here, except that it means you remember an era when people didn't even realise this was a problem. It still was a problem, they just didn't know it was a problem yet. And hey, you know about that experience too, because apparently you didn't know this was a problem after 2004 either.
Rust would like not to kick this can down the road for 18 years and counting, which is why Aria Beingessner's experiment is happening.
The front-end compiles your input language (C, C++, Rust, etc) down to a low-level language called an Intermediate Representation. Then the back-end of the compiler optimizes the IR and compiles it into object code. A family of compilers will usually share the back-end.
This kind of split allows for deduplication across different compilers in the same family, and also makes it easier to design a new language without having to fully re-implement everything about the compiler yourself.
In GCC, these are bundled together as a common project afaik. In Clang/LLVM, these are split into the front-end (clang) and the back-end (LLVM).
I knew that Julia uses LLVM. I also knew that Julia has something called IR, but i didn't know what it was. So Julia's IR is probably LLVM's IR...
For some examples, the compiler plugins interface acts on typed IR, so things like Diffractor for automatic differentiation or JET static analysis and EscapeAnalysis.jl act there. Notably, Zygote automatic differentiation acted on the untyped IR. GPUCompiler.jl does some operations on the typed IR then lowers to the LLVM IR level and then intercepts the normal compilation process to choose alternative backends (e.g. compile to .ptx for compilation of native Julia to CUDA). Enzyme.jl uses the Enzyme LLVM-based automatic differentiation, so it does some actions on the typed IR before lowering to LLVM and then injecting the Enzyme LLVM pass before compiling via GPUCompiler.jl (now to the normal CPU backend).