On 03/15/2012 07:52 PM, Richard Henderson wrote:
On 03/14/12 11:31, Richard Henderson wrote:
For my next trick: figuring out an Easy Way of utilizing IFUNCs,
so that we automatically make use of new cpu features without
recompilation...
Dunno about "easy", but I can now generate a shared librar
On 03/14/12 11:31, Richard Henderson wrote:
> For my next trick: figuring out an Easy Way of utilizing IFUNCs,
> so that we automatically make use of new cpu features without
> recompilation...
Dunno about "easy", but I can now generate a shared library that
contains ifunc symbols. Gotta get that
On Wed, 2012-03-14 at 14:14 -0400, Andrew MacLeod wrote:
> I expect in the not too distant future other sorts of guarantees may be
> desired, such as various forms of forward progress guarantees to replace
> the spin locks
I will have a look at what's there, and can take care of the lock-based
f
On Wed, 2012-03-14 at 12:00 -0700, Richard Henderson wrote:
> On 03/14/12 11:54, Paweł Sikora wrote:
> > is this yet another libatomic implementation better than atomic_ops?
> >
> > http://www.hpl.hp.com/research/linux/atomic_ops/
> > https://github.com/ivmai/libatomic_ops/
It's serves a similar
On 03/14/2012 03:06 PM, Andrew MacLeod wrote:
No comment on whether its better or worse than any other library, but
once we have one in place in the toolchain, everyone is welcome to
enhance it with a better implementation.
Heh, not to say that rth's implementation isn't a good one :-)...
Stupid evolution and autodetection of html format emails..., gcc bounced
the reply...
On 03/14/2012 02:54 PM, Paweł Sikora wrote:
On Tuesday 13 of March 2012 17:02:01 Richard Henderson wrote:
So, I've got something put together. I think it should be fairly scalable.
As a test I've thrown in s
On 03/14/12 11:54, Paweł Sikora wrote:
> is this yet another libatomic implementation better than atomic_ops?
>
> http://www.hpl.hp.com/research/linux/atomic_ops/
> https://github.com/ivmai/libatomic_ops/
My implementation is targeted at the requirements of C++11.
The projects you reference are n
On Tuesday 13 of March 2012 17:02:01 Richard Henderson wrote:
> So, I've got something put together. I think it should be fairly scalable.
> As a test I've thrown in some ARM overrides.
>
> See
>
> git://repo.or.cz/gcc/rth.git rth/libatomic
>
> which is a gcc tree with a libatomic subdir.
>
On 03/14/12 11:14, Andrew MacLeod wrote:
> Perhaps those can fall into the config directory as well? ie config/TM or
> config/forwardprogress?
Hmm. Yes, I think so. Place a new copy of load_g.c in config/tm
and that will override the one at the top-level. A mere matter of
adjusting the sear
One of the things I want to make sure is that the library can be easily
extended in a generic way (ie not target dependant) as needs change.
Ie, initiually we are simply guaranteeing atomic operations and fall
back to a lock.
I expect in the not too distant future other sorts of guarantees ma
On 03/14/12 05:03, Andrew MacLeod wrote:
> I had taken that code, split it into more manageable source files
> that weren't so macro driven and much easier to maintain, added some
> testcases to verify the build, and was trying to figure out how to
> configure and build libatomic as a standalone li
On 03/13/2012 08:02 PM, Richard Henderson wrote:
So, I've got something put together. I think it should be fairly scalable.
As a test I've thrown in some ARM overrides.
See
git://repo.or.cz/gcc/rth.git rth/libatomic
which is a gcc tree with a libatomic subdir.
Comments welcome. Andrew, d
Richard Henderson wrote:
> So, I've got something put together. I think it should be fairly scalable.
[...]
> Comments welcome. Andrew, didn't you say you had some code as well, but
> didn't want to argue with autofoo?
I think Andrew's version is attached to
http://gcc.gnu.org/wiki/Atomic/GCCM
So, I've got something put together. I think it should be fairly scalable.
As a test I've thrown in some ARM overrides.
See
git://repo.or.cz/gcc/rth.git rth/libatomic
which is a gcc tree with a libatomic subdir.
Comments welcome. Andrew, didn't you say you had some code as well, but
didn't
14 matches
Mail list logo
