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. -- https://mail.python.org/mailman/listinfo/python-list
