7 ms·

I wish the barriers to using new architectures were lower. For instance, suppose binaries were typically distributed in a platform-agnostic format, like LLVM i

by elihu 6y ago

I wish the barriers to using new architectures were lower. For instance, suppose binaries were typically distributed in a platform-agnostic format, like LLVM intermediate representation or something equivalent. When you run your program the first time, it's compiled to native code for your architecture and cached for later use. I realize I've sort of just re-invented Javascript. But what if we just did away with native binaries entirely, except as ephemeral objects that get cached and then thrown away and regenerated when needed? It seems like this would solve a lot of problems. You could deprecate CPU instructions without worrying about breaking backwards compatibility. If a particular instruction has security or data integrity issues, just patch the compiler not to emit that instruction. As new side-channel speculation vulnerabilities are discovered, we can add compiler workarounds whenever possible. If you're a CPU architect and want to add a new instruction for a particular weird use-case, you just have to add it to your design and patch the compiler, and everyone can start using your new instruction right away, even on old software. You'd be able to trust that your old software would at least be compatible with future instruction architectures. Processors would be able to compete directly with each other without regard to vendor-lock-in.

Ericson2314 6y ago
Come to Nix and Nixpkgs, where we can cross compile most things in myriad ways. I think the barriers to new hardware ISAs on the software side have never been lower. Even if we get an ARM RISC-V monoculture, at least we are getting diverse co-processors again, which present the same portability challenges/opportunities in a different guise.
dataangel 6y ago
> For instance, suppose binaries were typically distributed in a platform-agnostic format, like LLVM intermediate representation or something equivalent. The Mill does something like this, but only for their own chips. "Binaries" are bitcode that's not specialized to any particular Mill CPU, and get run through the "specializer" which knows the real belt width and other properties to make a final CPU-specific version.
- brucehoult 6y ago
  "does" is not exactly the right word here. "Proposes to do"?
retrac 6y ago
That's how IBM implemented the AS/400 platform. Everything compiled down to a processor-agnostic bytecode that was the "binary" format. That IR was translated to native code for the underlying processor architecture as the final step. And objects contained both the IR and the native code. If you moved a binary to another host CPU, it would be retranslated and run automatically. The migration to POWER as the underlying processor was almost entirely transparent to the user and programming environment. https://en.wikipedia.org/wiki/IBM_System_i#Instruction_set https://en.wikipedia.org/wiki/IBM_System_i#Instruction_set
- skissane 6y ago
  > That's how IBM implemented the AS/400 platform. Everything compiled down to a processor-agnostic bytecode that was the "binary" format Originally, AS/400 used its own bytecode called MI (or TIMI or OMI). A descendant of the System/38's bytecode. That was compiled to CISC IMPI machine code, and then after the RISC transition to POWER instructions. However, around the same time as the CISC-to-RISC transition, IBM introduced a new virtual execution environment – ILE (Integrated Language Environment). The original virtual execution environment was called OPM (Original Program Model). ILE came with a new bytecode, W-code aka NMI. While IBM publicly documented the original OPM bytecode, the new W-code bytecode is only available under NDA. OPM programs have their OMI bytecode translated internally to NMI which then in turn is translated to POWER instructions. The interesting thing about this, is while OMI was originally invented for the System/38, W-code has a quite different heritage. W-code is actually the intermediate representation used by IBM's compilers (VisualAge, XL C, etc). It is fundamentally the same as what IBM compilers use on other platforms such as AIX or Linux, and already existed on AIX before it was ever used on OS/400. There are some OS/400-specific extensions, and it plays a quite more central architectural role in OS/400 than in AIX. But W-code is conceptually equivalent to LLVM IR/bitcode. So here we may see something in common with what Apple does with asking for LLVM bitcode uploads for the App Store. > And objects contained both the IR and the native code. If you moved a binary to another host CPU, it would be retranslated and run automatically Not always true. The object contains two sections – the MI bytecode and the native machine code. It is possible to remove the MI bytecode section (that's called removing "observability") leaving only the native machine code section. If you do that, you lose the ability to migrate the software to a new architecture, unless you recompile from source. I think, most people kept observability intact for in-house software, but it was commonly removed in software shipped by IBM and ISVs.
