Re: Castle Adventure by David Malmberg

[mjmahon@aol.com (Michael J. Mahon)]

David Malmberg wrote:

>pausch@saaf.se (Paul Schlyter) wrote in message
>news:<cd06mv$20mu$1@merope.saaf.se>...
><snip>
>> 
>> Old mainframe computers often used a different way to represent
>> end-of-lines: there were no end-of-line characters at all in the
>> text, instead end-of-lines were implicitly assumed at regular
>> intervals, usually every 80'th character.  Lines shorter than 80
>> characters were padded with spaces, and lines longer than 80
>> characters either were truncated or wrapped onto the next line.
>
>And other computers used line-length indicators. OpenVMS (and
>strangely, the TI-99/4A) had record length attributes in front of
>variable-length records to determine the record length.
>
>Fixed records, of course, were padded to the proper length.

How variable-length records were represented by a particular
manufacturer's proprietary operating system was strongly
influenced by a bias resulting from the way that the manufacturer's
storage media worked.

If the manufacturer used tapes with variable-length records, then
a direct representation was natural, sometimes with delimiters
but usually with "out-of-band" indication of the actual record length.

If the manufacturer used tapes formatted into fixed-length blocks,
then a representing variable-length records with a length prefix
was a natural device.  If the file could be read in reverse order,
then length suffixes were also used.

As a general rule, large commercial ("mainframe") manufacturers
went the "actually variable length" path, while many minicomputer
manufacturers went the "fixed-block with embedded lengths" path.
(IBM actually was so steeped in variable-length records that, when
they introduced the first disk pack devices, they thought of them
as an evolution of tape drives with "direct access".  They directly
supported the writing and reading of variable-length records on
the tracks, greatly complicating data management!  Within a few
years, they realized what a bad tradeoff had been made and went
to a "new" "fixed-block architecture" for their disks.  ;-)

Similar implicit biases explain the apparently arbitrary (but
still staunchly contested) choice of data representation usually
known as "little endian" or "big endian".

If you design machines with a failrly large word length, in the
32- to 48-bit range, then you seldom need multiple-precision
arithmetic.  It is "natural" to address any "byte" subdivisions
of the word in their order of adjacency in a word:  big endian.

If you design byte-oriented machines, then any quantity larger
than 255 requires multiple-precision arithmetic.  So it is "natural"
to arrange bytes in memory in an order conducive to simple
multiple-precision arithmetic:  little endian.

Despite the "religious wars" around endianness, no computer
subculture I am familiar with has been so rabidly little endian
that they put the LSB at the _left_ end of a byte.  And when a
word-oriented big endian actually does multiple-precision
arithmetic, they usually arrange the words in little endian
order. ;-)

-michael

Check out parallel computing for 8-bit Apples on my
Home page:  http://members.aol.com/MJMahon/