At 15:45 2002-10-25 -0700, you wrote:
In general, the standard just requires the appearance that something happened. It says that the implied copy constructor must act like it worked like this, and that is what drove the initial implementation.From: "Ben Combee" <[EMAIL PROTECTED]> > > Looking at the C++ standard, the behavior here is determined by section > 12.8, "Copying class objects". The implicitly defined copy constructor has > several requirements: > > 1) perform a memberwise copy of its subobjects > 2) order of copying is the same as the of initiation of its base classes > and members in a user-defined constructorI don't have the standard in front of me, but I would've expected it to say that an implementation must appear from the outside as if those two requirements were met, but that it can certainly optimize a simple struct copy without regard to them. In other words, I do not believe the standard really requires memberwise copy in implementation.
There are two levels here.> #pragma block_assign on > > to your source files or header file. It is not enabled by default because > it can cause missed optimization opportunities for some code because the > compiler is no longer able to split a single struct into multiple scalar > variables for independent assignment to registers or the stack. Can't the optimizer tell when it should do a block assignment?
The front-end is responsible to generating either a block copy or a memberwise copy. The FE has finished all of its code generation before the optimizer gets a chance to modify things. So, the optimizer now sees you local struct treated both as individual elements and as a whole structure due to the block copy. It doesn't know that that block copy is really a copy constructor, it just sees a much lower level use of the address of the structure, rather than the individual use of each structure element.
On the 68K with the current backend, this optimization isn't very important, so it may be good to default to block_copy on for this compiler. Access from memory don't have a huge penalty on the 68K versus more pipelined chips, and the register pressure is already very high due to the limited number of address and data registers, so there aren't a lot of opportunities to do struct scalarization that there would be on a chip like the PowerPC with its 32 general purpose registers.
--
Ben Combee <[EMAIL PROTECTED]>
CodeWarrior for Palm OS technical lead
Palm OS programming help @ www.palmoswerks.com
--
For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
