[Gc] Re: Re[4]: [Patch 2/2] Aarch64 libatomic_ops and Gc basic port

Yvan Roux yvan.roux at linaro.org
Mon Jan 28 05:42:15 PST 2013


I generate the attached mixed source/assembly file (thanks to
objdump), hope it makes it more readable. If you are not fluent in
AArch64 here are some hints :

Load-Store Single Register:
  LDR  wt, addr
  STR  wt, addr

Load-Store Exclusive:
  LDXR  wt, [base{,#0}]
  STXR  ws, wt, [base{,#0}]  // ws hold returned exclusive access status

Load-Acquire / Store-Release:
  - Non-exclusive:
  LDAR Wt, [base{,#0}]
  STLR Wt, [base{,#0}]

  - Eclusive:
  LDAXR Wt, [base{,#0}]
  STLXR Ws, Wt, [base{,#0}]  //  ws hold returned exclusive access status

Cheers,
Yvan

On 28 January 2013 14:05, Yvan Roux <yvan.roux at linaro.org> wrote:
> Hi Ivan,
>
>> gcc-boehmgc at bdwgc git repository is a "read-only" branch I used to
>> identify code that worth merging to master.
>
> Ok, thanks.
>
>> To be fixed:
>> * AO_load_acquire - it is defined twice (in aarch64.h and in ordered_load.h)
>> - are they the same at asm level?
>
> In fact the other definition of AO_load_acquire (in read_ordered.h) is
> implemented as a AO_load followed by an AO_compiler_barrier (actually
> this macro is an empty one for the AArch64, but probably have to be a
> dmb instruction), whereas the call to the atomic builtin with the
> acquire memory model, used the explicit load-acquire (ldar) of the
> AArch64 ISA :
>
> AO_load_acquire:
>         sub     sp, sp, #16
>         str     x0, [sp]
>         ldr     x0, [sp]
>         ldar    w0, [x0]
>         add     sp, sp, 16
>         ret
>
>> Also, it would be good if you provide us with the assembly output for each
>> primitive in aarch64.h - just to check verify gcc output.
>
> Yes sure, I'll sent all the generated assembly code.
>
>> The TODO items I've placed to aarch64.h are not strictly necessary to be
>> done to have the file merged to master.
>
> Ok, many thanks for your help.
> Cheers,
> Yvan
>
>> Regards,
>> Ivan
>>
>> 24 01 2013, 12:55 +01:00 Yvan Roux <yvan.roux at linaro.org>:
>>
>> Hi Ivan and Marcus,
>>
>> Thanks for the comments and committing.
>>
>>
>> I've a question for you two, on the proper way to have this merged
>> into GCC. Should it be first merged into Ivan's gcc-boehmgc github
>> branch or directly into the FSF repo ? Regarding the FSF, Marcus this
>> has to go into the AArch64 branch I guess ?
>>
>> Cheers,
>> Yvan
>>
>> On 23 January 2013 20:51, Ivan Maidanski <ivmai at mail.ru> wrote:
>>> Hi Marcus and Yvan,
>>>
>>> I've committed the proposed GC patch (with the 2 corrections mentioned
>>> below) to master branch:
>>>
>>> https://github.com/ivmai/bdwgc/commit/7b5acfba9a1df00f0427d1d2e1a92570da3ab2d1
>>>
>>> Regards,
>>> Ivan
>>>
>>> Wed, 23 Jan 2013, 18:15 UTC Marcus Shawcroft <marcus.shawcroft at arm.com>:
>>>
>>> On 23/01/13 17:53, Yvan Roux wrote:
>>>
>>>> @@ -557,6 +568,7 @@
>>>> /* running Amdahl UTS4 */
>>>> /* S390 ==> 390-like machine */
>>>> /* running LINUX */
>>>> + /* AARCH64 ==> ARM 64-bit */
>>>
>>> The define AARCH64 represents the ARM AArch64 execution state therefore
>>> I think this comment should read:
>>>
>>> AARCH64 -> ARM AArch64
>>>
>>>
>>>> +# define DATASTART ((ptr_t)__data_start)
>>>> + /* __stack_base__ is set in newlib/libc/sys/arm/crt0.S */
>>>
>>> That comment doesn't make sense in this context.
>>>
>>> Cheers
>>> /Marcus
>>>
>>>
>>>
>>> _______________________________________________
>>> Gc mailing list
>>> Gc at linux.hpl.hp.com
>>> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
>>>
>>>
>> _______________________________________________
>> Gc mailing list
>> Gc at linux.hpl.hp.com
>> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
>>
>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: aarch64.s
Type: application/octet-stream
Size: 6177 bytes
Desc: not available
Url : http://napali.hpl.hp.com/pipermail/gc/attachments/20130128/6b67194a/aarch64.obj


More information about the Gc mailing list