smells like linus thinks there is going to be an ever increasing tech debt, and honestly, i think i agree with him on that one.
RISCV is likely going to eventually overstep it’s role in someplaces, and bits and pieces of it will become archaic over time.
The gap between hardware and software level abstraction is huge, and that’s really hard to fill properly. You just need a strict design criteria to get around that one.
I’m personally excited to see where RISCV goes, but maybe what we truly need is a universal software level architecture that can be used on various different CPU architectures providing maximum flexibility.
but maybe what we truly need is a universal software level architecture that can be used on various different CPU architectures providing maximum flexibility.
Then again, if you don’t have the JVM/JRE, Java won’t work, so first you need to write it in another language and in such a way that it works across a bunch of different ARM and x86 processors.
software level architecture that can be used on various different CPU architectures providing maximum flexibility.
I’ve only done a little bare metal programming, but I really don’t see how this is possible. Everything I’ve used is so vastly different, I think it would be impossible to create something like that, and have it work well.
theoretically you could do it by defining an architecture operations standard, and then adhering to that somewhat when designing a CPU. While providing hardware flexibility as you could simply, not implement certain features, or implement certain other features. Might be an interesting idea.
That or something that would require minimal “instruction translation” between different architectures.
It’s like x86. except if most of the features were optional.
It sounds like you’re just reinventing either the JVM (runtime instruction translation), compilers (LLVM IR), or something in between (JIT interpreters).
The problem is that it’s a hard problem to solve generally without expensive tradeoffs:
interpreter like JVM - will always have performance overhead and can’t easily target arch-specific optimizations like SIMD
compiler - need a separate binary per arch, or have large binaries that can do multiple
JIT - runtime cost to compiling optimizations
Each is fine and has a use case, but I really don’t think we need a hardware agnostic layer, we just need languages that help alleviate issues with different architectures. For example, Rust’s ownership model may help prevent bugs that out of order execution may expose. It could also allow programmers to specify more strict limits on types (e.g. non-zero numbers, for example), which could aid arch-specific optimizations).
smells like linus thinks there is going to be an ever increasing tech debt, and honestly, i think i agree with him on that one.
RISCV is likely going to eventually overstep it’s role in someplaces, and bits and pieces of it will become archaic over time.
The gap between hardware and software level abstraction is huge, and that’s really hard to fill properly. You just need a strict design criteria to get around that one.
I’m personally excited to see where RISCV goes, but maybe what we truly need is a universal software level architecture that can be used on various different CPU architectures providing maximum flexibility.
I think that’s called Java.
Or Emacs
Then again, if you don’t have the JVM/JRE, Java won’t work, so first you need to write it in another language and in such a way that it works across a bunch of different ARM and x86 processors.
I don’t know, if your platform doesn’t have a jre… Is it really a platform?
Dunno, would you consider the Xbox or Playstation platforms?
but but, minecraft in java bad and stinky??
But Java is the good version of Minecraft…
unfortunately, you’re aren’t wrong.
I’ve only done a little bare metal programming, but I really don’t see how this is possible. Everything I’ve used is so vastly different, I think it would be impossible to create something like that, and have it work well.
theoretically you could do it by defining an architecture operations standard, and then adhering to that somewhat when designing a CPU. While providing hardware flexibility as you could simply, not implement certain features, or implement certain other features. Might be an interesting idea.
That or something that would require minimal “instruction translation” between different architectures.
It’s like x86. except if most of the features were optional.
It sounds like you’re just reinventing either the JVM (runtime instruction translation), compilers (LLVM IR), or something in between (JIT interpreters).
The problem is that it’s a hard problem to solve generally without expensive tradeoffs:
Each is fine and has a use case, but I really don’t think we need a hardware agnostic layer, we just need languages that help alleviate issues with different architectures. For example, Rust’s ownership model may help prevent bugs that out of order execution may expose. It could also allow programmers to specify more strict limits on types (e.g. non-zero numbers, for example), which could aid arch-specific optimizations).
yeah pretty much. The JVM but marginally less skill issued lol.
Oh we already have dozens of those haha