msla 6y ago
> For instance, suppose binaries were typically distributed in a platform-agnostic format, like LLVM intermediate representation or something equivalent. When you run your program the first time, it's compiled to native code for your architecture and cached for later use. IBM's OS/400 (originally for the AS/400 hardware, now branded as System i) did precisely this: Compile COBOL or RPG to a high-level bytecode, which gets compiled to machine code on first run, and save the machine code to disk; thereafter, the machine code is just run, until the bytecode on disk is changed, whereupon it's replaced with newer machine code. IBM was able to transition its customers to a new CPU architecture just by having them move their bytecode (and, possibly, source code) from one machine to another that way. https://en.wikipedia.org/wiki/IBM_System_i https://en.wikipedia.org/wiki/IBM_System_i Other OSes could definitely do it.
- skissane 6y ago
  > Other OSes could definitely do it. See https://en.wikipedia.org/wiki/Architecture_Neutral_Distribution_Format https://en.wikipedia.org/wiki/Architecture_Neutral_Distribut... Using ANDF you could produce portable binaries that would run on any UNIX system, regardless of CPU architecture. It was never commercially released though. I think while it is cool technology the market demand was never really there. For a software vendor, recompiling to support another UNIX isn't that hard; the real hard bit is all the compatibility testing to make sure the product actually works on the new UNIX. ANDF solved the easy part but did nothing about the hard bit. It possibly would even make things worse, because then customers might have just tried running some app on some other UNIX the vendor has never tested, and then complain when it only half worked. Standards are always going to have implementation bugs, corner cases, ambiguities, undefined behaviour, feature gaps which force you to rely on proprietary extensions, etc. That's where the "hard bit" of portability comes from.
MaulingMonkey 6y ago
> I realize I've sort of just re-invented Javascript. Or one of several bytecodes that get JIT or AOT compiled. WASM in particular has my interest these days, thanks to native browser support and being relatively lean and more friendly towards "native" code, whereas JVM and CLR are fairly heavyweight, and their bytecodes assume you're going to be using a garbage collector (something that e.g. wasmtime manages to avoid.) Non-web use cases of WASM in practice seem more focused on isolation, sandboxing, and security rather than architecture independence - stuff like "edge computing" - and I haven't read about anyone using it for AOT compilation. But perhaps it has some potential there too?
- MaxBarraclough 6y ago
  I think the short answer is that the performance penalty is so significant that it doesn't make sense to use WASM unless you're running untrusted code.
saagarjha 6y ago
This sounds a bit like Google’s Portable Native Client.
- Wowfunhappy 6y ago
  (Which is deprecated now, and scheduled for removal.)
