 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Does the C standard use the word "byte", or does it simply say that
> sizeof(char) must always be 1 (without specifying a name for the unit)?
It says byte, which is the smallest addressable unit of memory.
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1336.pdf
That's why RFCs talk about octets and not bytes.
--
Darren New, San Diego CA, USA (PST)
Insanity is a small city on the western
border of the State of Mind.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mueen Nawaz wrote:
> On 06/26/09 11:13, Darren New wrote:
>> Mueen Nawaz wrote:
>>> Think modems (the phone ones). In the old days, it was all baud. 1
>>> baud is 1bit/s. It probably has stuck since.
>>
>> Technically, one baud is one symbol per second. A 9600bps modem is a
>> 2400 baud modem with 2 symbols per baud.
>
> Fine, be picky.<G>
Hey, I worked for the guy who invented the 9600 bps modem. I had to be
picky. :-)
> I was taught it meant 1 cps (character per second) - which could
> have been 1 bit/s, but not necessarily. I suppose character is the same
> as your symbol.
Probably. The symbol is the smallest unit at the physical layer.
> It's just that in all the contexts that _I've_ used it, a baud was
> 1bit/s.
Yes, incorrectly so. :-) I still talk about 9600baud modems, unless i'm
being picky
--
Darren New, San Diego CA, USA (PST)
Insanity is a small city on the western
border of the State of Mind.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] san rrcom> wrote:
> It says byte, which is the smallest addressable unit of memory.
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1336.pdf
It's interesting that the standard doesn't specify how many bits there
should be in a byte (as it shouldn't), but later it specifies that the
maximum value an unsigned char type should be able to hold is 255, so
it's indirectly saying that a byte should be at least 8 bits. Likewise
it gives a minimum value of 8 for CHAR_BIT.
I suppose that if there exists a system with bytes smaller than 8 bits,
a C compiler for that system would slightly break the standard by necessity
(well, unless the 'char' type is made to consist of more than one physical
byte).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> but later it specifies that the
> maximum value an unsigned char type should be able to hold is 255
Of course I meant to write "at least" in between there.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> I suppose that if there exists a system with bytes smaller than 8 bits,
> a C compiler for that system would slightly break the standard by necessity
Nah. You just wouldn't be able to address the smaller units. If you has
6-bit memory units, you'd have pointers to characters that increment by two
machine addresses on each ++, and you'd have 12 bits per char.
Altho, in truth, I expect they'd just break compatibility, rather than
actually follow the standard yet generate surprising machine code.
The real killer for such a system is the number of people who *do* assume
8-bit bytes. What happens when you have 10-bit characters and you call
write(14, "Zoop", 4)
and handle 14 is a TCP socket?
--
Darren New, San Diego CA, USA (PST)
Insanity is a small city on the western
border of the State of Mind.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> I suppose that if there exists a system with bytes smaller than 8 bits,
> a C compiler for that system would slightly break the standard by
> necessity (well, unless the 'char' type is made to consist of more than
> one physical byte).
If there is a system with internal "bytes" smaller than 8 bits, it has to do
something different to make a conforming C implementation.
http://www.parashift.com/c++-faq-lite/intrinsic-types.html#faq-26.6
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> http://www.parashift.com/c++-faq-lite/intrinsic-types.html#faq-26.6
"""
The C++ language guarantees there are no bits between two bytes. This means
every bit in memory is part of a byte. If you grind your way through memory
via a char*, you will be able to see every bit.
"""
I find it hard to believe you could even enforce that in a language. I'm
quite sure there are architectures where C can run that have memory
unaddressable by a char*. Certainly there are bits in floating point
registers (or even regular CPU registers) that many architectures don't give
you addresses for. Memory in memory-mapped panes (i.e., addressing more bits
than you have address space for) would also seem to be outlawed.
"""
The C++ language guarantees there are no bits that are part of two distinct
bytes. This means a change to one byte will never cause a change to a
different byte.
"""
I wish he'd actually cited the part of the standard that says things like
this. It would be interesting to know how it was actually worded.
--
Darren New, San Diego CA, USA (PST)
Insanity is a small city on the western
border of the State of Mind.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> """
> The C++ language guarantees there are no bits that are part of two
> distinct bytes. This means a change to one byte will never cause a
> change to a different byte.
> """
>
> I wish he'd actually cited the part of the standard that says things
> like this. It would be interesting to know how it was actually worded.
Actually, thinking on this, it's obviously impossible to follow the
standards on any machine with virtual addressing, too. It's easy to tell
Linux (or at least the CPU, even if Linux prevents it) to map the same byte
to lots of different locations.
--
Darren New, San Diego CA, USA (PST)
Insanity is a small city on the western
border of the State of Mind.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Certainly there are bits in floating point
> registers (or even regular CPU registers) that many architectures don't give
> you addresses for. Memory in memory-mapped panes (i.e., addressing more bits
> than you have address space for) would also seem to be outlawed.
Then how do you copy blocks of memory from one place to another with a
function like memcpy()?
If an architecture cannot support memcpy() then that would certainly
break quite come C programs.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Actually, thinking on this, it's obviously impossible to follow the
> standards on any machine with virtual addressing, too.
Why? I thought the whole idea of virtual addressing is that non-contiguous
memory is made to *look* contiguous to a program, which is precisely what
the C standard requires. So virtual addressing *fixes* the problem rather
than *creating* it.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
