In principle the serialisation process can transfer between different machine architectures. It automatically stores and interprets a "magic" number in order to cope with byte reversal between (for example) Transputers and SUN workstations. This is handled by the function word_swap() which is controlled by a global variable within the serialisation code, at the beginning of the deserialisation process (the serialisation process does not need to be concerned with byte ordering of course.
The standard way of communicating between different machine architectures is via conversion to an intermediate machine independent format, such as ANSI (for example uuencode on UNIX systems). However, such a process is unwieldy and not appropriate for real-time processing systems. In the interest of speed the serialisation process performs a low-level write operation directly on the data. This places a limitation on the data structures which can be serialised and communicated between architectures reliably. For example some SUN machines will not permit a "double" variable to be specified on an odd machine address. This problem can often be rectified by careful arrangement of variables within a structure but on some occasions this cannot be achieved. This is handled by inserting an extra "int filler" variable to realign the structure (see Conic above, the smart user will notice that in this particular case the filler variables could actually have been avoided!).
The serialise code also assumes that all variables are stored in the same position relative to the start of the structure and in the same machine representation (floats and doubles etc.). The size of data structure written out to file is specified by a "sizeof" declaration and the same value is read back from the file and used to allocate the memory for the data structure later. It is clear that once again this assumption was made on the basis of speed considerations (it would have been safer to copy the data from a temporary stored file into a separately allocated TINA data structure which was allocated in the usual manner.) This of course may not always be the case. This problem will of course need to be reconsidered when porting to any new architectures. A simple first step check would be to compare the size of all TINA data structures calculated by sizeof() on different machines.