MaxBarraclough 6y ago
> I wish the barriers to using new architectures were lower. > For instance, suppose binaries were typically distributed in a platform-agnostic format, like LLVM intermediate representation or something equivalent. We're doing a pretty good job on portability these days already. Well-written Unix applications in C/C++ will compile happily for any old ISA and run just the same. Safe high-level languages like JavaScript, Java, and Safe Rust are pretty much ISA-independent by definition, it's 'just' a matter of getting the compilers and runtimes ported across. Adopting LLVM IR for portable distribution, probably isn't the way forward. I don't see that it adds much compared to compiling from source, and it's not what it's intended for. (LLVM may wish to change the representation in a subsequent major version, for instance.) For programs which are architecture-sensitive by nature, such as certain parts of kernels, there are no shortcuts. Or, rather, I'm confident the major OSs already use all the practical shortcuts they can think up. > When you run your program the first time, it's compiled to native code for your architecture and cached for later use. Source-based package management systems already give us something a lot like this. There are operating systems that take this approach, such as Inferno. [0] I like this HN comment on Inferno [1]: kernels are the wrong place for 'grand abstractions' of this sort. > I realize I've sort of just re-invented Javascript Don't be too harsh on yourself, JavaScript would be a terrible choice as a universal IR! > [[ to the bulk of your second paragraph ]] In the Free and Open Source world, we're already free to recompile the whole universe. The major distros do so as compiler technology improves. > Processors would be able to compete directly with each other without regard to vendor-lock-in. For most application-level code, we're already there. For example, your Java code will most likely run just as happily on one of Amazon's AArch64 instances as on an AMD64 machine. In the unlikely case you encounter a bug, well, that's pretty much always a risk, no matter which abstractions we use. [0] https://en.wikipedia.org/wiki/Inferno_(operating_system) https://en.wikipedia.org/wiki/Inferno_(operating_system) [1] https://news.ycombinator.com/item?id=9807777 https://news.ycombinator.com/item?id=9807777
- elihu 6y ago
  > Well-written Unix applications in C/C++ will compile happily for any old ISA and run just the same. Safe high-level languages like JavaScript, Java, and Safe Rust are pretty much ISA-independent by definition, it's 'just' a matter of getting the compilers and runtimes ported across. That sort of works, but duplicating the proper development environment in the end-user's computer would take a lot of space and would be complicated by the enormous variety of programming languages and environments. Linux distros manage this with a lot of effort. I'm imagining something like a universal intermediate representation that can be compiled quickly (because a lot of the early language-specific part of compilation will have already been done by whoever you get your packages from) and in a uniform way because there's a common intermediate representation format that all the compiled languages use. Universal binaries might also be acceptable for commercial, closed-source applications where source distribution would not.
gnufx 6y ago
Surely the barrier to using a new architecture is being able to boot a kernel and run (say) the GNU toolchain, as demonstrated with RISC-V. Then you just compile your code, assuming it doesn't contain assembler, or something. Whether or not you'll have the same sort of board support issues with RISC-V as with Arm, I don't know.
jacquesm 6y ago
> I realize I've sort of just re-invented Javascript. You've re-invented UCSD P-code. https://en.wikipedia.org/wiki/P-code_machine https://en.wikipedia.org/wiki/P-code_machine
- brucehoult 6y ago
  BCPL ocode is quite a bit older the UCSD P-code. The BCPL compiler always outputs ocode. Then a back end for the particular system statically generates machine code (or assembly language) Back in 1983 I helped take a BCPL running on a VAX and add a M6809 back end to it.
  - jacquesm 6y ago
    Ah yes, it even rates a mention on that Wikipedia page. Thank you for pointing this out. 1966! Funny how all these supposedly 'new' concepts really go back all the way to the beginning.
    - pjmlp 6y ago
      Like safe systems languages, first one 1961.
TheRealSteel 6y ago
Isn't that basically what Android Runtime does?
- elihu 6y ago
  I don't know much about Android specifically. Is it still heavily Java-based? There are a lot of universal-binary candidates both current and historical. Javascript, Java, SPirV, LLVM intermediate representation are some of the current ones. So, this isn't a new idea, it's just that most of the software I use regularly is compiled specifically for x86-64. Maybe it would be better if that were a rare exception rather than the norm.
  - pjmlp 6y ago
    Definitely, the use of Linux kernel is a pyrrhic victory only celebrated by those without native Android development experience. NDK's main purpose, from Android team point of view, is for writing native libraries.
grishka 6y ago
You've just reinvented bytecode. JVM/ART, WebAssembly, ActionScript, some versions of .net... You know, all the stuff that supposedly runs on everything.
pabs3 6y ago
> I wish the barriers to using new architectures were lower. Efforts like Bootstrappable Builds and Debian's rebootstrap aim to reduce the barriers for new architectures: https://bootstrappable.org/ https://bootstrappable.org/ https://bootstrapping.miraheze.org/wiki/Main_Page https://bootstrapping.miraheze.org/wiki/Main_Page https://wiki.debian.org/DebianBootstrap https://wiki.debian.org/DebianBootstrap https://wiki.debian.org/HelmutGrohne/rebootstrap https://wiki.debian.org/HelmutGrohne/rebootstrap For eg the Synopsis folks are bootstrapping a Debian ARC port right now using rebootstrap. https://github.com/foss-for-synopsys-dwc-arc-processors/rebootstrap/ https://github.com/foss-for-synopsys-dwc-arc-processors/rebo...
LargoLasskhyfv 6y ago
1989 is calling with a blast from the past: https://en.wikipedia.org/wiki/Architecture_Neutral_Distribution_Format https://en.wikipedia.org/wiki/Architecture_Neutral_Distribut... It didn't last.

