LabVIEW
DLL call with a struct definition
This sounds wrong. int used to be 16 bit under 16 bit systems but is 32 bit under 32 bit Windows. That said it may work to declare an int16 value when the DLL expects a 32 bit integer as long as your number is in the range which can be represented by an i16 value. Any paramters in WIndows are passed as 32 bit value on the stack. How an int16 is expanded to 32 bit by the caller is however not defined. So while LabVIEW might clear the entire 32 bit before storing the 16 bit number and pushing it on the stack there is no guarantee that LabVIEW or any other caller will always do this. If the higher bits are not cleared, they might contain garbage and the callee trying to interprete the full 32 bits will be completely hosed.
For a structure however, which when larger than 32 bits is always passed by reference by the way, the actual size for the int does of course matter very much. Since it is a 32 bit DLL, and LabVIEW would bark about an invalid DLL if it was 16 bit, I would strongly expect the DLL to actually use 32 bit integers here.
Rolf Kalbermatter
For a structure however, which when larger than 32 bits is always passed by reference by the way, the actual size for the int does of course matter very much. Since it is a 32 bit DLL, and LabVIEW would bark about an invalid DLL if it was 16 bit, I would strongly expect the DLL to actually use 32 bit integers here.
Rolf Kalbermatter
Additionally, I'm assuming I need to set the parameter type for my cluster (Assuming I can find the right data type) to "Adapt to type", and then send a pointer to a handle.....
Yes adapt to type is fine. The specifier how to pass handles has no meaning for flat structures. It tells LabVIEW to pass references to arrays or strings as pointers to its handles or the handle itself only. A cluster is always passed as pointer to the structure in LabVIEW.
Rolf Kalbermatter
shoneill wrote:
Shane,
A WORD is in the WINAPI nomenclature indeed a 16 bit unsigned integer, and if used extensively in an API in my opinion a real sign that the API and DLL has been developed by a hardware person. For embedded designs it is an advantage to use the smallest possible representation for parameters and variables, but for modern 32/64 bit CPUs the best parameter size in terms of performance is always its native bit size.
Well, with all compilers you can select the byte padding in structures as one of the compiler options. This can be 1,2,4,8 and nowadays even 16 bytes. What this means is that the compiler will align each element in a cluster to the smaller of the two values, either the elements own byte size or the alignment. So a double will be made sure to align to 8 byte if you specify a structure alignment of 8 or higher but a char will always be put whereever it is, as its own size is only one byte and so no alignment is ever done. LabVIEW on x86 architecture uses throughout byte packing (1 byte alignement) which is fine as it is the most flexible, although not most performant, option. So if your DLL needs other alignment you have to care yourself about adding additional filler bytes in the cluster. Visual C defaults to 8 byte alignment nowadays, but for Pentiums, 4 byte is not worse. Accessing an int32 on a non 4 byte aligned address incurres extra CPU cycles to read and write the value to/from a register.
Rolf Kalbermatter
most of the parameters being passed are WORD, which, unless I'm ageing at a rate I'd rather not admit, is a 16-bit integer?
Shane,
A WORD is in the WINAPI nomenclature indeed a 16 bit unsigned integer, and if used extensively in an API in my opinion a real sign that the API and DLL has been developed by a hardware person. For embedded designs it is an advantage to use the smallest possible representation for parameters and variables, but for modern 32/64 bit CPUs the best parameter size in terms of performance is always its native bit size.
I also read that some C++ compilers "pad" clusters (Sorry, Structs) to a defined padding width, but I'm not sure if this only applies to mixed-data structs).
Well, with all compilers you can select the byte padding in structures as one of the compiler options. This can be 1,2,4,8 and nowadays even 16 bytes. What this means is that the compiler will align each element in a cluster to the smaller of the two values, either the elements own byte size or the alignment. So a double will be made sure to align to 8 byte if you specify a structure alignment of 8 or higher but a char will always be put whereever it is, as its own size is only one byte and so no alignment is ever done. LabVIEW on x86 architecture uses throughout byte packing (1 byte alignement) which is fine as it is the most flexible, although not most performant, option. So if your DLL needs other alignment you have to care yourself about adding additional filler bytes in the cluster. Visual C defaults to 8 byte alignment nowadays, but for Pentiums, 4 byte is not worse. Accessing an int32 on a non 4 byte aligned address incurres extra CPU cycles to read and write the value to/from a register.
Rolf Kalbermatter
shoneill wrote:
Not necessarily! Assume a structure like
struct {
int16 val1;
int32 val2;
} MyStruct;
A compiler set with alignment higher than two bytes will allign the val2 parameter to four bytes as it is also the size of the val2 parameter. So while this structure needs 6 bytes it really takes 8 bytes in memory.
This applies to clusters with embedded strings and arrays. While it is possible with a lot of woodoo to do it without wrapper DLL it is a lot of work, worrysome, cumbersome, and did I mention a lot of work? If you have several functions with such parameters or structure parameters with arrays of structures with ........ then it is definitely just simply a pain in the ass to try to work around a wrapper DLL.
Well, put your reference to your DLL in there and then you go. Looks fine to me but I would first try with 32 bit integers. If you have to large parameters, the returned data will look weird. But if they are to small it will either crash immediately or corrupt some LabVIEW data which will crash sooner or later too, but maybe after a VI was saved to disk with corrupted content.
Rolf Kalbermatter
I automatically assumed that the padding would be interpreted as the LARGER of the two numbers, either the native data size or the padding length, but your answer suggests the opposite. This means that a cluster whose total size is less than 8 bytes (or equal to 8 bytes) will not have any padding issues?
Not necessarily! Assume a structure like
struct {
int16 val1;
int32 val2;
} MyStruct;
A compiler set with alignment higher than two bytes will allign the val2 parameter to four bytes as it is also the size of the val2 parameter. So while this structure needs 6 bytes it really takes 8 bytes in memory.
"My" cluster is 4 WORD (even though the DLL documentation describes them as int, I'm assuming they're actually WORD) in size, which is exactly the 8 bytes. So basically, I shouldn't have to worry about padding, correct?
This would help me a bit because I've read in some places that passing clusters can sometimes be impossible with LV without writing a CIN wrapper, where I have even less experience than with DLLs (i.e. none).
This applies to clusters with embedded strings and arrays. While it is possible with a lot of woodoo to do it without wrapper DLL it is a lot of work, worrysome, cumbersome, and did I mention a lot of work? If you have several functions with such parameters or structure parameters with arrays of structures with ........ then it is definitely just simply a pain in the ass to try to work around a wrapper DLL.
Here's how I'm trying to do it..... The code won't run, but the DLL configuration is visible.
Thanks
Shane.
Well, put your reference to your DLL in there and then you go. Looks fine to me but I would first try with 32 bit integers. If you have to large parameters, the returned data will look weird. But if they are to small it will either crash immediately or corrupt some LabVIEW data which will crash sooner or later too, but maybe after a VI was saved to disk with corrupted content.
Rolf Kalbermatter
