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