By: rwessel (rwessel.delete@this.yahoo.com), March 21, 2021 11:26 am
Room: Moderated Discussions
blaine (myname.delete@this.acm.org) on March 21, 2021 10:10 am wrote:
> Moritz (better.delete@this.not.tell) on March 20, 2021 5:21 am wrote:
> > What if you could completely rethink the general processor concept?
> > There are concepts that were without alternative in the days of little memory and few transistors:
> > Sequential instructions by storage address and jumps based on that address
> > Implicit dependency based on above principle
> > Explicit naming of storage place rather than data item
> > Explicit caching into registers
> > Implicit addressing of registers
> > Mixing of memory, float, integer instructions in one instruction stream
> > that must be analyzed to remove the assumed sequentiallity.
> > The ISA used to represent the physical architecture, today that
> > is no longer the case in high performance microprocessors.
> > The data modifies the program flow at run-time, instead of explicitly generating the data stream
> > that reaches the execution units. The CPU steps through the program issuing the data to EUs instead
> > of the program explicitly generating multiple data streams with synchronization markers.
> > ... and many other implications that are so "natural" to us that we can not see/name them. As usual
> > we can not even question the ways, because we are so used to them. There are infinite bad ways of doing
> > it, but some of those forced/obvious (legacy) design decisions of the past might no longer be that
> > necessary/without alternative. Some ways that seem cumbersome and wasteful might on second thought
> > turn out to be hard on the human, but open new ways to the compiler, RTE, OS, CPU removing as much
> > complexity as they add, but increasing throughput or energy efficiency beyond the current limit.
>
> When goto-less programming came out I envisioned a machine that used the "come
> from" instruction to implement loops" without branches. It needed some other
> instructions for support (e.g. to escape loops). Never went further with it.
Wasn't the come-from instruction/statement defined by a (humorous) Datamation article back in the 70s, as a response to the structured "goto-less programming" proponents.
> Moritz (better.delete@this.not.tell) on March 20, 2021 5:21 am wrote:
> > What if you could completely rethink the general processor concept?
> > There are concepts that were without alternative in the days of little memory and few transistors:
> > Sequential instructions by storage address and jumps based on that address
> > Implicit dependency based on above principle
> > Explicit naming of storage place rather than data item
> > Explicit caching into registers
> > Implicit addressing of registers
> > Mixing of memory, float, integer instructions in one instruction stream
> > that must be analyzed to remove the assumed sequentiallity.
> > The ISA used to represent the physical architecture, today that
> > is no longer the case in high performance microprocessors.
> > The data modifies the program flow at run-time, instead of explicitly generating the data stream
> > that reaches the execution units. The CPU steps through the program issuing the data to EUs instead
> > of the program explicitly generating multiple data streams with synchronization markers.
> > ... and many other implications that are so "natural" to us that we can not see/name them. As usual
> > we can not even question the ways, because we are so used to them. There are infinite bad ways of doing
> > it, but some of those forced/obvious (legacy) design decisions of the past might no longer be that
> > necessary/without alternative. Some ways that seem cumbersome and wasteful might on second thought
> > turn out to be hard on the human, but open new ways to the compiler, RTE, OS, CPU removing as much
> > complexity as they add, but increasing throughput or energy efficiency beyond the current limit.
>
> When goto-less programming came out I envisioned a machine that used the "come
> from" instruction to implement loops" without branches. It needed some other
> instructions for support (e.g. to escape loops). Never went further with it.
Wasn't the come-from instruction/statement defined by a (humorous) Datamation article back in the 70s, as a response to the structured "goto-less programming" proponents.
