I am trying to throw together a quick program with LabView which needs to read files that have been written by a Borland compiled program. It seems Borland does not handle structs the same as LabView, Borland seems to condense the memory allocated to a structure. If something only needs 16bits only 16bits are allocated. At least this is what the programmers around here are telling me. I found a way around this by reading each element of the structure one by one, but I was told there should be a easier way around this. It seems Visual C++ has the same problem as LabView when reading Borland structures. Visual C++ has a command that changes the structures to match Borland. Does LabView have this capability?
> I am trying to throw together a quick program with LabView which needs to > read files that have been written by a Borland compiled program. > It seems Borland does not handle structs the same as LabView, Borland seems > to condense the memory allocated to a structure. If something only needs > 16bits only 16bits are allocated. At least this is what the programmers > around here are telling me. > I found a way around this by reading each element of the structure one by > one, but I was told there should be a easier way around this. It seems Visual > C++ has the same problem as LabView when reading Borland structures. Visual > C++ has a command that changes the structures to match Borland. > Does LabView have this capability?
There are several issues here -- promotion, alignment, and endianness.
Most compilers will allocate the space specified with a typical limit of a one byte minimum. Some choose to promote small allocation to a larger size. This happens on PCs when passing parameters to a function, and some exotic computers do this to structs as well. This is generally done for speed of access. LV always allocates the size requested, one byte, two, four, eight for doubles, or ten for extendeds (Note that extendeds are a different size on each platform's memory representation and sixteen bytes on disk).
Alignment refers the initial address where an allocation will be located and the additional space added between allocations. Typical alignment rules are that bytes can be stored at any address, but two-byte words are stored on even addresses, four-byte longs are stored on mod-four addresses, and perhaps there is an eight byte rule. The alignment rules are very much dependent on the chip architecture, and again its a performance issue. CPUs can be simplified if they can make assumptions about which addresses the instructions need to load from, and they often use exception/interrupt based means for loading non-aligned memory.
The Intel architecture has no required alignment rules and can access any size allocation from any address. Compilers settings can change the alignment to be more strict than necessary, and that is becoming more common on the PC. LV still locates allocations on a one-byte boundary, meaning that there is never any additional space inserted between cluster/structure elements.
Endianness refers to the order of bytes in a multi-byte allocation. Intel is referred to as a little-endian architecture and SPARC, PA-RISC, PPC, 68K, and most others are typically used big-endian. Some architectures can actually switch depending on what the OS requires. The in-memory image of any allocation in LV is the native format, but when saved to disk, the data is always standardized -- meaning it is always saved in big-endian format. This was chosen as the standard partly because of where LV came from, and partly because this is considered the network standard. Saving data in the standard form makes it easier to transport LV VIs and data between platforms and read the data into a different type of computer, but it does mean that other PC programs have a little difficulty reading and writing to LV's data format.
My guess here is that there is no problem with promotion or alignment, but the problem is with the endianness. I think it is the advanced palette that has some memory access primitives that can be used to swap bytes or words of an allocation to make them be match the assumptions of the other PC application. Note that there are only two types of endianness, big and little. Data files written by other applications either match LV or they don't. The same swap works on reads as well as writes.