I'm going to add that -fomit-frame-pointer option to the GNUmakefile, thanks... as for the variables, I'm stepping through this particular section of code in a recursive manner and preferring to avoid stack usage where possible. Registers r0,r1,r2,r13 and r31 are system-wide usable and untouched in these routines, Registers r3 through to r7 are usable as volatile variables across calls Registers r8 through r12 are used as variables through multiple depths of calls as "global" values inside the threads running this routine. Register r14 is a "Flags" register on a per-thread basis, Registers r15 through to r30 are also used globally for remapping registers inside a CPU Simulation. "jsr ((Offset+OpCode)<<2)" to select which routine is a summary of what the core routine is suppossed to calculate for address calling. that is kind of why I am setting up the registers in a "weird" way as I need to have *multiple* calls affect the same value no matter how many times it occurs recursively or not. I can't just let the compiler declare where it will put them as the routines called are not part of the library module containing the calling routine. and the use of labels inside the Assembly have no relation to variables or symbols outside the assembly from what I have read about the generic GCC Inline Assembly HOWTO material.

Well I am completely "green" to using GCC on AmigaOS 4.x along with the PPC specifics of the Assembly, I have no previously used the Assembly parts of GCC and other than what I already have I would like to make sure I don't miss any details or have any unplanned register changes, the variables themselves are being changed in both the parent and children of this function along with during the execution of this function... all three layers of stacking will be using the registers for the same values however when the various "call" and "return" stack frame changes happen I would like to retain changes that have occured. I'm not sure if I have left any details out or need further details specifically declared for this Would using the extended Assembly stuff doesn't make itself clear to me (I want the variables in question declared directly in the registers for the entire duration of the function described along with the function I am calling. how to do that without them being pushed back to the stack again?

then the following code for the C wrapping the assembly concerned compiled with -fomit-frame-pointer this will be enough to contain the specific routines as long as I used the fixed register usage within the specific thread model I will be using? Is that what you are saying? as the specific Simulation processes being run will have a standardized use of registers and this will be known inside the affected plugins concerned.

updated the code... I forgot to make the calling base relative to the r11 register content. Hopefully these snippets are understandable (I've deliberately included the full commentary as well for clarity) 2012-06-03 : latest update... if anyone can review and comment ?

okay...first off... I am defining my own ABI on top of the Sys V ABI generally used for the r8 through r30 register range with a hole at r13 for the near data section reservation, secondly, NONE of the register contents may be save/restored in-place within the same routine. as ExecOpCode(OpCodeVector(ExecOpCode(OpCodeVector()))) recursion is permissible and **on*exit*requires*the*content*of*the*deepest*function*to*remain*as*current*state** At any point in that recursion if "state save" and "state restore" events occur, then the entire recursive call is in effect a null event and repeated. this is a logical equivalent to compiler output from "for(;;) do_nothing();" hammering away inside the CPU core and eating it into uselessness so no "save/restore" of register content is against the operational requirements of this algorithm, "correcting" for register argument passing convention, again I need to actively define this as part of the function declaration (I'm not placing long term variables in any kind of "volatile" register layout) the registers require to retain variable state for the lifetime of the process that contains these execution constraints. there is two sets of stacks... the normal minimal process stack which will barely have enough memory to handle the normal processing and the wrapped-stack which is the stack of the program contained within the Interpreter/JIT engine. What I need is specific help in organizing telling the compiler the exacting constraints for all the register contained variables concerned. I know I can use "register atomic_type variable_name regname;" constructs in SAS/C and StormC but I need to know the equivalent to this for GCC to work with these assembly fragments properly, or some means where I can feed a C language variable into an Assembly fragment to handle these specifics properly. the functions called in the OpCodeVector[]() reference are an entirely separate library and Interface from the calling function of ExecOpCode8() and ExecOpCode16() I would appreciate any pointers or reference examples that are usable examples and are not messed up with x86 specific constraints. I've already looked around and spent at least a couple of weeks with the GCC Documentation along with various IRC channels asking for help. so far I keep getting "oh assembly, x86 blah blah blah..." responses... or referred back to the GCC documentation which says nothing about telling it which register that I want to use for what variable (I seem to get the impression of "just leave register handling to the compiler" which is something I can't do... I am crossing an API/ABI boundary between two compiled objects here, as well as recursive re-use of the same function making the boundary cross call being called as well...) I don't know at this point how much I need to explain about this for it to be understood, having tried with blog entries AND direct IRC chats... so far only 2 people have seemed to grasp what I am actually doing...the rest... I am simply unsure if I managed to explain the concept parts well enough.