by elihu 6y ago

Ericson2314 6y ago

Come to Nix and Nixpkgs, where we can cross compile most things in myriad ways. I think the barriers to new hardware ISAs on the software side have never been lower. Even if we get an ARM RISC-V monoculture, at least we are getting diverse co-processors again, which present the same portability challenges/opportunities in a different guise.

dataangel 6y ago

> For instance, suppose binaries were typically distributed in a platform-agnostic format, like LLVM intermediate representation or something equivalent. The Mill does something like this, but only for their own chips. "Binaries" are bitcode that's not specialized to any particular Mill CPU, and get run through the "specializer" which knows the real belt width and other properties to make a final CPU-specific version.

brucehoult 6y ago
"does" is not exactly the right word here. "Proposes to do"?

retrac 6y ago

That's how IBM implemented the AS/400 platform. Everything compiled down to a processor-agnostic bytecode that was the "binary" format. That IR was translated to native code for the underlying processor architecture as the final step. And objects contained both the IR and the native code. If you moved a binary to another host CPU, it would be retranslated and run automatically. The migration to POWER as the underlying processor was almost entirely transparent to the user and programming environment. https://en.wikipedia.org/wiki/IBM_System_i#Instruction_set https://en.wikipedia.org/wiki/IBM_System_i#Instruction_set

skissane 6y ago
> That's how IBM implemented the AS/400 platform. Everything compiled down to a processor-agnostic bytecode that was the "binary" format Originally, AS/400 used its own bytecode called MI (or TIMI or OMI). A descendant of the System/38's bytecode. That was compiled to CISC IMPI machine code, and then after the RISC transition to POWER instructions. However, around the same time as the CISC-to-RISC transition, IBM introduced a new virtual execution environment – ILE (Integrated Language Environment). The original virtual execution environment was called OPM (Original Program Model). ILE came with a new bytecode, W-code aka NMI. While IBM publicly documented the original OPM bytecode, the new W-code bytecode is only available under NDA. OPM programs have their OMI bytecode translated internally to NMI which then in turn is translated to POWER instructions. The interesting thing about this, is while OMI was originally invented for the System/38, W-code has a quite different heritage. W-code is actually the intermediate representation used by IBM's compilers (VisualAge, XL C, etc). It is fundamentally the same as what IBM compilers use on other platforms such as AIX or Linux, and already existed on AIX before it was ever used on OS/400. There are some OS/400-specific extensions, and it plays a quite more central architectural role in OS/400 than in AIX. But W-code is conceptually equivalent to LLVM IR/bitcode. So here we may see something in common with what Apple does with asking for LLVM bitcode uploads for the App Store. > And objects contained both the IR and the native code. If you moved a binary to another host CPU, it would be retranslated and run automatically Not always true. The object contains two sections – the MI bytecode and the native machine code. It is possible to remove the MI bytecode section (that's called removing "observability") leaving only the native machine code section. If you do that, you lose the ability to migrate the software to a new architecture, unless you recompile from source. I think, most people kept observability intact for in-house software, but it was commonly removed in software shipped by IBM and ISVs.

msla 6y ago

