[lkml]   [2010]   [Jan]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [x86] Unify semaphore_32.S and rwlock_64.S
    On Wed, 20 Jan 2010, H. Peter Anvin wrote:

    > > No I just saw it. Linus first patch increases the 64/32 bit separation by
    > > creating yet another 64 bit specific file. Can we avoid that and have
    > > code that is shared as much as possible between 32 and 64 bit?
    > The ABI is completely different between 32 and 64 bits. The stubs avoid
    > keeping track of *those* differences in each and every inline. It might
    > be possible with macros, but there is something that really is very
    > different: for x86-32, there are only three function-clobbered
    > registers, which we pretty much need to use anyway. For x86-64, there
    > are a lot more -- which means that each callsite would end up having gcc
    > generate save/restore code that would be in the fast path. Linus' patch
    > pushes that into the slow path, which seems significantly better to me.

    That does not seem to be such a problematic thing to solve.

    > > Why have a rwsem_count_t when a simple long would do in both cases? Just
    > > make sure that long is consistently used.
    > The motivation for rwsem_count_t seemed to be making it easier to switch
    > over. I leave it up to Linus to motivate the typedef... I have to say,
    > though, that using a typedef also tells you want the number is for.

    I thought we discourage such typedefs?

    > > __downgrade_write: Why use the inc trick instead of the add
    > > like in 32 bit? There is not much difference and it results in much
    > > stabler code.
    > Because you can't do an add with a 64-bit immediate! Yes, we could have
    > loaded it into a register, but that would have required an additional
    > 10-byte(!) instruction for no good reason.

    Well 2^32 readers is a bit large anyways. If we are satisifed with 2^30
    (only a billion) then it works with the same code.

     \ /
      Last update: 2010-01-20 21:55    [W:0.020 / U:20.928 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site