I am trying to use the Metal C compiler in our own product which has a stack very similar to the stack required by Metal C. I have used my own prolog and epilog code successfully to use our expandable stack mechanism for the code generated by the Metal C compiler. However, I am having difficulty with the run time library functions. Ideally I would like them to use our expandable stack. i.e. I would like to be able tailor them using our prolog and epilog code. This doesn't seem to be possible. Is there any reason why a source version of the STATIC library is not available?
The problem is that I cannot rely on there being a "generous amount of free space" in the stack. I can easily get a stack extension if I can get my code in at the right point to determine what is required. The problem I have is that we cannot afford to get say 1 meg stacks for all our online sessions because there might be thousands of sessions in one address space.
So using vsprintf as an example I did the following:
#define vsprintf(a,b,c) __asm (" $CFUNCS "); \
__asm (" $CFUNCE ");
where $CFUNCS and $CFUNCE are macros that I was going to write to switch R13 to a special stack for the Metal C functions. The problem with this is that the expansion of the vsprintf is using data from the DSA so I cannot change the value of R13 in my macros.
The only solution I can come up with is for us to generate the C code using the static run time library which in this example generates a call to an external VSPRINTF and for us to write our own VSPRINTF in C with special prolog and epilog code and a call to the dynamic library vsprintf function.
Is there a better way?
This topic has been locked.
2 replies Latest Post - 2011-02-08T10:42:24Z by DaveClark
Pinned topic Using the Metal C run time library
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2011-02-08T10:42:24Z at 2011-02-08T10:42:24Z by DaveClark
SystemAdmin 110000D4XK196 PostsACCEPTED ANSWER
Re: Using the Metal C run time library2011-02-07T19:34:35Z in response to DaveClarkDave,
There is an appendix in the "Metal C Programming Guide and Reference" book which lists the stack size required by each and every library function. The biggest users need 50K. So the generous amount can simply be 50K.
As you have found out what you proposed, using __asm to provide prolog/epilog to vsprintf, won't work as vsprintf is in binary code which relies on a NAB established by the caller.
DaveClark 2700024GBN4 PostsACCEPTED ANSWER
Re: Using the Metal C run time library2011-02-08T10:42:24Z in response to DaveClarkChwan-Hang,
The problem is that the 50k you mention is too much to have free for every user all of the time in a large multi-user address space for our product. I was hoping to be able to make sure there was enough free stack space for particular function calls by wrappering the calls using __ASM etc. so that I could obtain the amount of stack space required by the particular function dynamically if there was not enough free space on our stack at the time of the call.
Anyhow the technique I am now using of compiling our code using the static library and then writing our own static handlers using a special epilog and the dynamic library seems to work just fine. I do have one concern though and that is that you may alter the amount of storage required by a given function from that listed in the latest documentation or the naming conventions etc. you are using for the static function library.