> For instance, suppose binaries were typically distributed in a platform-agnostic format, like LLVM intermediate representation or something equivalent. When you run your program the first time, it's compiled to native code for your architecture and cached for later use. IBM's OS/400 (originally for the AS/400 hardware, now branded as System i) did precisely this: Compile COBOL or RPG to a high-level bytecode, which gets compiled to machine code on first run, and save the machine code to disk; thereafter, the machine code is just run, until the bytecode on disk is changed, whereupon it's replaced with newer machine code. IBM was able to transition its customers to a new CPU architecture just by having them move their bytecode (and, possibly, source code) from one machine to another that way. https://en.wikipedia.org/wiki/IBM_System_i https://en.wikipedia.org/wiki/IBM_System_i Other OSes could definitely do it.

skissane 6y ago
> Other OSes could definitely do it. See https://en.wikipedia.org/wiki/Architecture_Neutral_Distribution_Format https://en.wikipedia.org/wiki/Architecture_Neutral_Distribut... Using ANDF you could produce portable binaries that would run on any UNIX system, regardless of CPU architecture. It was never commercially released though. I think while it is cool technology the market demand was never really there. For a software vendor, recompiling to support another UNIX isn't that hard; the real hard bit is all the compatibility testing to make sure the product actually works on the new UNIX. ANDF solved the easy part but did nothing about the hard bit. It possibly would even make things worse, because then customers might have just tried running some app on some other UNIX the vendor has never tested, and then complain when it only half worked. Standards are always going to have implementation bugs, corner cases, ambiguities, undefined behaviour, feature gaps which force you to rely on proprietary extensions, etc. That's where the "hard bit" of portability comes from.

MaulingMonkey 6y ago

> I realize I've sort of just re-invented Javascript. Or one of several bytecodes that get JIT or AOT compiled. WASM in particular has my interest these days, thanks to native browser support and being relatively lean and more friendly towards "native" code, whereas JVM and CLR are fairly heavyweight, and their bytecodes assume you're going to be using a garbage collector (something that e.g. wasmtime manages to avoid.) Non-web use cases of WASM in practice seem more focused on isolation, sandboxing, and security rather than architecture independence - stuff like "edge computing" - and I haven't read about anyone using it for AOT compilation. But perhaps it has some potential there too?

MaxBarraclough 6y ago
I think the short answer is that the performance penalty is so significant that it doesn't make sense to use WASM unless you're running untrusted code.

saagarjha 6y ago

This sounds a bit like Google’s Portable Native Client.

Wowfunhappy 6y ago
(Which is deprecated now, and scheduled for removal.)

MaxBarraclough 6y ago

> I wish the barriers to using new architectures were lower. > For instance, suppose binaries were typically distributed in a platform-agnostic format, like LLVM intermediate representation or something equivalent. We're doing a pretty good job on portability these days already. Well-written Unix applications in C/C++ will compile happily for any old ISA and run just the same. Safe high-level languages like JavaScript, Java, and Safe Rust are pretty much ISA-independent by definition, it's 'just' a matter of getting the compilers and runtimes ported across. Adopting LLVM IR for portable distribution, probably isn't the way forward. I don't see that it adds much compared to compiling from source, and it's not what it's intended for. (LLVM may wish to change the representation in a subsequent major version, for instance.) For programs which are architecture-sensitive by nature, such as certain parts of kernels, there are no shortcuts. Or, rather, I'm confident the major OSs already use all the practical shortcuts they can think up. > When you run your program the first time, it's compiled to native code for your architecture and cached for later use. Source-based package management systems already give us something a lot like this. There are operating systems that take this approach, such as Inferno. [0] I like this HN comment on Inferno [1]: kernels are the wrong place for 'grand abstractions' of this sort. > I realize I've sort of just re-invented Javascript Don't be too harsh on yourself, JavaScript would be a terrible choice as a universal IR! > [[ to the bulk of your second paragraph ]] In the Free and Open Source world, we're already free to recompile the whole universe. The major distros do so as compiler technology improves. > Processors would be able to compete directly with each other without regard to vendor-lock-in. For most application-level code, we're already there. For example, your Java code will most likely run just as happily on one of Amazon's AArch64 instances as on an AMD64 machine. In the unlikely case you encounter a bug, well, that's pretty much always a risk, no matter which abstractions we use. [0] https://en.wikipedia.org/wiki/Inferno_(operating_system) https://en.wikipedia.org/wiki/Inferno_(operating_system) [1] https://news.ycombinator.com/item?id=9807777 https://news.ycombinator.com/item?id=9807777

