> -----Original Message----- > From: Joe Savage [mailto:joe.sav...@arm.com] > Sent: Friday, January 20, 2017 1:51 PM > To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolainen@nokia-bell- > labs.com>; Maxim Uvarov <maxim.uva...@linaro.org>; lng- > o...@lists.linaro.org; Bill Fischofer <bill.fischo...@linaro.org> > Cc: nd <n...@arm.com> > Subject: Re: [lng-odp] 32-bit support in examples > > > Agree with Maxim. I which way the application is not 32 bit compliant? > > It uses 128-bit atomics, and so is really designed for execution on 64-bit > machines. It is possible to provide lockless 32-bit support in this case, > though, and I have an implementation that does so. Since the pointer size > is > halved and there is a pointer in the 128-bit struct, I just have to squash > a > few of the other fields down (managing them carefully) so that 64-bit > atomics > can be used instead.
Unfortunately, ODP atomics API does not support 128 bit atomics - at least currently. So, your example could not use those anyway. Not all 64 CPUs have 128 bit atomic instructions. > > On reflection, I think that providing 32-bit support is probably > worthwhile > here, so I will do so. It does add a little complexity to the code, but > it's > not actually that much, and there are clear benefits from having the > example > be better supported on different platforms. > > I do think that having a place for 64-bit only examples in the future > (e.g. > an "example_64" directory as Bill outlined) might be useful though. It > isn't > always so easy to add 32-bit support. Good. ODP provides 32 and 64 bit atomics (also on 32 bit CPUs), so you can still utilize those. In addition, synchronization / critical sections should touch only a small portion of the application code base and preferably in a modular way (inside enqueue() / dequeue(), push() / pop(), etc functions). -Petri
