Re: RISC

[xanthian@well.com (Kent Paul Dolan)]

References=<9kws6.218$94.1074@www.newsranger.com>

Ted Dennison said:

=> ASN.1 had a lot of this type of stuff. Take the standard
=> "length octet" for instance (...please!). Bit 8 selects
=> between "short form" and "long form". In "short form" the
=> other 7 bits indicate the length of the contents. In "long
=> form", the other 7 bits indicate how many of the following
=> bytes are used to determinte the length of the rest of the
=> contents. (Remember, no problem can't be solved by another
=> level of indirection...) However, if bit 8 is on and the
=> rest of the bits are off, then it indicates that we are
=> using "indefinite form", where two terminator octets at the
=> end of the contents determine the length.

=> A week of wrestling with this kind of stuff several years
=> ago was enough to convince me that there are always going
=> to be some formats that just cannot be nicely handled at a
=> high-level with something like a rep clause.

Don't put ASN.1 too far in the past.  As of Q1 1998, at
least, it was alive and well as the data format for SNMP,
version 1, and as well as it worked, I can't imagine it
being easily replaced.

The other way of looking at this issue is probably that if
ASN.1 (and BER, _its_ underlying standard) were directly
supported as data type families in a compiled language,
the questions of worrying how to deal with stream oriented
data, or of fighting with representations, would go away.
In ASN.1 and BER, those are solved problems, so long as you
put each at both ends of the transaction.

The folks who designed ASN.1 took on a very hard problem:
how do you standardize the representation of dynamically
bounded amounts of indefinite precision data, and frankly,
strange as the mechanisms seem at first encounter, they are
quite elegant once the cultural shock has worn away.

Elegant and easy to implement are not synonyms.

The horror of knowing that you are going to be doing
_everything_ at the bit level has been adequately expressed
in another posting in this thread.  I ran into identical
issues in 1983, tasked with providing a library (in C for
the IBM big box of the day, I misremember which) to let
other programmers translate UDAF (Uniform Data Access
Format, I think) Honeywell 36 bit data to formats suitable
for storage on IBM 32/64 bit format media.  The answer that
worked to translate 20,000 2400' data tapes was to do it
all one bit at a time, with certain cheesy optimizations
where possible.

Cheers!

xanthian.
--
Kent Paul Dolan <xanthian@well.com>


-- 
Posted from smtp.well.com [208.178.101.27] 
via Mailgate.ORG Server - http://www.Mailgate.ORG