Also came across Reactors, where there are no functions, channels, methods or services.  Only data, states and relations.  Services are provided by requesting a state change.  An interesting read indeed.

How will this all tie in with Unununium? no idea!  But if you put together multicore, OpenCL, CUDA, and all the multiprocessing going on nowadays, you can start formulating an idea.  Have fun!

Here’s the scoop; the standard methods used in C and other languages are far from being the most efficient, even the ones we used in past Unununium implementations could be optimized further.  Here’s how to do it.

First it is important to understand how a cpu is processing instructions. Even before an instruction is executed, a prefetch queue is filled with the next few instructions to execute.  The CPU constantly analyzes if instructions can be piped in parallel and if it can pre-determine the result of a conditional jump prior to reaching that point.  When the CPU takes a wrong guess, this prefetch queue has to be flushed (emptied) causing some delays in execution.

A standard call implementation such as those found in C and typical languages, uses a return value to indicate if an error occured; such as returning -EOF when performing a fread() to indicate the End Of File has been reached.  The program calling the fread procedure (should) always check if the number of bytes read is equal to -EOF or some other error condition; this check takes some cpu cycles to execute and requires a conditional jump which in turn could be wrongly guessed by the CPU and cause a flush of the prefetch queue.

Newer processors and languages allow some flags to be inserted before the conditional jump to indicate what is the most likely outcome to help the processor take the right guess; if something happens and the condition is not matching the typical case the cpu will still have to go thru a prefetch queue flush.

A method exists to alleviate and reduce the number of comparisons required after a function call; not returning the status of the operation at all!  While this may sound counter productive, it is actually quite efficient and allows for proper error handling.  Here’s a snippet of assembly code to demonstrate a procedure call:
…
jmp short .perform_file_read
dd .invalid_file
dd .end_of_file_reached
.perform_file_read:
call read_file
… use the data, no need to check for errors
.invalid_file:
… do something; abort?
.end_of_file_reached:
… terminate the operation

Note that just before we perform a function call we do a inconditional jump, skipping over an “exception” table.  An unconditional jump is easily handled by the CPU and will not affect the prefetch queue in any significant manner.  When the call is performed, the ‘read_file’ function is able to calculate the location of the exception table based on the address of the return point that was pushed onto the stack.

In the ‘read_file’ function, something like this can be done:

… check if file handle is valid
jc .is_invalid_file_handle
… check if the end of file has been reached
jc .end_of_file_reached
… read the requested data
retn
.is_invalid_file_handle:
pop edi
jmp [edi-(5 + 8)]
.end_of_file_reached:
pop edi
jmp [edi-(5 + 4)]

Under normal condition, if the ‘file_read’ operation succeeds, it simply return with the data as it normally would, there is no extra cpu cycles used to check if the operation was performed properly and the cost of the entire operation is about the same as with a standard call; with the advantage that the caller still does not need to perform a check!

If an error occured, such as the end of file reached, the CPU will retrieve from the exception table the address where execution should be resumed.  The ‘jmp [edi-(5+4)]‘ in the example above is the operation of retrieving the return address from the exception table.  When a ‘call’ instruction is performed, the return address immediately located after the call is pushed onto the stack.  The encoded form of a near call instruction is 5 bytes long hence the ‘5′ in the code above.   By substracting 5 to the return address, we obtain the address of the ‘call’ instruction itself.  By substracting another ‘4′ we obtain the address where the last exception handler in the table is located, in this case ‘.end_of_file_reached’.

The advantage to the caller is the code will automatically resume where it needs to without having to do any return value comparison.  In a simple malloc() case where the value returned is either NULL (0) or not, a gain of approximately 5% (on the call/return code alone) can be seen using the above described method.

Now, I’d rather call the list of return addresses placed before a call an ‘alternative return points’ table rather than an exception table, as the cost associated is much more minimal, and the table has to be specified at every procedure call whereas an exception table is normally set and shared for a block of instructions.

I created page with the sample bootable image which compares performances of both standard and multipath calls Research: Multipath Calls

Enjoy the increase in performance!