CD-ROM recovery software?

[Michael Torrie]

Nicholas Leippe wrote:
> The topic in the FAQ is the definition of a byte within the C/C++ language. 
> Within that context a byte in C/C++ on a PDP-10 will have 36 bits.
> 
> Other languages may do differently of course. But the point is as you said, 
> that the smallest addressable unit of memory on that architecture holds 36 
> bits.
> 
> The definition of a machine word size can also vary. Usually that is defined 
> by either the register size (how many bits the cpu can operate on at once), or 
> the memory width (how many bits the cpu can transfer at once), or a 
> combination of the two. The earlier Motorola 68k cpus were classified as 
> 16/32, because they had 32 bit registers but only a 16-bit wide memory bus. I 
> believe the Intel 8088 was similar, being 8/16. But, a byte on both of those 
> cpus held 8 bits.

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).

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.