Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #100613 > unrolled thread

(Execution) Termination bit, Alternation bit.

Back to article view | Back to comp.lang.python

Contents

  (Execution) Termination bit, Alternation bit. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-12-19 18:56 +0100
    Re: (Execution) Termination bit, Alternation bit. Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-12-19 21:27 -0500
    Re: (Execution) Termination bit, Alternation bit. Chris Angelico <rosuav@gmail.com> - 2015-12-20 14:44 +1100
    Re: (Execution) Termination bit, Alternation bit. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-12-20 12:25 +0100
      Re: (Execution) Termination bit, Alternation bit. Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-12-20 11:21 -0500
      Re: (Execution) Termination bit, Alternation bit. eryk sun <eryksun@gmail.com> - 2015-12-20 22:04 -0600
      Re: (Execution) Termination bit, Alternation bit. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-12-21 13:40 +0100
        Re: (Execution) Termination bit, Alternation bit. Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-12-21 12:57 -0500
          Re: (Execution) Termination bit, Alternation bit. Grant Edwards <invalid@invalid.invalid> - 2015-12-21 19:32 +0000
            Re: (Execution) Termination bit, Alternation bit. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-12-29 12:25 +0100
              Re: (Execution) Termination bit, Alternation bit. Steven D'Aprano <steve@pearwood.info> - 2015-12-30 00:22 +1100
                Re: (Execution) Termination bit, Alternation bit. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-12-29 22:43 +0100
                  Re: (Execution) Termination bit, Alternation bit. Chris Angelico <rosuav@gmail.com> - 2015-12-30 11:00 +1100
                    Re: (Execution) Termination bit, Alternation bit. "Skybuck Flying" <skybuck2000@hotmail.com> - 2016-01-03 02:18 +0100
                      Re: (Execution) Termination bit, Alternation bit. Steven D'Aprano <steve@pearwood.info> - 2016-01-03 19:44 +1100
                        Re: (Execution) Termination bit, Alternation bit. "Skybuck Flying" <skybuck2000@hotmail.com> - 2016-01-08 12:59 +0100
            Re: (Execution) Termination bit, Alternation bit. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-12-29 12:42 +0100
        Re: (Execution) Termination bit, Alternation bit. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-12-22 16:46 +0100
          Re: (Execution) Termination bit, Alternation bit. Chris Angelico <rosuav@gmail.com> - 2015-12-23 02:56 +1100
            Re: (Execution) Termination bit, Alternation bit. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-12-29 12:23 +0100
    Re: (Execution) Termination bit, Alternation bit. Rustom Mody <rustompmody@gmail.com> - 2015-12-29 20:07 -0800
      Re: (Execution) Termination bit, Alternation bit. Steven D'Aprano <steve@pearwood.info> - 2015-12-30 23:56 +1100
        Re: (Execution) Termination bit, Alternation bit. Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-12-30 12:19 -0500

Page 2 of 2 — ← Prev page 1 [2]

#100979

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.

[toc] | [prev] | [next] | [standalone]

#100988

On Wed, 30 Dec 2015 03:07 pm, Rustom Mody wrote:

> 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. 
[...]

Rustom, your quote was (I trust inadvertently!) horribly misleading. I
thought this was said by Dijkstra, not some random crank on the Internet.

The comment from some random person Cleo Saulnier, who starts off with the
provocative comment that the *subroutine* is the "the absolute worst
programming construct", then goes on to sing the praises of Unix pipes.
What are small Unix programs communicating via pipes if not subroutines?

Functions are subroutines, but not all subroutines are functions.

It is fashionable to dismiss 1970s-style BASIC as a serious language, and
for good reason, but let's not forget that for all its problems, a large
number of programmers cut their teeth on it. BASIC is, in some ways, like a
machine language except with a friendly syntax. There are subroutines, but
you can jump into the middle of them, or out from the middle. There are no
functions, just jumps to the instruction you want to execute next. Only a
limited set of data types to work with.

I think every programmer would learn something from trying to write, and
maintain, an actual useful piece of code using only a BASIC-like language.
At the least, they would appreciate what a huge step-up it was to introduce
procedural programming.

(A friend of mine once worked under a manager who insisted that writing
functions and procedures was a terrible idea, that GOTO was vital, because
it was far more efficient to jump to a line of code than call a function.
And this was in the late 1990s.)

Cleo continues:

> 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.

This is a remarkable claim, considering that one of the advantages of the
function is that it can, when used correctly, *reduce* coupling.

In non-procedural code, any line of code may be used by any other chunk of
code. You can jump to any line, and people did (because they had no
alternatives), consequently coupling was very high.

In procedural code, any line of code can only be reached from exactly one
place: the previous line of code. (Well, a few more, in specialised
circumstances: for- and while-loops, branches, etc.) Lines of code *within*
a procedure can only couple with other lines within the same procedure;
it's true that procedures can have high-coupling or low-coupling, but at
least you know that you can change the inside of a procedure as much as you
want, and so long as it accepts the same input and generates the same
output (and has the same side-effects) it will continue to work. That's
reduced coupling.


> 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.

That's arguable. When I learned about Unix multi-processing, it was based on
a single CPU model: each process would run for a few ticks, before being
interrupted by the OS and the next process being allowed to run for a few
ticks. A sequential process that merely appeared to be parallel because the
CPU was so fast. Perhaps these days Unix is capable of actually running
multiple programs in parallel on separate cores or multiple CPUs?

As I said earlier, of course Unix programs communicating via pipes are a
kind of subroutine. We also have generators, and coroutines, and threads,
and other forms of parallel processing. The unsurprising reality is that
such kinds of code are *harder* to get right than functions with their
simple-minded stack-based sequential execution model.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#101004

On Wed, 30 Dec 2015 23:56:41 +1100, Steven D'Aprano <steve@pearwood.info>
declaimed the following:

>I think every programmer would learn something from trying to write, and
>maintain, an actual useful piece of code using only a BASIC-like language.
>At the least, they would appreciate what a huge step-up it was to introduce
>procedural programming.
>
	Well -- it wasn't "useful" being just a class assignment, but the
instructor of the data structures/algorithms class permitted us to use any
language he could understand for an assignment.

	I did use a 70s era BASIC for it. Got fun as the system only allowed
for four open files at a time... And I made use of the CHAIN LINK command
to load the main operational functions as separate programs... The
assignment: a hashed head multiple linked list. Something I've only seen in
one place since then -- the file system of the Amiga.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.python

csiph-web