JC> CC> positive,none, and negative. As you can tell, the base 3 machine
JC> CC> suffered from serious physical limitations and was dumped.
JC>
JC> Sounds a bit hard to believe to me - Knuth mentions the idea of a
JC> trinary machine in his books, but implies that such a thing has never
JC> existed. In any case, the standards _do_ specify binary encoding,
JC> though they allow 1's or 2's complement or sign/magnitude.
I got that one from my professor Dr. Read. In his assembly/architecture
class he always got off on tangents. I,however, would believe him
to be credible because he knows may too much about machines of the
past. He worked on the apollo 11 mission (his claim to fame) and
couldn't stop telling us about the old X17522-1/1jjkk_blah_blah
punch card computers.
One reason for the failure of the trinary machine is it's hard
for a computer to recognize a voltage level but can recognize level
changes easily. From this we had to learn bit encodings like manchester
and differential manchester, NRZ-L,NRZ-I, etc - but thats more
allong the line of networks.
JC> CC> You mean like sequential,indexed sequential, and so on? If so,
JC> CC> bad idea - dos systems and the like only have sequential files
JC> CC> natively.
JC>
JC> No - just an encoding so you could do things like write a long out to a
JC> file on one system and read it on another and dependably get the same
JC> value on each. I'm not sure about many of the details, but it would
JC> have only had to do with the encoding of individual data items, not the
JC> overall organization of a file.
Sounds like the idea behind htonl, ntohl functions for tpc/ip.
In one assignment, we had to have a server on a big endian machine
and a client on a little endian machine and transmit an arp frame
and return the arp using the actual adresses of the machines.
He told no-one about ntohX() or htonX() and let everyone figure it
out for themselves. We also had to send it in network form, least
significant bit to most significant bit.
The translation functions where a pain to use for sockets and would
be even a greater pain for every single read and write to a file
or stream.
--- GEcho 1.00
---------------
* Origin: Digital OnLine Magazine! - (409)838-8237 (1:3811/350)
|