An idea how to speed up computer programs and avoid waiting. ("event driven memory system")

Hmm,

One possible problem with this idea is the following:

load
load
load
load * hit
load
load
load

some other instruction
some other instruction
some other instruction
some other instruction * proceed
some other instruction
some other instruction

The * hit indicates that it's memory has arrived. Now the problem is all the
other instructions. With this sequential programming pattern it would need
to skip over all other instructions to finally arrive at * proceed.

That's a lot of wastefull skipping/no operations.

One possible solution could be to allow the programmer to specify which
instruction to execute next

load register 4 proceed some other instruction 4.

But this is probably pushing it a bit

So maybe it is better to split up the program into seperate pieces, that way
the programmer only has to program one piece/kernel like in cuda.

Which automatically gets duplicated/repeated and so forth.

But then the problem is: even single threads stall.

The idea is to let the load instruction continue even while no data present
to hopefully execution something else.

So all those loads and some other instructions could also be replaced by
some calculations or so...

So perhaps some merit in this idea

Bye,
Skybuck.

Perhaps even a new branching instruction like so, pseudo code idea:

if load then
begin
perform operation on loaded data
end else
begin
do something else while loading.
end;

The if branch would execute if the load completed.

The else branch would execute if the load is still pending.

Bye,
Skybuck.

I am not totally happy with this posting, but gonna post it anyway,
otherwise it would probably be lost in oblivion

(At least now it's in my outlook express archive potential issue's could
be with correct program order/operations I++; I=I+SomeField; I++ - may not
execute until somefield is retrieved.)

Hmm,

One possible problem with this idea is the following:

load
load
load
load * hit
load
load
load

some other instruction
some other instruction
some other instruction
some other instruction * proceed
some other instruction
some other instruction

This idea isn't even that bad... instead of letting the programmer specify
the relations between the instructions, the compiler could also figure this
out.

The compiler for example could figure out the "some other instruction *"
relies on "load * hit" and therefore the compiler can fill in the "next
instruction pointer" inside the load instruction.

One little problem is introduced with this idea which would be nice to solve
as well:

The sequential order of the code should be respected.

Another bit could be used inside the load instruction or perhaps somewhere
in data to indicate if the next instruction is already executed or not.

If it was not yet executed it would first be executed... it could continue
doing this until all instructions are executed and " * proceed" is
encountered naturally. Or it could keep track of the next "jump to on stall
pointer".

The processor would store the "next instruction pointer" located at "load *
hit" into the "jump to on stall pointer register".

Then when the processor is about to stall/wait it won't let that happen and
instead check the "jump to on stall pointer register" if it's filled and/or
a flag is set to indicate that it has not been jumped to... then the
processor can jump to that instruction to execute there next...

This does screw up the instruction flow somewhat.

But a whole new kind of compiler and a whole new kind of instructions and
instruction flow paradigm could be created where each instruction indicates
via flags or registers or something on which other instructions it depends.

It doesn't need to specify all. It should only specify the minimum
requirement... this could also include data fields.

Other instructions could reset these flags to indicate that these fields are
to be reloaded, like load instructions.

Bye,
Skybuck.

On 07/22/11 10:23, Skybuck Flying wrote:
Hmm,

One possible problem with this idea is the following:

load
load
load
load * hit
load
load
load

some other instruction
some other instruction
some other instruction
some other instruction * proceed
some other instruction
some other instruction

The * hit indicates that it's memory has arrived. Now the problem is all
the other instructions. With this sequential programming pattern it
would need to skip over all other instructions to finally arrive at *
proceed.

That's a lot of wastefull skipping/no operations.

One possible solution could be to allow the programmer to specify which
instruction to execute next

IBM's 650 computer used this design, i.e., an instruction contained the
address of the next instruction for execution, which lead to an early
assembler (for want of a better term), called SOAP (Symbolic Optimizing
Assembly Programming). The optimizing here was for the machine's
magnetic drum memory (pre core days), like optimizing disk access.

Such a design does not conform to von Neumann's model, in which the next
instruction to be executed is the next sequential instruction unless
*something* causes it to be otherwise, e.g., a branch or jump instruction.

But who knows, maybe it's an idea whose time has come back?

On Jul 23, 3:09*am, Tony Harding wrote:

IBM's 650 computer used this design, i.e., an instruction contained the
address of the next instruction for execution, which lead to an early
assembler (for want of a better term), called SOAP (Symbolic Optimizing
Assembly Programming). The optimizing here was for the machine's
magnetic drum memory (pre core days), like optimizing disk access.

Such a design does not conform to von Neumann's model, in which the next
instruction to be executed is the next sequential instruction unless
*something* causes it to be otherwise, e.g., a branch or jump instruction..

But who knows, maybe it's an idea whose time has come back?

The difference between how drum memory computers worked and a von
Neumann computer with random-access memory is generally considered to
be a trivial one which doesn't impact the programming model.

John Savard