CD-ROM recovery software?
torriem at gmail.com
Thu Apr 9 10:30:13 MDT 2009
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
> 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
More information about the PLUG