elihu 6y ago
> Well-written Unix applications in C/C++ will compile happily for any old ISA and run just the same. Safe high-level languages like JavaScript, Java, and Safe Rust are pretty much ISA-independent by definition, it's 'just' a matter of getting the compilers and runtimes ported across. That sort of works, but duplicating the proper development environment in the end-user's computer would take a lot of space and would be complicated by the enormous variety of programming languages and environments. Linux distros manage this with a lot of effort. I'm imagining something like a universal intermediate representation that can be compiled quickly (because a lot of the early language-specific part of compilation will have already been done by whoever you get your packages from) and in a uniform way because there's a common intermediate representation format that all the compiled languages use. Universal binaries might also be acceptable for commercial, closed-source applications where source distribution would not.

gnufx 6y ago

Surely the barrier to using a new architecture is being able to boot a kernel and run (say) the GNU toolchain, as demonstrated with RISC-V. Then you just compile your code, assuming it doesn't contain assembler, or something. Whether or not you'll have the same sort of board support issues with RISC-V as with Arm, I don't know.

jacquesm 6y ago

> I realize I've sort of just re-invented Javascript. You've re-invented UCSD P-code. https://en.wikipedia.org/wiki/P-code_machine https://en.wikipedia.org/wiki/P-code_machine

brucehoult 6y ago
BCPL ocode is quite a bit older the UCSD P-code. The BCPL compiler always outputs ocode. Then a back end for the particular system statically generates machine code (or assembly language) Back in 1983 I helped take a BCPL running on a VAX and add a M6809 back end to it.
- jacquesm 6y ago
  Ah yes, it even rates a mention on that Wikipedia page. Thank you for pointing this out. 1966! Funny how all these supposedly 'new' concepts really go back all the way to the beginning.
  - pjmlp 6y ago
    Like safe systems languages, first one 1961.

TheRealSteel 6y ago

Isn't that basically what Android Runtime does?

elihu 6y ago
I don't know much about Android specifically. Is it still heavily Java-based? There are a lot of universal-binary candidates both current and historical. Javascript, Java, SPirV, LLVM intermediate representation are some of the current ones. So, this isn't a new idea, it's just that most of the software I use regularly is compiled specifically for x86-64. Maybe it would be better if that were a rare exception rather than the norm.
- pjmlp 6y ago
  Definitely, the use of Linux kernel is a pyrrhic victory only celebrated by those without native Android development experience. NDK's main purpose, from Android team point of view, is for writing native libraries.

grishka 6y ago

You've just reinvented bytecode. JVM/ART, WebAssembly, ActionScript, some versions of .net... You know, all the stuff that supposedly runs on everything.

pabs3 6y ago

> I wish the barriers to using new architectures were lower. Efforts like Bootstrappable Builds and Debian's rebootstrap aim to reduce the barriers for new architectures: https://bootstrappable.org/ https://bootstrappable.org/ https://bootstrapping.miraheze.org/wiki/Main_Page https://bootstrapping.miraheze.org/wiki/Main_Page https://wiki.debian.org/DebianBootstrap https://wiki.debian.org/DebianBootstrap https://wiki.debian.org/HelmutGrohne/rebootstrap https://wiki.debian.org/HelmutGrohne/rebootstrap For eg the Synopsis folks are bootstrapping a Debian ARC port right now using rebootstrap. https://github.com/foss-for-synopsys-dwc-arc-processors/rebootstrap/ https://github.com/foss-for-synopsys-dwc-arc-processors/rebo...

LargoLasskhyfv 6y ago

1989 is calling with a blast from the past: https://en.wikipedia.org/wiki/Architecture_Neutral_Distribution_Format https://en.wikipedia.org/wiki/Architecture_Neutral_Distribut... It didn't last.