Memory layout of a data structure: Difference between revisions

=={{header|Fortran}}==

===Modern===

F90 introduced the ability to define compound data aggregates, as had been used from the start by COBOL in the 1960s. Thus, one could define <lang Fortran> TYPE RS232PIN9

LOGICAL CARRIER_DETECT !1

LOGICAL RECEIVED_DATA !2

LOGICAL TRANSMITTED_DATA !3

LOGICAL DATA_TERMINAL_READY !4

LOGICAL SIGNAL_GROUND !5

LOGICAL DATA_SET_READY !6

LOGICAL REQUEST_TO_SEND !7

LOGICAL CLEAR_TO_SEND !8

LOGICAL RING_INDICATOR !9

END TYPE RS232PIN9 </lang>

But it would be nearly pointless to do so.

Fortran's LOGICAL type is defined to occupy as much space as the default INTEGER type, which is typically thirty-two bits. This was done to simplify questions of storage size for large collections of assorted types of variables in a COMMON storage area. Further, ''true'' and ''false'' may not be signified by 1 and 0 but by -1 and 0, or, something else. Many compilers continue to support the old-style storage size indications that were introduced for binary computers and so would allow LOGICAL*1, but alas, this does not mean one bit, it means one byte. There is no equivalent of a key word PACKED (as in Pascal for example) whereby it might be indicated that a collection of items are to be stored "adjacent" and not aligned to byte or word boundaries. But, without a storage type equivalent to BIT(1) such as pl/i offers, this won't help either. Such packing can make reading or writing to a variable quite difficult - imagine a 32-bit integer variable offset by three bits - which is why some languages offer the keyword ALIGNED.

However, all is not quite lost. Given that one can access the special storage word containing the status of the nine-pin socket, presumably returning what can be regarded as a thirty-two bit integer (to accommodate a 25-pin socket), then, given certain knowledge of the ordering of the pins versus the bits of the integer (are bits counted from left-to-right or right-to-left, starting at one or at zero?), and certain knowledge that the nine bits are at the high-order end of the word or at the low-order end of the word (the IBM 1130's card reader placed the image of a column of a card, twelve bits, at the high-order end of its sixteen-bit word), it would be merely a matter of tedium to unpack those bits with suitable expressions and place the appropriate values into the components of a variable of type RS232PIN9. Such variables can then be juggled in the usual way.

There may be available library functions IAND(i,j) and IOR(i,j) for dealing with integer variables, otherwise it becomes a matter of integer arithmetic. Unpacking or re-packing a data structure (say, as found in a disc file record) is straightforward but tedious, and, aside from the sizes and types of the components one must have definite knowledge of the endianness of the data as in the aggregate (read from disc) compared to the endianness of the cpu running your procedure. Easiest is of course to have the same style cpu for both.

===Older style===

Without the ability to create data aggregates via TYPE statements, whereby a single variable might sprawl across memory as above, one instead prepared a collection of variables, usually with some systematic name convention linking the names of the parts. These variables would be anywhere in memory and so had no particular memory layout in themselves. However, when stored as a record in a disc file a data structure is created with a definite layout, and this is manifest in the READ and WRITE statements involved. Suppose the statement was <code>WRITE (F,REC = n) THIS,M,NAME</code> meaning that the n'th record of file unit F was to be written. The types of the variables would be known, and their sizes also. Say <code>REAL*8 THIS</code>, <code>INTEGER*1 M</code>, and <code>CHARACTER*28 NAME</code>. Such a record could be read (or written) by <code>READ (F,REC = n) STUFF</code> given a declaration <code>CHARACTER*37 STUFF</code> (counting on fingers as necessary) and the various parts of the data aggregate could be indexed within STUFF. However, the interpretation of the interior bytes of multi-byte items such as integer and floating-point variables is complicated by the endianness of the processor, a confounding nuisance.

As before stated, there is no BIT facility, so packing is to byte boundaries. But, if one is determined to store thousands of records with minimal storage use, it may seem worth the effort to engage in the arithmetic to pack the likes of say three bits, followed by the thirty-two bits of a floating-point value, and so on, into a sequence of bytes which then would be written. In such a situation it may even be worth packing only a portion of the floating-point variable, if reduced preciaion is acceptable and one is certain of the usage of the bits within such a number.