By: gallier2 (gallier2.delete@this.gmx.de), March 22, 2021 12:49 am
Room: Moderated Discussions
rwessel (rwessel.delete@this.yahoo.com) on March 21, 2021 11:26 am wrote:
> 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.
Yes, it was April 1st joke, that's why it was implemented in the Intercal language. It is even the venue for multi-threading.
> 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.
Yes, it was April 1st joke, that's why it was implemented in the Intercal language. It is even the venue for multi-threading.