(Execution) Termination bit, Alternation bit.

[Skybuck Flying]

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.

[Skybuck Flying]

"Richard Damon" wrote in message news:QHody.3724$Bz5....@fx04.iad...

On 12/19/15 9:03 PM, Skybuck Flying wrote:

> It could be usefull if the instruction pointer/return address that was
> pushed onto the stack when the interrupt handler was called can be
> modified by the interrupt handler so that when it returns the modified
> instruction pointer is popped from the stack.
>
> This would assume:
>
> 1. To be interrupted processor pushed it's own instruction pointer onto
> the stack.
> 2. To be interrupted processor pops it's own instruction pointer from
> stack.
>
> Bye,
> Skybuck.

"
It would be an unusual machine where you couldn't modify the return
address on the stack to change the address you return to.
"

This does make me wonder how Windows 7 terminates threads/processes/hanging
applications.

Apperently there is some kind of mechanism for this.

Perhaps it's not fully exposed to application developers or perhaps in a
somewhat more complex way via all kinds of APIs ?

An example of how to terminate threads/processes instantly on Windows 7
could be interesting.

Bye,
Skybuck.

[fir]

this may be good idea, but to be honest i did not do much read-in into this..
for sure i also opt for simple hardware solutions that will cover a lot of software trouble.. but i am also far for understanding todays software ground esp in
the area of core 'intercomunications'

[Chris M. Thomasson]

> "Skybuck Flying" wrote in message
> news:d8c28$56769027$d47876e2$58...@news.ziggo.nl... wrote:

[...]

> This does make me wonder how Windows 7 terminates
> threads/processes/hanging applications.

> Apperently there is some kind of mechanism for this.

Take a look at the (pthread_cancel()) function wrt async in:

https://www.sourceware.org/pthreads-win32/

IIRC, they use a special diver to queue a kernel mode APC for cancellation.

I think they fall back to Suspend/ResumeThread API if the driver is not
present.

[Skybuck Flying]

The original idea I posted is less about sending a signal to another
processor.

It is more about how to break out of an instruction sequence.

Example of problem:

Main:
while Condition1 do
begin
while Condition2 do
begin
while Condition3 do
begin
Routine1
end
end;
end;

Routine1:

while Condition4 do
begin
while Condition5 do
begin
Routine2:
end;
end;

Routine2:

while Condition6 do
begin
while Condition7 do
begin

end;
end;

Breaking out of these kinds of loops, routines, code currently requires
something like:

Current cumbersome solution for problem:

Main:
while Condition1 and not Terminated do
begin
while Condition2 and not Terminated do
begin
while Condition3 and not Terminated do
begin
Routine1
end
end;
end;

Routine1:

while Condition4 and not Terminated do
begin
while Condition5 and not Terminated do
begin
Routine2:
end;
end;

Routine2:

while Condition6 and not Terminated do
begin
while Condition7 and not Terminated do
begin

end;
end;

It can take a long while before all this code exits, plus the Terminated
boolean is probably placed on wrong side.

It should be on the left side in case the Conditions are actual functions
otherwise those would unnecessarily be executed as well.

Having something that can immediatly exit all of this code would be a nice
feature to have.

Perhaps something like an exception block, perhaps it could be called a
termination block.

Routine1:
Result = False

Execute
while True do
begin

end;
Result = True
Termination
OnTerminate:
begin

end;
end;

return Result

Preferrably , optionally this can be omitted/left out.

Bye,
Skybuck.

[Skybuck Flying]

"Richard Damon" wrote in message news:QXSdy.6634$QG6....@fx31.iad...

On 12/21/15 7:40 AM, Skybuck Flying wrote:
> The original idea I posted is less about sending a signal to another
> processor.
>
> It is more about how to break out of an instruction sequence.
>
> Example of problem:

[snip]
> Bye,
> Skybuck.

"
The issue is that if your threads are doing real work, the cleanup
needed at each point keep the environment clean for other threads likely
varies. Just arbitrarily stopping or blindly going off to something else
is very apt to create problems.

Some languages can be better at automatically cleaning up for you, these
will tend to be languages that support some form of exception
processing, as that tends to need similar support. You abort can be
treated as a type of exception that is automatically thrown when signaled.

The problem here is that most programs, while they can handle exceptions
in many spots, have some spots where exceptions will cause problems,
especially in code that is directly managing the resources. Thus, you
still need to have some definition of where to check for the breaks.
"

I can imagine that arbitrarily terminating somewhere can lead to problems
for example in memory clean up code, where then memory leaks might occur.

Though applications do sometimes seem to clean up anyway.

One idea which immediatly comes to mind to fix this problem is to offer a
"PushTerminationFlag" onto stack and then a "ClearTerminationFlag"
instruction.

Then a code section can be executed without breaking or terminating.

Once that's done the code would then call "PopTerminationFlag".

At least this offers some protection against arbitrarely breaking code
sections.

Bye,
Skybuck.

[fir]

W dniu sobota, 19 grudnia 2015 18:56:41 UTC+1 użytkownik Skybuck Flying napisał:

arnt the computers today use some mechanism like that, i mean interrupts?

i do not quite understand the difference..
also i learned on interrupts in 90-ties..
there source for interrupts might be a timer
that camn break app execution move control
to the kernel when kernel code could store
execution state and give it back to the another one... in those times there was no other core that could interrupt other cores

not sure if those 2 bits will makeenhancement on the interrupt mechanism that is afaik still used 9and i dont know if it is used to core communication, i was even asking on this somewhere as i was curious how cores communicate today (suspected that by interrupts, though they also could communicate thru ram and locks, i dont see it to much))

[Kaz Kylheku]

On 2015-12-19, Skybuck Flying <skybu...@hotmail.com> wrote:
> The idea is also that Thread A could influence Thread B to start executing a
> different path.

It's as if you racked you brain for hours to come up with an elaborate
way of convincing the reader that you have zero experience in production
concurrent programming.