Re: [Gcl-devel] aarch64

[Will Newton]

On 13 August 2014 22:28, Camm Maguire <address@hidden> wrote:
> 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.

Pointers are always 8 bytes and naturally aligned. The problem was
that if the start of the stack was not aligned then only misaligned
stack slots would be checked for pointers which missed all the actual
pointers as they were aligned. So yes, the GC does miss pointers that
are not naturally aligned but that is not a problem for AArch64.

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

It is pretty confusing. ;-)

The original ARM ISA exists pretty much intact from its beginnings.
Thumb and Thumb2 were added but they are re-encodings of the ARM ISA
for code density which can largely be ignored if you're running Linux
on ARM. ARMv8 (i.e. version 8 of the ARM architecture) added a whole
new ISA which was AArch64, and preserved the ARM and Thumb2 ISAs and
called them AArch32. The only way to switch from AArch32 to AArch64
and vice versa is to take an exception (e.g. system call, hypervisor
call) so there is no need to interoperate between the two ISAs and
they have only a passing resemblance.

> 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?

Hmm, I thought I had enabled that. I believe it does work.

> 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?

I think so. ;-)

The bottom two bits are stored at bits 30:29, and the remaining 19
bits are stored at 23:5 so we have already masked off the bottom two
bits so just need to shift up 3 to get everything aligned with the
opcode field.

> 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.

I think the problem is that linking statically with a .a file links
only the functions that are actually used and discards the rest so
only the symbols that are used initially are available and if code is
loaded that needs other symbols it will fail to link. Dynamic linking
means that all the symbols will be available.

> 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.

Thanks, hope it works!

> 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



-- 
Will Newton
Toolchain Working Group, Linaro