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

Darren New wrote:
> 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?

Hell breaks loose?

Post a reply to this message

Nicolas Alvarez wrote:
> Darren New wrote:
>> 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?
> 
> Hell breaks loose?

I don't know. But that's the problem Ada solves by separating out "bytes of 
memory" from "bytes of I/O".  Of course, as Warp points out, for 99% of the 
population not writing code for embedded processors in weapons systems, 
those two types are always the same and it's annoying as hell to write any 
I/O stuff in Ada. :-)

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

I was addressing the part of the original comments that said the same bit 
can't be part of two different bytes.

In any case, if I have more RAM than address space (say, a 6G box running 
under WindowsXP-32), I can address all of memory, just not with a char*. So 
VM both lets me have one byte in two places and also lets me have bytes that 
no pointer can point to.

That's why I'm curious about exactly how the standards body worded these 
things, rather than the FAQ-writer's take on it. I'm sure the standards body 
isn't still back in a Z-80 mindset.

-- 
   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:
>   Then how do you copy blocks of memory from one place to another with a
> function like memcpy()?

Why would memcpy be harder to implement than a while loop copying bytes?


My point is that if *no* program in that language can access those "hidden" 
bits, how would your program know? Consider the bits hidden in (for example) 
the processor registers. I worked on a mainframe where the registers were 
mapped to addresses 0 thru 15. You could literally branch to instructions 
stored in the registers.  But you can't do that with AX/BX/SI/DI registers. 
There's bits of "memory" that C can't address with a char*.  Yet it isn't 
problematic, because while memcpy() can't copy them, nothing else can see 
that the copy can't copy them. I might have ECC bits or parity bits in my 
memory, which C also can't address. It's not a problem for C.

Imagine if your C compiler was set up to only ever address even-numbered 
bytes. Would you notice, other than running out of RAM twice as fast as you 
thought you should? memcpy() would only copy even-numbered addresses, but 
since nothing you do in the language would see odd-numbered addresses, 
that's OK.  (Until you share that memory with some other process via OS 
primitives, but that isn't really relevant here.)

>   If an architecture cannot support memcpy() then that would certainly
> break quite come C programs.

memcpy() doesn't need to copy all memory. It only needs to copy all 
addressable memory.

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