「 Rust will invariably solve some issues in today’s programming, including security-related trouble such as Heartbleed or the goto fail fiasco of 2014. But Rust will invariably introduce new issues, completely unforeseen as of now. And a new, modern programming language will appear in 2050 or 2060 solving those issues, and the rewrite cycle will begin all over again 」
This is huge. I’ve been bullish on RISC-V from the beginning but this is happening even faster than I expected. Between IT Sovereignty and geopolitics involving access to global supply chains, hyperspecialization of algorithms to hw, etc., it’s about to get really interesting.*
We’re one generation from the tech hacking culture of cyberpunk fiction.
HW heterogeneity will be mediated by LLVM and WebAssembly.
I'm just now catching Andrew Whatson's talk on #PreScheme from #fosdem this year, and I just can't get over the fact that he was able to implement a working, reasonably fast systems programming language with Hindley-Milner type inference in his free time over the course of a few months. And I was in the #GuileSteel irc when the discourse first started, it was probably less than a month before he got it working. I even try it then and it seemed great for something that went up that quick. What other programming languages make rapid prototyping #compilers feasible without relying on massive frameworks like #LLVM or #Truffle/#Graal?
If you are using clang-format in any of your projects, this might be useful to apply complex .clang-format rules as you type rather than after-the-fact.
There is an #LLVM pass I'm interested in: MergeFunctions
It seems to allow us to cut size of compiled SPIRVs in half. However, it can also end up generating Pointers to Function which we absolutely can't and won't handle.
Anybody any idea how we could deal with this so we don't end up with any function pointers?
revng is a static binary translator. Given a input ELF binary for one of the supported architectures (currently i386, x86-64, MIPS, ARM, AArch64 and s390x) it will analyze it and emit an equivalent LLVM IR. To do so, revng employs the QEMU intermediate representation (a series of TCG instructions) and then translates them to #LLVM IR.
So the thing about LLVM IR is, in reality it's a family of accidental and informally defined dialects. Every LLVM-based compiler for a particular machine target refines the input module down to its own idiosyncratic dialect.
Consequently there's way more latitude for confusion and bugs than you'd initially guess.
Try using an i65 type in an x86 backend. When I did that years ago it sailed right through and generated nonsense code.
I have half an hour trip to climbing gym and back 3 times a week. Not to waste this time I take my laptop with downloaded materials with me and watch courses.
Back to work on packaging @hare for @fedora, let's see how much I can bang out in a few hours. The resulting artifacts are going to be fairly simple, but not particularly packager friendly. That's a day-2 project.
New cross-compile meta packages for #GNU and #LLVM dependencies.
I've created a convenience script, harex, to switch to non-GNU toolsets. Just set HARE_XCOMPILE_TOOLCHAIN to "llvm". User specified env vars will still be respected.