5 ms·
RISC-V is dominated by American companies. They could be a part of sanctions as well. I think the Chinese will continue with ARM short term and then create a C
by throwaway4good 6y ago
RISC-V is dominated by American companies. They could be a part of sanctions as well.
I think the Chinese will continue with ARM short term and then create a Chinese-dominated alternative.
From an operating systems point of view I would go for an intermediate language (similar to .NET or Java bytecode) that I also could do some on-the-fly verification of and only have very little compiled for the actual cpu (at least beyond dedicated embedded systems).
Being forced to redo the full stack from processors to end-user OS and cloud services gives a possibility to let go of a lot legacy and pursue some ideas that have been "cutting-edge research" in CS for years.
- throwaway4good 6y agoCombining the ideas here: https://consumer.huawei.com/en/press/news/2019/huawei-launches-harmonyos/ https://consumer.huawei.com/en/press/news/2019/huawei-launch... With say: https://webassembly.org https://webassembly.org And the actual instruction set of the CPU doesn't matter that much.
- nix23 6y ago>RISC-V is dominated by American companies. Really? Have a look at the Premier members: https://riscv.org/ https://riscv.org/
- throwaway4good 6y agoOk, maybe not quite fair but the point is that they risk the same sanctions as for ARM.
- nix23 6y ago>RISC-V International is a global nonprofit association based in Switzerland. Founded in 2015 as the RISC-V Foundation with 29 members, RISC-V is now a truly global organization with over 200 member organizations in more than 30 countries, plus over 300 individual members worldwide. It's not based in the US, and its under the BSD License.
- throwaway4good 6y agoThe instructions set is open source but all the supporting companies probably have to follow a US sanctions regime.
- throwaway4good 6y agoHere is a blog speculating how open source could be covered by the US sanction regime as well: https://www.bunniestudios.com/blog/?p=5590 https://www.bunniestudios.com/blog/?p=5590 Open Source Could Be a Casualty of the Trade War When I heard that ARM was to stop doing business with Huawei, I was a little bit puzzled as to how that worked: ARM is a British company owned by a Japanese conglomerate; how was the US able to extend its influence beyond its citizens and borders?
- sudosysgen 6y agoIf the US wants to sanction OSS out of existence, it's their loss.
- nix23 6y agoIt's not even possible, how does the US want to make that?
- sudosysgen 6y agoHave you read the link in the comment in replying to? The US is considering banning the use of OSS if some Chinese entities participated.
- krageon 6y agoIt's kind of galling that this isn't even the dumbest thing I've heard the US contemplate recently. We're living in really weird times.
- 6y ago
- MaxBarraclough 6y ago> From an operating systems point of view I would go for an intermediate language (similar to .NET or Java bytecode) that I also could do some on-the-fly verification of and only have very little compiled for the actual cpu (at least beyond dedicated embedded systems). There are technical reasons we don't already have a 'universal bytecode' like this. One of them is that it doesn't fit the build model of C and C++. C deliberately doesn't shield the programmer from all details of the underlying architecture, and neither does C++. For instance, the values of sizeof(long) and LONG_MAX depend on the platform, and must be known at compile-time. This is the reason LLVM bitcode cannot be used as an intermediate representation for C programs the way Java bytecode is an IR for Java programs. IRs are already widely used where they make good technical sense. Java, .Net, Python, Lua, and Erlang, each define their own. None of them would work well as a universal intermediate representation. Programs for the Inferno operating-system used a bytecode representation, but modern OSs don't tend to offer 'grand abstractions' like this. See this wise comment from 2015: https://news.ycombinator.com/item?id=9807777 https://news.ycombinator.com/item?id=9807777
- throwaway4good 6y agoWebAssembly is an example of an IL that it is supported by many languages. It solves a lot of problems related to distribution of software and migration between different processor architectures. The Huawei Harmony OS is already touting its verification and how it lets a lot of user code run in the kernel process. Add some just in time compilation and it would be quite a thing.
- my123 6y agoSingularity and Midori existed too. + WebAssembly just isn't efficient for translating quite some patterns to it, at least at this point, with a quite significant perf decrease. (yes, it's better than JS in general, but that's not saying much)
- pjmlp 6y agoSure it does, mainframe language environments and .NET have long supported C and C++. Back in the J2ME days there was a Swedish startup trying to sell a C and C++ version of what was basically a competitor to J2ME. The only reason why LLVM bitcode doesn't do this is political, meaning the LLVM designers don't want to follow down this path.