> Am 17.03.2014 um 01:06 schrieb John Kasunich <[email protected]>: > > > > > If you can be sure that hal_float_t is the largest member on > > all platforms, then it could just be: > > > > *((hal_float_t)(data_addr)) = pin->dummysig.f; > > that is exactly the kind of 'optimizations' I abhor: an assumption deep down > in code which is maybe executed a few hundred times at best each run of > linuxcnc, which nowhere near warrants execution time considerations, and > which is going to blow up as soon as you introduce a larger hal scalar. > > NO. > > - Michael
I'm in full agreement. I wasn't sure if memcpy was available in kernel space. If it is available we should use it. I must admit that it pains me a bit to use memcpy for an object that is at most 64 bits long. Doesn't memcpy have special code to detect and deal with things like overlapping blocks? Seems like overkill. I guess we could write hal_data_u_copy(hal_data_u *dst, hal_data_u *src) that would do exactly what is needed without any special case code. But that is nitpicking - I agree with your basic principle. -- John Kasunich [email protected] ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
