gcl-devel
[Top][All Lists]
Advanced

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

Re: [Gcl-devel] aarch64


From: Camm Maguire
Subject: Re: [Gcl-devel] aarch64
Date: Thu, 14 Aug 2014 18:59:52 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)

Greetings!  And thanks so much again for your feedback here.

Will Newton <address@hidden> writes:

> Pointers are always 8 bytes and naturally aligned. The problem was

Great!  Wanted: a reliable configure test to check for possibly
'unnaturally aligned' pointers on the stack.  Tried some obvious C to no
avail.  

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

OK leaving a separate file.

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

I'm having seemingly unrelated uncontrollable segfaults on my machine,
and gdb is broken, so I'm leaving it out for now.  Would be nice if
someone with real hardware could define it and see if it breaks.

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

OK.

Separately, CALL26/JUMP26 can have an addend right?  They seem to be all
0.

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

Do you recall what symbols wound up missing?

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

Seems to so far :-).

Take care,
-- 
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]