CD-ROM recovery software?

Nicholas Leippe nick at leippe.com
Thu Apr 9 10:51:55 MDT 2009


On Thu Apr 9 2009 10:30:13 Michael Torrie wrote:
> Right.  But at the time the PDP-10 was made, the "byte" was known
> already as 8-bits, at least in the parlance of data communication.  Thus
>   if one was programming something on the PDP-10 that would communicate
> with another piece of hardware, it is likely that one would have to
> distinguish between a real byte and the byte as defined (for convenience
> and speed mainly) in the C++ compiler.  What a mess.  I'm glad we don't
> have to make such distinctions on modern systems, even though most CPUs
> address memory on word boundaries, or even larger boundaries, or at
> least a word at a time (IE you can't just fetch a byte on a 64-bit x86
> CPU... you have to fetch 64-bit words through the bus).

True, the machine always fetches a complete cache line at a time from ram. 
But, it is still byte addressable--it will still let you select an individual 
byte to operate on.
The same can still be said of other arches, such as the Alpha, even though 
memory accesses must be on aligned word boundaries or else you cause a bus 
error, each individual address still points to an individual byte, but 
operating on an indidual byte requires additional operations besides the load 
and store.

And yes, context is always relevent. A byte defined in communications 
protocols varies historically even more than a byte as defined by memory 
layouts on cpu architectures, being defined by character sets and serial 
protocol encodings to mention a few.

>
> I guess it doesn't help that C and C++ has brought us certain,
> arbitrary, implementation-specific definitions of data types that are
> never consistent.  Like a word being 16-bits, except that sometimes it
> is 32-bits.  An integer is 32-bits (since i386 anyway).  A long integer
> is 64-bits.  Except on 64-bit systems where an integer and a long
> integer are typically both 64-bits.  And then we have dwords and long
> words.  Wonderful.

Yes, the C/C++ standards have always defined limits according to architecture:

sizeof byte <= sizeof short <= sizeof long <= sizeof long long

where size of byte by definition is the smallest addressable unit of memory, 
and size of int is the fastest (usually word) size on the machine for 
arithmetic.

Fortunately, C99 defines stdint.h, (some C++ compilers provide this header), 
the boost library provides boost/cstdint.hpp, which does the same, and it's 
under review for inclusion into the next C++ standard revision.

This makes comms and embedded programming much more sane, where you can get 
standard sized types, and standard defined types:

intX_t for exact size,
int_leastX_t for minimum size
int_fastX_t for fastest w/minimum size, etc.

It boggles my mind that these types weren't added to the standards a decade 
sooner.





More information about the PLUG mailing list