Reading a Borland structed File

Kenneth Leung — Tue, 23 Nov 1999 22:09:05 GMT

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?

Re: Reading a Borland structed File

Greg_McKaskle2 — Wed, 24 Nov 1999 15:28:20 GMT

> 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.

Greg McKaskle

topic Reading a Borland structed File in LabVIEW

Reading a Borland structed File

Re: Reading a Borland structed File