On 8/14/2014 3:53 AM, Pavel Pisa wrote: > Hello Sebastian, > > On Thursday 14 of August 2014 10:07:06 Sebastian Huber wrote: >> On 14/08/14 09:48, Pavel Pisa wrote: >>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch >>> /mips/include/uapi/asm/inst.h?id=refs/tags/v3.15#n486 >> My experience with bitfields at this level is that GCC is regularly broken >> in this area. > Aligned with my feeling that it is dangerous and combined with required > volatile for regs can lead even to worse code. I don't think RTEMS has a formal coding convention (yet) for this but I don't trust them for any compiler. Ignoring breakages, you don't have as much control over the width of the generated accesses.
I recall ages ago helping someone debug a broken driver where gcc had generated a bit set or clear instruction and the device didn't like that. >>> But I generally prefer more only defines used for such fields. >>> >>> Then it would look something like >>> >>> TMS570_SCI_SCICLEARINT_XXX >>> >>> My notation is to add suffix "_m" for mask, "_b" for starting bit >>> position if used and where are offset from base "_o". The "_m" and "_b" >>> quite usesfull because C dosenit warn you when starting bit or mask is >>> mixed and results of mixing are quite damaging. >>> >>> But use of macros leads to quite complex/long lines in the code. >> Yes, I prefer this too. You may have a look at >> >> http://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/shared/include/arm-pl0 >> 11-regs.h > I am OK with single bit masks - BSP_BIT32(7), but I prefer only single > define per multi bit field. So my own approach is to use macros to find > field start bit from maks > > /*masked fields macros*/ > #define __val2mfld(mask,val) (((mask)&~((mask)<<1))*(val)&(mask)) > #define __mfld2val(mask,val) (((val)&(mask))/((mask)&~((mask)<<1))) > > for constant masks they compile optimal way and for variable > they are usable too if CPU has ffs/clz support. > > http://sourceforge.net/p/ulan/sysless/ci/master/tree/arch/arm/generic/defines/cpu_def.h > > This is how I use it in our bare HW/system-less code > > http://sourceforge.net/p/ulan/sysless/ci/master/tree/libs4c/spi/spi_lpcssp.c#l200 > > lpcssp_drv->ssp_regs->CR0 = > __val2mfld(SSP_CR0_DSS_m, lpcssp_drv->data16_fl? 16 - 1 : 8 - 1) | > __val2mfld(SSP_CR0_FRF_m, 0) | > (msg->size_mode & SPI_MODE_CPOL? SSP_CR0_CPOL_m: 0) | > (msg->size_mode & SPI_MODE_CPHA? SSP_CR0_CPHA_m: 0) | > __val2mfld(SSP_CR0_SCR_m, 15); > > http://sourceforge.net/p/ulan/sysless/ci/master/tree/arch/arm/mach-lpc17xx/libs/hal/hal_gpio.c#l32 > > So I would prefer something like that. But I agree that it can hurt > someone else eyeballs as well. > > I have seen similar solution in Nvidia driver sources with even > really interresting (ab)use of ternary C operator. > > But if RTEMS preference is to define all fields twice with SET and GET > then I would suggest that to Premek. > > Best wishes, > > Pavel > _______________________________________________ > 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
