Thanks Shawn,
I am off on hoilday in 30mins for 3 weeks will look at it in detail when I
get back. Watch out peru!!
Simon
E-mail Confidentiality Notice and Disclaimer
This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to which they are addressed. Access to this email by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited.
Email messages are not necessarily secure. Renesas Technology Europe does not accept responsibility for any changes made to this message after it was sent. Please note that Renesas Technology Europe checks outgoing email messages for the presence of computer viruses.
---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
>>> and double.
>> Yes.
> Are we sure, a float can use a double word, a single word, or ...
Certain. It's the *size* of data that's important to the stack, not the
type. sizeof(float) = 4, sizeof(double) = 8. DWORD = unsigned long = 4, WORD
= unsigned short = 2. VEE Real32 = 4, Real64 = 8.
Interpretation (type) is important for the receiver. I.e., passing an Int32
(long) to a function that expects a float will cause the function to
misinterpret the 32 bits. VEE sends an int and the function is trying to
interpret it as an IEEE format floating point number. However, it won't mess
up the stack because the size of the data is the same.
Then of course there's certain optimizations that are used at the compiler's
discretion. Passing 16 bits can sometimes mean passing 32 bits, though the
outside world never knows the difference. One usually only sees this kind of
optimization within a complete compilation unit - a dll that exports an API
doesn't usually allow this to happen, but there are wacky combinations of
options that can produce parameter lists who's sizes don't match their
declarations.
This is one of the reasons that the standard __stdcall notation appends the
total size of parameters to a function name. If you have params of int and
short, that's 6 bytes. If your function name winds up _MyFunc@8, you know
that the short param is actually using 4 bytes and the function must be
called with 8 bytes. If not, then 16 bits of the first parameter get
replaced with 16 bits of the last return address and the stack is two bytes
short when the called function returns. The result is usually a wild crash.
-SHAWN-
---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".