FORTRAN 77 on PDP-11

Little-endian and big-endian apply whenever you have a multi-digit value broken up into smaller ordered multi-digit units. (Usually this is for base-2 digits, but it doesn't have to be.) Most often, the smaller units are 8-bit bytes, with the order being memory addressing, but this doesn't have to be so. (An example that violates all of those assumptions is sending multi-bit bytes over a bit-serial line, where the "smaller..units" are individual bits, ordered by chronology on the wire.) As a concrete example, consider the 32-bit value 305,419,896 (decimal), stored in 4 bytes on a computer with 8-bit bytes. 305,419,896 is hex 12345678; the four bytes will have values 12, 34, 56, and 78 (hex). The question is, which comes first? In little-endian, the byte with value 78, the least significant one, comes first, followed by 56, 34, and 12. In big-endian order, it's the other way around: 12, 34, 56, 78. As applied to values in memory, "comes first" generally means "stored at lower-addressed memory". Little-endian is how the x86 family of CPUs works. The VAX also uses little-endian, as do some MIPS systems, and probably others that don't come to my mind immediately. Big-endian is used by the SPARC, the 680x0 family, some MIPS systems, and, again, doubtless others. The PDP-11 is an odd case. The hardware is little-endian, but the hardware is 16-bit. Some languages store 32-bit integers in what we might call "schizophrenic endian": that 12345678 value is stored in four consecutive bytes as 34 12 78 56: it is broken into two 16-bit words with the more-significant one stored first, but those 16-bit words are then stored little-endian in the bytes making them up. Some aspects of the VAX - notably its floating-point layout - are comparably twisted; it's quite impressive to look at the data layouts section of the VAX Architecture Reference Manual and notice how some things are shown in 8-bit columns, some 16, some 32, so that it all looks natural even when it's totally bizarre. Whether this will do what you want depends on what the implementation does when asked to print a floating-point value in octal. You appear to be assuming it simply prints the bits making up the floating-point number, rather than (as would be more logically consistent) doing a conversion to octal floating point. (I would actually expect to get a compile-time error from using an O format with a REAL*8 value.) I see two problems here. First, you have to eliminate the postincrement on the second and third ADC instructions. Second, this loses carries resulting from the ADCs. For example, if r1 points to 0x00000000ffffffff and r0 points to 0x0000000000000001, the result will, I think be zero, not the 0x0000000100000000 it should be. (Also, the return instruction is normally spelled "ret", not "return".) Right - or at least, it does after you've fixed the bugs. Little-endian. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse at rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B