opensubscriber
   Find in this group all groups
 
Unknown more information…

l : lightning@gnu.org 24 June 2011 • 1:11PM -0400

Re: [Lightning] Lightning arm port
by Paulo César Pereira de Andrade

REPLY TO AUTHOR
 
REPLY TO GROUP



Ludovic Courtès wrote:
> Hi Paulo,

  Hi Ludovic,

>>   Out of interest of learning more about arm, I made a simple arm
>> port of lightning, see https://github.com/pcpa/lightning
>
> Woow, excellent!  :-)
>
>>   It has been developed and tested only in qemu, but it pass all
>> the tests I added to the contrib/check subdirectory in my for in
>> github.
>
> I tested on my GuruPlug, which is armv5tel-unknown-linux-gnueabi (had to
> run autoreconf in ‘contrib/check’ because of a dangling
> ‘install-sh’
> link; also ‘config.guess’ in your repo is from 2004 and doesn’t know
> about ‘gnueabi’, so I’d recommend not putting it under version
> control
> and instead using the one that comes with the latest Autoconf.)

  Many thanks for the feedback.

  I think I may have partially messed in a git reset to avoid
noisy in the commit due to autoconf files. The old config.guess
should be the one in the build-aux directory.

  You should be able to get it to work running autoreconf, as
below it appears to have failed due to not creating the symlinks
to the arm subdirectory. I think I will remove the autotools files
from git.

