Casey Muratori has a talk that I think is interesting and probably a good idea for an angle for forwardcom to target:
The Thirty Million Line Problem
https://www.youtube.com/watch?time_cont ... ZRE7HIO3vk
Casey Muratori talk about what's wrong with modern hardware and OSes
Moderator: agner
-
HubertLamontagne
- Posts: 80
- Joined: 2017-11-17, 21:39:51
Re: Casey Muratori talk about what's wrong with modern hardware and OSes
I agree with his point that today, there is way too many code between nearly any actual function one tries to use.
However, his solution makes it clear he is looking at the problem from a pure consumer point of view. I'm seeing a few disadvantages for an SoC-wide ISA.
First, you would either need every component to be there or make large parts of the ISA optional, therefore wasting much code space in every non-SoC case. That also is why I said that he is looking at the problem from a consumer-perspective.
Second, you trade flexibility for it's simplicity. Want to use an external GPU with the native ISA? You'll propably need an architectural register for this. And so on.
Third, all status information that is currently managed by drivers would have to be built in hardware.
There is propably someone with more insight in this than me, but these are my thoughts so far.
A solution might be to just define a platform as a set of ISAs, with each internal component having his own. This does not solve all the problems, but is does not tie components into a SoC structure. One could use plain x86, ForwardCom or any other CPU ISA for the CPU. However, this would still leave the problem of the glue logic. Also, we would lock ourselves on one architecture for every component, so no more choice between RISC and VLIW for GPUs, for example.
Finally, there is the problem with the architecture itself. I am not aware of an open GPU architecture and know almost nothing about the other components. For an industry-wide standard, it would have to be open.
Finally, I can think of two arguments against all this. One, there is a reason drivers exist in the first place. They not only provide a common interface, but they also manage the hardware they drive. You would need to do all of that in every program. Also, running multiple programs at the same time which all attempt to manage the same hardware would escalate into one big mess.
Second, why would the leading hardware vendor give up their closed architecture? It is the perfect tool to shut out competitors from "their" market. x86 from Intel oder CUDA from Nvidia come to mind.
So bottom line, I can understand the idea, but many things would have to change for it too work, while still having big drawbacks.
However, his solution makes it clear he is looking at the problem from a pure consumer point of view. I'm seeing a few disadvantages for an SoC-wide ISA.
First, you would either need every component to be there or make large parts of the ISA optional, therefore wasting much code space in every non-SoC case. That also is why I said that he is looking at the problem from a consumer-perspective.
Second, you trade flexibility for it's simplicity. Want to use an external GPU with the native ISA? You'll propably need an architectural register for this. And so on.
Third, all status information that is currently managed by drivers would have to be built in hardware.
There is propably someone with more insight in this than me, but these are my thoughts so far.
A solution might be to just define a platform as a set of ISAs, with each internal component having his own. This does not solve all the problems, but is does not tie components into a SoC structure. One could use plain x86, ForwardCom or any other CPU ISA for the CPU. However, this would still leave the problem of the glue logic. Also, we would lock ourselves on one architecture for every component, so no more choice between RISC and VLIW for GPUs, for example.
Finally, there is the problem with the architecture itself. I am not aware of an open GPU architecture and know almost nothing about the other components. For an industry-wide standard, it would have to be open.
Finally, I can think of two arguments against all this. One, there is a reason drivers exist in the first place. They not only provide a common interface, but they also manage the hardware they drive. You would need to do all of that in every program. Also, running multiple programs at the same time which all attempt to manage the same hardware would escalate into one big mess.
Second, why would the leading hardware vendor give up their closed architecture? It is the perfect tool to shut out competitors from "their" market. x86 from Intel oder CUDA from Nvidia come to mind.
So bottom line, I can understand the idea, but many things would have to change for it too work, while still having big drawbacks.