3 ms·
1. LLVM is not portable. PNaCl is trying to make it so, but it's a work in progress. 2. A 'universal' payload with ARM and x86, would just work on them. What i
by azakai 16y ago
1. LLVM is not portable. PNaCl is trying to make it so, but it's a work in progress.
2. A 'universal' payload with ARM and x86, would just work on them. What if in 5 years we have new architectures? Only supporting ARM and x86 would hold back innovation there.
- stcredzero 16y ago1) Yes, it's a work in progress, just like NaCl. 2) You're posing a what-if for 5 years down the road? Your horizon is really that far? Sounds like grasping for straws to me.
- rizzzer 16y agoAre you saying we shouldn't think 5 years ahead? GP was right, including just x86 and ARM is not good enough. Heck it even ignores x86_64 right now, and won't support new SIMD extensions that come out from time to time. Not to mention be a barrier to anyone introducing a new arch, as GP said. Thinking ahead here is vital.
- stcredzero 16y agoThinking ahead is good, but precluding a technology because a particular implementation would have to be changed in 5 years is just flat-out silly for tech. You couldn't ever buy a car with criteria like that. Grasping for straws.
- rizzzer 16y agoThe point is that if you have only x86 and ARM binaries, you can't run them directly on a new architecture. It isn't a matter of changing an implementation. It's like trying to run a C64 binary today. The only practical way is emulation, which is slow - but thankfully fast enough in this case. In general though, it means new architectures will run more slowly than existing ones. That's not a good thing.
- stcredzero 16y agoBy then just recompile it for the next wave of tech/standards.
- rizzzer 16y agoDo you think we still have the source code to all C64 binaries out there? We don't. And in 5 years, we won't have the source to all the stuff we are running now.
- stcredzero 16y agoFine, those things can just die or limp along.