Hi,

The other think that I feel go give a lot more room for improv code speed
execution would be gotoReturn, where basically just like a normal function
call, however, return address is placed on the stack and non of the
parameters, which would allow for the same speed improvements as inline and
optimizing as if there was no function boundaries for register and
parameter usage.

Possibly label procedures, where by maybe followed with braces and default
return.

I have 3 locations of logic, which all reference 6 different configurations
of functions, to speed things up one has to inline them, however,
definitely leads to instruction bloat.

To simplify one can use labels as values, however, looks like labels as
values, is actually quite slow, when implemented, much slower than switch
to code generating and abstraction unless the compiler for const version
would allow locality and not to have be declare before any other labels,
aka globally..

So in my mind the ability go gotoReturn that goto and address and then at
the end of the label block code, one can place goReturn, which will go back
to the return address put in a register or stack.

LabelCommonProcedure: {
process some common variable global to function that is always used.

goReturn; // this read the value in a register or on the stack.
}


gotoReturn labelCOmmonProcedure
or gotoReturn LabelCommondProcedure(ReturnLabelJumpHere)

 // Where return and jump to the static label, give more optimized control
of flow, don't have to first return, and then jump, just jump directly. Can
do this with labels as values but seem to slow things down for me.
....
....
  ReturnLabelJumpHere


The alternative I guess would be a direction which be used before a
function call or on a function definition. *inline-once*, meaning the
function, will be inlined only once in a consuming function and not
multiple times. Thus giving one the flexibility of having closed to
assemble level control for performance and code size and it would also
allow the compiler to look at sharing variable usuage in the background for
optermize code, where parameters for a function call would be hosted to the
top of block section of code.

inline-once, could also benefit by some how having ability to specific the
return line of code, which compiler could optimize away, like jumping right
out of a switch block to the end directly, or maybe some where else, skip
loads unessary code to be evaluated.

void func() {}

void parent() {
inline-once(list of common separate functions) // this would be more
redable, but still one inline to be prefix a function call to specify a
return label.

switch() {
case:
int res = inline-once func();//call
inline-once(contiueHereLabel)()
inline(contiueHereLabel)() // as long as there is one reference, then the
function will be inlined once, seem clusm, otherwise, better approach
parent function declaraion
cases:...
}
contiueHereLabel
}




This doesn't reduce the overall logic, however, does improve the speed of
things.

I wouldn't be able to well go this such simple procedure, that using
goReturn gotoReturn
to write a more dynamic and not relay on the compiler to optimize the
variable usuage across all calls, that could be left up to the writer of
the code.

One could even maybe come up with the concept of alias variables names for
the same variable and type, just in different section, which clearly show
the sharing of a variable for different meanings in different sections of
code.

Think of something like this.

int sharedA[mem, currAverage]
where mem and currAverage would be defined as 0, so basically think it like
access an array of 1 element, with different name, but that name is an
abstration for 0 the same variable for readability.

sharedA[mem] = 10;
echo sharedA[mem]; // 10
sharedA[curreAverage] = 12;
echo sharedA[mem]; // 12;
echo sharedA[ curreAverage ]; // 12;

This I feel would be a current show coming from allowing to get all the
performance and optimized size of code. For instance, one could have a
toggle, to prevent the need for assignment like as if you calling a
function, where the toggle, change the array of parameters ones function is
consuming, preventing the need to assign them to a common variable or
reserve space for the block of procedure code.

enum Sets {SetA = 0, SetB = 1, SetC = 2};
int l, lr, r, h, rh, m, mh
const int A[3] = {lr, rh, mh};
const int B[3] = {r, h, h};

int ComplexSufferlingFuncParaSet = 0;

ComplexSufferling(A[ComplexSufferlingFuncParaSet],
B[ComplexSufferlingFuncParaSet])
...
This kind of thing, depends on how many parameters you have, and how often
they get called.

Just a few ideas, where feel there is quite alote more from for more
performance to be easily squeezed out, with compiler optermizations doing
this for you or the ability to first manual do them, then implemented them
as further compiler optermizations, however, it goes.
Just feel that I am missing this improve level of control.

Good old jump does add performance, to pure old inlining, unless start
share variables and things..

Kind Regards,

Wesley Oliver

-- 
----
GitHub:https://github.com/wesleyolis
LinkedIn:https://www.linkedin.com/in/wesley-walter-anton-oliver-85466613b/
Blog/Website:https://sites.google.com/site/wiprogamming/Home
Skype: wezley_oliver
MSN messenger: wesley.olis_at_[hidden]