(Execution) Termination bit, Alternation bit.

[Rustom Mody]

On Saturday, December 19, 2015 at 11:26:55 PM UTC+5:30, Skybuck Flying wrote:
> Hello,
> 
> I'd like to see instruction execution enhanced with the following two ideas:
> 
> 1. A termination bit, and a terminator pointer.
> 2. A alternation bit, and a alternate pointer.
> 
> The purpose of these bits is as follows:
> 
> Before a processor/core executes an instruction both bits are examined.
> 
> 1. If the termination bit is set the instruction is not executed and instead 
> the processor sets the instruction pointer to the termination pointer.
> 2. If the alternation bit is set the instruction is not executed and instead 
> the processor sets the instruction pointer to the alternation pointer.
> 
> The idea behind this is support multi threading/parallelism better.
> 
> The idea is that Thread A could terminate Thread B immediately so that 
> Thread B does not continue execution.
> The idea is also that Thread A could influence Thread B to start executing a 
> different path.
> 
> Hopefully these bits are enough for operating systems to add support for 
> this. Some issues remaining could be items pushed on the stack.
> Perhaps operating system can deal with that, or perhaps compiler or perhaps 
> some other special instructions or software methods can be added.
> Hopefully operating systems can include data structures per thread that can 
> be loaded into the core, and into these bits and pointers so that it becomes 
> active.
> During a context switch these bits and pointers should be loaded 
> accordingly.
> So these two bits and these two pointers become part of the context.
> 
> I think these two features would be usefull to make multi-threading more 
> responsive and faster reaction time to changes/events occuring.
> 
> (Eventually it would be nice if these low level features would end up in 
> high level languages like Python ;))
> 
> Bye,
>   Skybuck.

By some coincidence was just reading:
from http://www.wordyard.com/2006/10/18/dijkstra-humble/

which has the following curious extract.
[Yeah its outlandish]

----------------------------------------------
I consider the absolute worst programming construct to be
subroutine or the function. We've used it for over 50 years now
and we're still having difficulty reducing complexity. What if
the unthinkable were true? What if the subroutine was the cause
of all our problems? I can prove how the subroutine causes all
parts of our software to become coupled and as such cannot
support this as the basic building blocks of software.

I find the subroutine and all the technology around it (OOP,
functional, AOP, etc.) are like a sinking ship where you keep
throwing more lifeboats when what you really need is a new
boat. (The ship being the subroutine and the lifeboats are OOP,
funcional, AOP, etc.).

I posit a fourth "condition" for being able to produce better
software and that is being able to recognise what specifically
isn't working and be ready to ditch it. I see no indication of
this for at least another 20 or 70 years give or take 100 years.

Computing Industry's Best Kept Secret: The function is *NOT*
necessary to build software and may in fact be a bad tool.

:
:

[In response to questions of whats the answer to functions]

With functions, it's stack based. You have to wait until the
function returns in order to process the next function unless
it's an internal function. This is the first in, last out rule
just like a stack. I don't mean that functions are bad in of
themselves for certain things. I mean that maybe they're not the
*only* way. Just like different data structures have different
uses. Right now, everyone is using the function. Imagine if the
stack was the only data structure you could use. What a horrible
world. Yet this is what we have with the function.

Unix has pipes. These are queues. As data is piped, software on
both ends of the queue can execute at the same time. As data
passes from one end of the queue to the other, there is no
concept of execution point. Only data transformations and
transfers. Another example is the Internet where messages (real
ones) get passed back and forth. Simple idea that scales and is
in active use.

We've look into the stack based way of programming to
death. Maybe the queue or other data processing model can be
looked at, especially to solve concurrency. I feel it's a shame
that there are perfectly acceptable tools available that get
sidelined for the status quo.

BTW, history dictates that the function is not reusable. Well,
maybe it's reusable like sand is reusable to build glass. Once
it's actually used, it is forever transformed into something else
that can no longer be separated from the whole.