Copying Structs

Maybe the call is to the same code used by the C library function :

memcpy( void* , void* , int )

- Are You sure that all the struct are copied correctly ?
- Whats about the sizeof( ) of the struct ?
- How the function called can know it if the sizeof is not passed to registers ?

Usually I use the following code :

typedef strcut A
{ ....
} str_A;

void CopyStruct( str_A *sSrc, str_A *sDst)
{ memcpy( *sSrc , *sDst , sizeof(str_A) )
}

Maybe the call is to the same code used by the C library function :

memcpy( void* , void* , int )

- Are You sure that all the struct are copied correctly ?
- Whats about the sizeof( ) of the struct ?
- How the function called can know it if the sizeof is not passed to registers ?

Usually I use the following code :

typedef strcut A
{ ....
} str_A;

void CopyStruct( str_A *sSrc, str_A *sDst)
{ memcpy( *sSrc , *sDst , sizeof(str_A) )
}

"How the function called can know it if the sizeof is not passed to registers ?"

I'd be pretty certain that the size is being passed in registers - how about:

0018 E6F23600 MOV R2,#036H

My primary Intention is a better understandig.

What about Data Integrity of larger Objects in Multitasking Environments? I.e. do I have to protect against Interrupts (Struct consisting of 16Bit Objects @ 16Bit operations = No, @ 8Bit operations = yes)

What about Performance in time-critical projects?

Of course I could write my own Function, but the simple assignment is quite charming.

Regards,
Marcus

"What about Data Integrity of larger Objects in Multitasking Environments?"

Even a simple assignment is not guaranteed to be atomic - so nothing special here.

"What about Performance in time-critical projects?"

If you have a time-critical project, why are you copying big structures around anyhow?

"Of course I could write my own Function, but the simple assignment is quite charming."

That's the trade-off: either write it yourself, and know what's going on, or go for convenience and delegate the control to the compiler.
You can't have it both ways, I'm afraid.

I don't think Keil give out their source code. But you don't need it: the copy subroutine is small and you can easily figure out how it works by looking at its disassembly. I suspect in some memory models and/or optimization settings the compiler could inline the copy subroutine.
If you need atomicity for thread-safe operation, you should take care of it yourself. The compiler should not disable interrupts silently as this would increase interrupt latency and create a risk of side effects.
As for performance, if you think that the standard copy subroutine is suboptimal, right one yourself. That's what I would have done, anyway.

Regards,
- mike

Even a simple assignment is not guaranteed to be atomic - so nothing special here

What do you mean by that? In which cases can a 8 or 16 Bit assignment on a 16 Bit Platform like the XC be unsafe? Can you give me an example?

Thanks

"In which cases can a 8 or 16 Bit assignment on a 16 Bit Platform like the XC be unsafe"

I didn't say that!

All I said was, Even a simple assignment is not guaranteed to be atomic"

In fact, as you say, it probably will be safe for 8 or 16 bit assignments on a 16 Bit Platform like the XC - but that is a feature of the target environment, not a guarantee of the language.
And what happens if the 16-bit value is not word-aligned...?