Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.swapon.de!fu-berlin.de!uni-berlin.de!not-for-mail
From: Dennis Lee Bieber <wlfraed@ix.netcom.com>
Newsgroups: comp.lang.python
Subject: Re: (Execution) Termination bit, Alternation bit.
Date: Sat, 19 Dec 2015 21:27:21 -0500
Organization: IISS Elusive Unicorn
Lines: 59
Message-ID: <mailman.63.1450578438.30845.python-list@python.org>
References: <df0ec$56759a3e$d47876e2$54535@news.ziggo.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: list
Xref: csiph.com comp.lang.python:100619

On Sat, 19 Dec 2015 18:56:17 +0100, "Skybuck Flying"
<skybuck2000@hotmail.com> declaimed the following:

>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.
>
	Don't see it here... You've just enabled leaving lots of corrupted data
structures in the system... (Imagine your "termination" branch is taken
after a call that allocated a 500MB block of memory, but before the call
that returns that memory to the system).

	This is why all well-designed multi-thread (and even multi-process --
though processes are typically an OS level entity which can be killed and
all resources reclaimed as they are not in a shared memory space) tend to
rely upon known points of communication and signalling.

	One of the bedrocks of software engineering has been the concepts of
cohesion and coupling. High cohesion: a block (function, etc.) of code is
focused upon a task, not containing bits of stuff involving multiple
unrelated work. Low coupling: blocks are independent of other blocks, with
only a few known points of information transfer -- few, if any,
side-effects, no mysterious globals... They should be black-boxes whose
inner content can be changed without affecting any other code.

	Your externally inflicted bits and jumps violate all of these as they
require outside code to know what the inside looks like to make safe use of
them.

	The "bits" are not the problem, but the uncontrolled/asynchronous
transfer of control is a big problem! The "bits" themselves are nothing
more than a recreation of VMS Event Flags (or even AmigaOS signal bits) --
they can be asynchronously set; but to act upon them requires a synchronous
operation*... That is, some sort of read operation in a loop or at other
known code points at which the code itself can cleanly change its path of
execution.


* I'm ignoring ASTs -- software interrupts -- since they don't cause a
transfer of control of the thread itself; they activate, run quickly, and
return to the point of activation.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/