Might it be useful to include the flag as part of the ABI? E.g., many functions (including system calls) can return an error condition or otherwise provide a meaningful boolean return result. By defining the flag as an additional return value, 'error_occurred' could be provided and the return value could be set to errno (providing thread safety, correct? [I do not know if there are any functions that can return a meaningful non-boolean value and set errno.]). In some cases the flag could be set for free (i.e., the normal process of handling special cases generates the flag and does not overwrite it before returning), resulting in a miniscule dynamic instruction count benefit. Even if the flag is not set for free, it could improve code density _slightly_ by having the test inside a function accessed by more than one call point (i.e., one set-flag instruction at the end of the function would replace one such at every reentry point). Along similar lines, it might be useful to pass one boolean argument in a function call. E.g., a variable argument count function might have the flag set if all arguments are passed in registers, this would increase code size somewhat but might accelerate a common case of single or no optional arguments (or really one or fewer optional arguments of each type). (An even more complex idiom might have the caller use the flag to indicate that certain callee save registers need not be saved. [This would be consistent with the existing ABI in that it would only _allow_ a reduction in memory traffic when the caller and callee are cooperating--i.e., the caller sets the flag and the callee tests the flag if it wants to use those registers.] With 10 caller-save registers plus 7 argument/return value registers, this would probably not be worthwhile, but a more aggressive callee-save ABI might make such interesting [though there is also the cost of less flexibility in scheduling the spills and fills and the need to restore the flag for testing the need to fills {unless the fills were transferred to the caller--i.e., callee saving but caller restoring}].) Paul A. Clayton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencores.org/forums/openrisc/attachments/20041106/1ce8fae6/attachment.htm