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

Here is an idea:

1. The computer program issue's load and store requests to the memory
system.

Instead of only specifieing the memory address, the computer program would
also specifiy the instruction pointer.

2. The memory system fetches the memory located at the memory address and
returns it but it also returns the instruction pointer.

3. Because the instruction pointer is returned, this allows the computer
program to go back to the instruction that was "stalled" or "skipped".

4. This would allow the computer program to issue memory requests, but not
have to wait for them. The computer program would jump back to the
instruction location once it's memory
has been retrieved. This would allow the computer program to simply move
on/go on with executing other instructions and potentially retrieving other
memory locations.

For example:

Load
Load
Load
Load
Load
Load

^ All these instructions specify an memory address, but also specify the
instruction pointer to main memory, and also specify a register where to
load the memory into.

The question is now:

What to do with other instruction which depend on the registers to be "live"
/ "filled" with data.

Well perhaps these instructions could all check a "flag" inside the
register.

If the register is "live" the instructions get executed. If the register is
"dead" (/"stalled") the instruction is skipped.

This would allow a programmer to program a lot of semi-parallel code which
gets or gets not executed depending on if the memory came in...

The program would then simply jump back at appriorate times... when the
memory comes in... like an interrupt handler or like an exception handler.

So this is probably a totally new instruction flow idea.

Finally if the memory loading takes so long that the program cannot do
anything anymore then the programmer could issue a wait:

Like so:

wait

The processor would then either wait for all loads to complete or some other
interrupts to occur.

So another way to describe this system would be a really short abstract way:

"An event driven memory system".

Bye,
Skybuck.

"Flying Bucket" posted one more _new_ idea

> Here is an idea:
>
> 1. The computer program issue's load and store requests to the memory
> system.
>
> Instead of only specifieing the memory address, the computer program would
> also specifiy the instruction pointer.
>
> 2. The memory system fetches the memory located at the memory address and
> returns it but it also returns the instruction pointer.
>
> 3. Because the instruction pointer is returned, this allows the computer
> program to go back to the instruction that was "stalled" or "skipped".
>
> 4. This would allow the computer program to issue memory requests, but not
> have to wait for them. The computer program would jump back to the
> instruction location once it's memory
> has been retrieved. This would allow the computer program to simply move
> on/go on with executing other instructions and potentially retrieving
> other memory locations.

All this issues are already covered/implemented in x86 architectures,
OoO features exist there since a while (>10 years).
__
wolfgang

On Jul 22, 9:06*am, "wolfgang kern" <nowh...@never.at> wrote:

> All this issues are already covered/implemented in x86 architectures,
> OoO features exist there since a while (>10 years).

Indeed. If one is going to add something to the machine language,
generally speaking it would be something that allows instructions to
execute fully in sequence without delays. So instead of going back to
an instruction that requested data from memory, there would be
instructions that made a request, and later instructions that used the
data.

John Savard

Quadibloc wrote:
> On Jul 22, 9:06 am, "wolfgang kern" <nowh...@never.at> wrote:
>
>
>>All this issues are already covered/implemented in x86 architectures,
>>OoO features exist there since a while (>10 years).
>
>
> Indeed. If one is going to add something to the machine language,
> generally speaking it would be something that allows instructions to
> execute fully in sequence without delays. So instead of going back to
> an instruction that requested data from memory, there would be
> instructions that made a request, and later instructions that used the
> data.
>
> John Savard
Guess that is why they have cache !


Jamie

"wolfgang kern" wrote in message news:j0c3m5$ebr$...


"Flying Bucket" posted one more _new_ idea

> Here is an idea:
>
> 1. The computer program issue's load and store requests to the memory
> system.
>
> Instead of only specifieing the memory address, the computer program would
> also specifiy the instruction pointer.
>
> 2. The memory system fetches the memory located at the memory address and
> returns it but it also returns the instruction pointer.
>
> 3. Because the instruction pointer is returned, this allows the computer
> program to go back to the instruction that was "stalled" or "skipped".
>
> 4. This would allow the computer program to issue memory requests, but not
> have to wait for them. The computer program would jump back to the
> instruction location once it's memory
> has been retrieved. This would allow the computer program to simply move
> on/go on with executing other instructions and potentially retrieving
> other memory locations.

"
All this issues are already covered/implemented in x86 architectures,
OoO features exist there since a while (>10 years).
"

I don't think so...

I have never seen x86 processors execute instructions and then later go back
to previous instructions

I might do this underneath, but I have never seen a debugger jump back =D

Bye,
Skybuck