On 2/13/2015 2:54 AM, Chris Johns wrote: > On 13/02/2015 7:06 pm, Sebastian Huber wrote: >> On 13/02/15 08:56, Daniel Cederman wrote: >>>> Daniel(s), could enlighten me why this is needed ? Is this a arch >>>> constraint or something else ? >>>> >>>> Chris >>> It is an arch constraint. On SPARC, for example, all memory accesses >>> needs to a be aligned. From the SPARC V8 manual: >>> >>> "Halfword accesses must be aligned on 2-byte boundaries, word accesses >>> must be aligned on 4-byte boundaries, and doubleword accesses must be >>> aligned on 8-byte boundaries. An improperly aligned address in a load >>> or store instruction causes a trap to occur." >>> >>> Since the capture engine does a 64-bit write when it writes the time, >>> the entries needs to be aligned on 8-byte boundaries. >> If you need this hack in the test, then there is a bug in the caputure >> engine. >> > Agreed, and what I was wondering. > > Maybe the capture engine needs a buffer alignment arg so the data > transfers match up. malloc is supposed to return buffers aligned to the strictest requirements of the architecture. This usually results in 4 or 8 byte alignment. Maybe the capture engine just needs to follow the same rule. > Chris > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel
-- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel