gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gcl-devel] aarch64


From: Camm Maguire
Subject: [Gcl-devel] aarch64
Date: Wed, 13 Aug 2014 17:28:58 -0400

Greetings!  And thank you so much again for your very helpful and
detailed contribution.  You've certainly put a lot of work into your
reloc file, and it appears to be working at least initially.  Great!

I've committed some preliminary support based on your patches and have a
few questions.

1) You ensure that cs_org is pointer aligned.  This implies to me that
the conservative gc was missing stuff at off-alignment, but that
off-alignment is nevertheless possible, i.e. a pointer can be found on
the stack at address 4 mod 8.  Is this true?  If so, we have a special
define C_GC_OFFSET that walks the stack twice at both offsets which we'd
need to add.

2) Should aarch64 use arm-linux.h, like the other 64bit versions of
older 32bit machines?  I'm confused about the arm/aarch nomenclature.

3) Thanks for the work on the print_isns, but I don't have this working
in any useful fashion for anything but x86 at the moment.  I can
elaborate if interested.

4) no SGC?

5) You have some reloc entries like

+      store_val(where,MASK(19) << 5, (s & 0x1ffffc) << 3);

Since the last shift differs from that applied to the mask, this will
miss the ending bits in the 19bit range.  Is this what you intend?

6) I'm not sure what the libgcc issue is, but it is reminiscent of the
situation on hppa, which we solve by linking it in statically.  Please
let me know if this is not OK for some reason.

The current implementation uses an 'ldr/br' sequence, requiring two
extra words per 26bit call.  Its weak in the sense that the space really
required is much less than this, yet there is a circular dependency in
that the loaded memory location depends on the size, which depends on
the location if optimal.  Left for another day.

I'll be starting an acl2 build soon and see where we stand.

Take care,


On 12 August 2014 21:37, Camm Maguire <address@hidden> wrote:
> Greetings!
>
> Will Newton <address@hidden> writes:
>
>> On 12 August 2014 20:28, Camm Maguire <address@hidden> wrote:
>>
>> custreloc is working, but lacks trampolines. The branch distance is
>> +/-128MB which seems sufficient on the cygwin branch but not master
>> where the heap seems to grow much more quickly.
>>
>
> Great!  I did not know this (apparent adequacy on cygwin).  As I recall,
> there is still no long-calls option.  Can you post the relocs used by
> the existing calls output by gcc?  Is the branch you mention above the
> existing 24bit call?

The relocs used by gcc should be covered in the patch I posted, the
relative branch is R_AARCH64_CALL26/R_AARCH64_JUMP26.

The relocations are documented on the ARM website (not sure if you
need an account):

http://infocenter.arm.com/help/topic/com.arm.doc.ihi0056b/IHI0056B_aaelf64.pdf

> I'm surprised there is a difference between master and 2.6.11pre here,
> but the immediate goal is the latter.  The most strenuous test will be
> the acl2 build, and I'd be very surprised if that will work with 24bit
> calls even in 2.6.11pre.  If it does, we can proceed with the release.
>
>>
>> I think debian-arm is a good place to ask, there should be some ARM
>> and Linaro people on that list who may be able to arrange access to
>> hardware.
>
> Thanks so much.  Have posted there, and already received a kind offer.

Excellent!

> I take it you are working on/with gcc development on arm64.  How long
> will it take to get long-calls?

I can't speak for ARM but I don't believe they plan to add a long
calls option to the compiler as the linker is capable of dealing with
adding the required trampolines.

> Lastly, is there any reason why a 32bit long call on arm32 could not be
> used as a arm64 trampoline?  Is the instruction encoding the same?

The ISA is completely new, although it does have a number of
similarities to AArch32 (as it is now known).

The sequence to use would probably be something like:

adrp ip0, #:pg_hi21:sym
add ip0, #:lo12:sym
br ip0

Which gives 32bits pc-relative.

-- 
Will Newton
Toolchain Working Group, Linaro

-- 
Camm Maguire                                        address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah



reply via email to

[Prev in Thread] Current Thread [Next in Thread]