stack preparation

[Satya_6]

Hi,

I have an application to simulate the 'c' type function calling. It would read the function name and arguments from a file.
Use a generic function pointer to call the function passing the arguments using an array of void * .

The argument array is filled based on the argument type and the pointer is incremented accordingly.

(Eg. For double, the pointer will be incremented by 2).

Now if I call the function with a generic function pointer with the arguments like
func_ptr(args[0], args[1], args[2], args[3], ..
args[49]); (whare areg is declared as void *args[50])

The problem is if I have a double as argument anywhere after the 5th argument it is not getting passed properly to the actual function.

It works fine on a HP-UX 11.11 PA-RISC based workstaion but on a HP-UX 11.22 Itanium based m/c the arguments are screwed up in the actual function. 9It doesn't work on SGI and IBM also)

Please suggest the right approach to construct the stack and call the function with a generic function pointer.

TIA
satya

[Adam J Markiewicz]

Hi

I would think of passing the single address to the beginning of the array with arguments, rather than declaring function with 50 spare arguments just in case. Despite from being more optimal, it should be easier to handle I guess.

Good luck
Adam

[Mike Stroyan]

If you want the C compiler to pass float or double parameters according to the calling conventions then you have to let the compiler know that they are float data types. You can read the calling conventions here.
Intel Itanium software conventions and runtime architecture
http://h21007.www2.hp.com/dspp/tech/tech_TechDocumentDetailPage_IDX/1,1701,3309,00.html

The first eight parameter "slots" are passed in registers. Float data types that are known to be float parameters should be passed in float registers. Float data that are varargs parameters should be passed in general registers. If the caller is not able to tell if they are varargs, parameters should be passed in both float and general registers.

If you caused every parameter to be treated as float data, then you would be at risk of NaN traps from certain integers interpreted as floats. Also, the parameter float registers, f8-f15, are only used up by passing a float value. If a call passes "(float,int,float,int)", then it uses the f8, out1, f9, and out3.

It seems that the only way to handle all cases is with 2^8 enumerated code versions for the possible combinations of float and non-float parameters.