By: Etienne Lorrain (etienne_lorrain.delete@this.yahoo.fr), March 22, 2021 2:22 am
Room: Moderated Discussions
Like other have pointed to, microthread could be used, I would propose very simple form of it, without much modification.
I mean, usual software only have an IPC in between 0.5 and 2, far lower than the theoretical maximum. Even hyper-threading cores seem to quite often have the two threads waiting.
IHMO we could have an explicit, hardware supported, background microthread. The OoO CPU would reserve around 20 in-flight instructions for it (out of its 100 in-flight instructions).
So if the main program flow is stopped (waiting for memory reads), the background microthread would be run.
I would imagine that "background microthread" being very limited, not able to do system call or change rings - but it would be sufficient to do things like pre-zeroing the next memory allocation (always running in the memory context of the main application).
It would be implemented by a single "background program counter" and a set of registers (maybe the smallest set), so that a "rep stosb" can be done.
I think it would also be "optionally run", so the main application would not require anything, just the memory allocator would provide pre-zeroed blocks if there were some available, else it would zero those blocks itself. More complex uses of such background microthread could be found over time, like balancing binary trees.
On a more complete redesign of a processor, I would easily "type" the registers of the processor (as I have said in old threads), i.e. have assembly instructions to change the type of each registers at run time.
I imagine processor registers could have types like:
- simple byte/word/long or any fixed number of bits like all processors
- pointer to memory (probably 64 bits), maybe with read-only/write-only/read-write distinction (would help cache prefetch for read or write at value initialisation)
- Integer/unsigned which would saturate on overflows, or bitmasks types
- floating point of fixed number of bits
- vector of byte/word/long/floats...
At least it would reduce the number of instructions (addb, addw, addl, ...), clearly define when a register is live or dead, and give more context to the core executor. At first one could fix all registers being 64 bits to use standard current compilers, and implement other types slowly, one at a time.
I mean, usual software only have an IPC in between 0.5 and 2, far lower than the theoretical maximum. Even hyper-threading cores seem to quite often have the two threads waiting.
IHMO we could have an explicit, hardware supported, background microthread. The OoO CPU would reserve around 20 in-flight instructions for it (out of its 100 in-flight instructions).
So if the main program flow is stopped (waiting for memory reads), the background microthread would be run.
I would imagine that "background microthread" being very limited, not able to do system call or change rings - but it would be sufficient to do things like pre-zeroing the next memory allocation (always running in the memory context of the main application).
It would be implemented by a single "background program counter" and a set of registers (maybe the smallest set), so that a "rep stosb" can be done.
I think it would also be "optionally run", so the main application would not require anything, just the memory allocator would provide pre-zeroed blocks if there were some available, else it would zero those blocks itself. More complex uses of such background microthread could be found over time, like balancing binary trees.
On a more complete redesign of a processor, I would easily "type" the registers of the processor (as I have said in old threads), i.e. have assembly instructions to change the type of each registers at run time.
I imagine processor registers could have types like:
- simple byte/word/long or any fixed number of bits like all processors
- pointer to memory (probably 64 bits), maybe with read-only/write-only/read-write distinction (would help cache prefetch for read or write at value initialisation)
- Integer/unsigned which would saturate on overflows, or bitmasks types
- floating point of fixed number of bits
- vector of byte/word/long/floats...
At least it would reduce the number of instructions (addb, addw, addl, ...), clearly define when a register is live or dead, and give more context to the core executor. At first one could fix all registers being 64 bits to use standard current compilers, and implement other types slowly, one at a time.