Øyvind Harboe wrote: > It is not obvious at all from the context that there is an alignment > guarantee.
If alignment is not guaranteed, casting from uint32 to void would cause problems too, wouldn't it? http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=blob;f=src/target/mips32_pracc.c;h=af60d321638652aad0a52a573add2aceacbfb7d9;hb=HEAD#l310 > The version below yields decent code across architectures after > Stefan showed that the mileage varies greatly with intrinsic memcpy(). The resulting code is even worse. Andreas Fritiofson wrote: > The question is who makes the guarantee that the function is only ever called > with uint32-aligned > generic pointers. If it just happens to be so that all *current* callers pass > a uint32 pointer cast > to void pointer, it would be a terribly bad idea to suddenly assume that. If > it is guaranteed by > design/contract, why is a void pointer used at all? Just use a pointer to > uint32 then. Please see mips32_pracc_read_mem (link above). This function returns void pointer because it is used for uint8, uint16 or uint32, depending on size parameter. If reading uint32 or uint16 from target memory, this function returns value in host endianness. While this is useful for normal EJTAG handling, it's bad for dumping target memory. For dumping we need target endianness. BR, Stefan _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