> There are some test failures under tests/, and contrib/checks/ appears
> to have environment problems:
>
> --8<---------------cut here---------------start------------->8---
> make  check-TESTS
> make[2]: Entering directory `/mnt/disk/2/src/lightning-arm/+build/tests'
> 1d0
> < nfibs(32) = 7049155
> FAIL: fib
> PASS: fibit
> PASS: fibdelay
> PASS: incr
> 1d0
> < looks like 1024 bytes sufficed
> FAIL: printf
> PASS: printf2
> PASS: rpn
> PASS: add
> PASS: bp
> 2,10c2,10
> < nans 0 2 2 1 2
> < trunc -2 -2 0 2 2
> < trunc -3 -2 0 2 3
> < ceil -2 -2 0 3 3
> < ceil -3 -2 0 2 3
> < floor -3 -3 0 2 2
> < floor -3 -2 0 2 3
> < round -3 -2 0 2 3
> < round -3 -2 0 2 3
> ---
>> nans 0 1 -1 0 -1
>> trunc -1 -1 0 1 1
>> trunc -1 -1 0 1 1
>> ceil -1 -1 0 1 1
>> ceil -1 -1 0 1 1
>> floor -1 -1 0 1 1
>> floor -1 -1 0 1 1
>> round 90111 -1 -1 0 0
>> round 90111 -1 -1 0 0
> FAIL: testfp
> 1d0
> < result is 171.15 17.25
> FAIL: funcfp
> PASS: rpnfp
> PASS: modi
> PASS: ldxi
> PASS: divi
> PASS: movi
> 1c1
> < succeeded
> ---
>> failed: got -1 instead of 7777
> FAIL: ret
> 1,2d0
> < received 7777
> < succeeded
> FAIL: allocai
> 1,2d0
> < we got 7777
> < succeeded
> FAIL: push-pop
> PASS: sete
> 5c5
> < 0 0
> ---
>> 0 1
> 9,20c9
> < 0 0
> < 1 1
> < 1 1
> < 0 0
> < 1 1
> < 1 1
> < 1 1
> < 0 0
> < 1 1
> < 1 1
> < 1 1
> < 0 0
> ---
>> 0 1
> 22a12,22
>> 0 4
>> 1 4
>> 1 48
>> 1 48
>> 0 48
>> 1 48
>> 1 48
>> 1 48
>> 0 48
>> 1 48
>> 1 48
> FAIL: 3to2
> 0a1,31
>> SIGSEGV: __builtin_return_address(0) = 0x4017ed40 - info->si_addr = 0x10
>> stxi...
>> movxi...
>> xi_c...
>> xi_uc...
>> xi_s...
>> xi_us...
>> xi_i...
>> xi_ui...
>> xi_f...
>> xi_d...
>> stxr...
>> movxr...
>> xr_c...
>> xr_uc...
>> xr_s...
>> xr_us...
>> xr_i...
>> xr_ui...
>> xr_f...
>> xr_d...
>> str...
>> movr...
>> x_c...
>> x_uc...
>> x_s...
>> x_us...
>> x_i...
>> x_ui...
>> x_f...
>> x_d...
> FAIL: ldst
> ================================
> 9 of 22 tests failed
> Please report to bonzini@gnu....
> ================================
> make[2]: *** [check-TESTS] Error 1
> make[2]: Leaving directory `/mnt/disk/2/src/lightning-arm/+build/tests'
> make[1]: *** [check-am] Error 2
> make[1]: Target `check' not remade because of errors.
> make[1]: Leaving directory `/mnt/disk/2/src/lightning-arm/+build/tests'
> Making check in contrib/check
> make[1]: Entering directory
> `/mnt/disk/2/src/lightning-arm/+build/contrib/check'
> make  lightning
> make[2]: Entering directory
> `/mnt/disk/2/src/lightning-arm/+build/contrib/check'
> gcc -DPACKAGE_NAME=\"check\" -DPACKAGE_TARNAME=\"check\"
> -DPACKAGE_VERSION=\"0.0.1\" -DPACKAGE_STRING=\"check\ 0.0.1\"
> -DPACKAGE_BUGREPORT=\"paulo.cesar.pereira.de.andrade@gmai...\"
> -DPACKAGE_URL=\"\" -DPACKAGE=\"check\" -DVERSION=\"0.0.1\"
> -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1
> -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
> -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1
> -DLT_OBJDIR=\".libs/\" -DHAVE_LIBIBERTY=1 -DHAVE_LIBBFD=1
> -DHAVE_LIBOPCODES=1 -I. -I../../../contrib/check
> -I../../../contrib/check/../.. -I../../../contrib/check/../../lightning
> -I../../../contrib/check/../../lightning/  -Wall -Wbad-function-cast
> -Wdeclaration-after-statement -Wmissing-prototypes -Wmissing-declarations
> -Wnested-externs -fno-strict-aliasing -Wold-style-definition
> -Wpointer-arith -Wstrict-prototypes -DDEBUG=1 -D_ASM_SAFETY=1
> -DDISASSEMBLER=1 -DDYNAMIC=1 -DPREPROCESSOR=1 -std=c99 -pthread
> -fvisibility=hidden -D_GNU_SOURCE=1 -g -O2 -MT lightning.o -MD -MP -MF
> .deps/lightning.Tpo -c -o lightning.o ../../../contrib/check/lightning.c
> In file included from ../../../contrib/check/lightning.c:23:0:
> ../../../contrib/check/../../lightning.h:248:27: fatal error:
> lightning/asm.h: No such file or directory
> compilation terminated.
> make[2]: *** [lightning.o] Error 1
> make[2]: Target `lightning' not remade because of errors.
> make[2]: Leaving directory
> `/mnt/disk/2/src/lightning-arm/+build/contrib/check'
> make[1]: *** [check-am] Error 2
> make[1]: Target `check' not remade because of errors.
> make[1]: Leaving directory
> `/mnt/disk/2/src/lightning-arm/+build/contrib/check'
> make: *** [check-recursive] Error 1
> make: Target `check' not remade because of errors.
> --8<---------------cut here---------------end--------------->8---

  I did only test so far under qemu, and it pass all tests there.
I feel it may be due to the ldrd/strd instructions. You can force
it to use a pair of ldr/str with the pseudo patch:

-           jit_cpu.version = strtol(buf + 17, &ptr, 10);
+           jit_cpu.version = 4;

in lightning/arm/funcs.h. Besides the documentation I have tells
those instructions are in all armv5, gcc does not appear to
generate those.

> Note that the GCC Compile Farm has a few ARM boxes (SheevaPlugs or
> similar.)
>
>>   Some generic arm details:
>>
>> o arm has 16 registers
>> o registers 0-3 are used to pass arguments, extra arguments on stack
>> o registers 0-3 are also used for return values
>> o registers 4-9 are callee saved registers
>> o registers 10,11,13,14 are special purpose, stack/base pointer,
>>   link register, etc
>> o register 15 is the program counter
>> o register 12 is the only truly scratch register
>> o float/double arguments are passed and returned in registers 0-3
>> o arguments are not packed, so, like in the mips port, it is
>>   not easy to follow lightning specification of pushing argument
>>   right to left...
>
> Which ABI does this follow?

  It should be eabi. If I understand correctly, major visible
difference for basic data types is that in eabi arguments are
not packed, i.e. int+double+int arguments become r0=int,r2+r3=double,
sp[0]=int while in older abi the double would be in r1+r2.
  I mean "should be eabi" because the stack frame being created
in lightning does not fully match the ones created by gcc. The
ones created by gcc have r11 (fp) pointing to the address of
r14 (lr) in the stack, but this, I believe should only be
required for code unwinding the stack, and I preferred to
have fp in a more convenient/standard position, like:

[alloca][fprn]...[fpr0][r0][r1][r2][r3][r4]...[fp][lr][extra-arguments]
                       ^                          ^
                       fp                    <gcc fp position>

where fpr* are the "soft float registers", and r[0-4] is a
copy of incoming arguments, and where pusharg* stores it
temporarily (load/save with the ldm/stm instruction, that
receive a bitmask argument).

  I am still unsure what is the rule of r10. I think it is free
(callee saved) in gnueabi.


  I am almost getting ready a rework in my other jit code, where
I did choose (for the sake of experimentation) to use r0-r3 only
for arguments and return, and r4-r6 as JIT_R[0-2] and r7-r9 as
JIT_V[0-2]; this lies because JIT_R[0-2] becomes callee save :-)
With limitation of not making complex operations on
jit_prepare ... jit_finish, it means there is no need to spill
r0-r3. Because of the issue of sharing registers, I also extended
my "fork of my lightning fork" :-) to add the extra jit_ret(),
jit_retr(r), jit_reti(i), jit_retr_f(r), jit_reti_f(i), jit_retr_d(r)
and jit_reti_d(i), so that it does not need to make some hacks
mapping a special value to JIT_FRET, and in other ports, those are
just aliases, e.g. jit_retr(r) -> jit_movr(JIT_RET,r);jit_ret();

> Thanks,
> Ludo’.

Thanks,
Paulo


_______________________________________________
Lightning mailing list
Lightning@gnu....
https://lists.gnu.org/mailman/listinfo/lightning

Bookmark with:

Delicious   Digg   reddit   Facebook   StumbleUpon

Related Messages

opensubscriber is not affiliated with the authors of this message nor responsible for its content.