Subject:
|
Re: Mechanical Memory for Computing
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Thu, 26 Jun 2003 16:44:51 GMT
|
Original-From:
|
T. Alexander Popiel <POPIEL@WOLFSKEEP.nospamCOM>
|
Viewed:
|
759 times
|
| |
|
|
In message: <1056643644.3efb1a3c68157@webmail.xmission.com>
Bruce Boyes <bboyes@systronix.com> writes:
> Quoting Ross Crawford <rcrawford@csi.com>:
> > Actually a byte is whatever you define it to be - a nibble is generally
> > half a byte, and a word is generally 2 bytes.
>
> Not to start a tempest in a teapot but I know of no recent computer language
> or hardware which defines a byte as anything other than 8 bits. "byte-wide"
> I/O is always 8 bits wide as are byte-wide registers. Were it not so, there
> would be extreme confusion in hardware and software.
Various network protocols define bytes as 7-bit + parity. Almost
all modern modems still support this, for a simple example.
Historically, the hardware-defined 'most covenient' integer size
was called the 'word', with word sizes ranging from 4 bits up to
128 bits. Then Intel broke with that definition when they made
backwards-compatible *86 chips with a native width of 32 bits,
but still documented with the word size being 16 bits.
> In the C world there can be disagreement on different hardware platforms
> about the number of bits in an int (16 or 32), word or long word, but the
> size of a byte is always 8 bits. Intel vs Motorola hardware differs in where
> bit0 is, which drives programmers and designers crazy.
C is even more flexible than that... and makes no reference to
byte size. It's the size of a 'char' that's _at least_ 8 bits,
and size of all other types is some multiple of char size.
'int' must be at least 16 bits, and must be more expressive than
char. 'long' or 'long int' must be at least 32 bits. All types
are welcome to be larger than these minimum sizes.
Note that the types don't have to have perfect power-of-2 ranges,
either... the actually specified (ISO 9899-1990) limits are
specific numbers, not bit counts. If you really want, you can
have all types 64 bits, with the range for char limited such
that EOF is distinguishable from an unsigned char (as per getchar()
requirement).
> On advantage of Java is that all primitive sizes - byte, int, long, etc are
> all the same on all hardware, making such definitions truly standardized in
> a way which they never were with C tools. The 'endian-ness' of data is also
> standardized across all platforms so there is no confusion about whether
> 'bit 0' is the least- or most- significant bit and where it's located. In
> Java it's always the rightmost bit and always the least significant.
Note that for Java, runtime storage size is not specified anywhere.
At runtime, only the ranges and the overflow behaviours are
specified; any implementation is free to use whatever storage size
is convenient, with appropriate fixups on the operators. Even in
the JVM spec, those things delared as bytes are explicitly stored
in the same size registers as ints... which could be 64 bit
registers, if you were on hardware where that's the most convenient
size.
Runtime storage is even more problematic in Java due to the fact
that implementations are not required to reclaim object memory...
ever. Garbage collection is entirely optional.
Actual size and endianness is only defined for the transmission
formats, which is fairly typical of the networked world.
And yes, I'm a language lawyer. Why do you ask?
- Alex
|
|
Message is in Reply To:
 | | Re: Mechanical Memory for Computing
|
| Quoting Ross Crawford <rcrawford@csi.com>: (...) Not to start a tempest in a teapot but I know of no recent computer language or hardware which defines a byte as anything other than 8 bits. "byte-wide" I/O is always 8 bits wide as are byte-wide (...) (21 years ago, 26-Jun-03, to lugnet.robotics)
|
5 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
