Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 29 Dec 2012 01:41:53 +0900
From:      "Daisuke Aoyama" <aoyama@peach.ne.jp>
To:        "Daisuke Aoyama" <aoyama@peach.ne.jp>
Cc:        freebsd-arm@freebsd.org
Subject:   Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr)
Message-ID:  <9ED42265200A41B1BD637682720E0E9D@ad.peach.ne.jp>
In-Reply-To: <234E1E18AC1C4A3985D6C570F78698E6@ad.peach.ne.jp>
References:  <B5F827FF91C94FF2AFEE00194A2BB2C5@ad.peach.ne.jp> <B508111FCE534B2CBA61F4D1EC1078D3@ad.peach.ne.jp> <E42823D3-D405-40E7-B4CF-75DC947AC119@bluezbox.com> <2BA73CBF02B04DD19D08CDFC556B8750@ad.peach.ne.jp> <BE93F553-E060-45E5-90FE-39AAD1325BAB@bluezbox.com> <F384770FEB784C67BC89AFF7CF57E96C@ad.peach.ne.jp> <1356624694.1144.67.camel@revolution.hippie.lan> <234E1E18AC1C4A3985D6C570F78698E6@ad.peach.ne.jp>

next in thread | previous in thread | raw e-mail | index | archive | help
>>> This is complete version of systimer patch.
>>> It should fix stopping interrupt and related things such as USB LAN is
>>> unstable,
>>> SSH is closed suddenly.
>>> (I've not yet finished all test at this time, but at least portsnap 
>>> fetch is
>>> success.
>>> Now extracting the ports without any problems.)

Finished without any problems.


I'm checking the alignment of clang now. It seems no difference of location 
of data structure.
However, access method is different.

I learned clang will combine two loads into one op.
This is a reason why the alignment seems difference between clang and gcc.
Also, a reason why clang binary is smaller than gcc code.

According to ARM manual, strd alignment is:
"The address must be a multiple of eight for doubleword transfers."

uboot/lib/api_public.h:
----------------------------------------------------------------------
struct sys_info {
        unsigned long           clk_bus;
        unsigned long           clk_cpu;
        unsigned long           bar;
        struct mem_region       *mr;    /* << mr offset is 12!! (not DW 
aligned) */
        int                     mr_no;  /* number of memory regions */
};

uboot/lib/glue.c:
----------------------------------------------------------------------
struct sys_info *
ub_get_sys_info(void)
{
        int err = 0;

        memset(&si, 0, sizeof(struct sys_info));
        si.mr = mr;
        si.mr_no = UB_MAX_MR;
        memset(&mr, 0, sizeof(mr));

        if (!syscall(API_GET_SYS_INFO, &err, (u_int32_t)&si))
                return (NULL);

        return ((err) ? NULL : &si);
}

----------------------------------------------------------------------
clang -O2 output (7 steps):
        bl      memset            ; ATPCS uses r0-r3 as parameters
        ldr     r0, .LCPI6_1      ; mr
        mov     r1, #5            ; UB_MAX_MR
        mov     r2, #60           ; sizeof(mr)
        strd    r0, r1, [r5, #12] ; r5 aligned but strd requires DW(8byte) 
alignment (faulted here)
        mov     r1, #0
        bl      memset            ;  memset(&mr, 0, sizeof(mr));

clang final binary size(2.8% smaller):
-rwxr-xr-x  1 root  wheel  235984 Dec 28 23:49 ubldr
----------------------------------------------------------------------
gcc 4.2 -O2 output (9 steps):
        bl      memset            ; ATPCS uses r0-r3 as parameters
        ldr     ip, .L162+4       ; mr
        mov     r3, #5            ; UB_MAX_MR
        mov     r1, r4            ; r4 is zero
        mov     r0, ip            ; << what??
        mov     r2, #60           ; sizeof(mr)
        str     r3, [r6, #16]     ; r6 aligned same as clang
        str     ip, [r6, #12]     ; r6 aligned same as clang
        bl      memset            ;  memset(&mr, 0, sizeof(mr));

gcc final binary size:
-rwxr-xr-x  1 root  wheel  242810 Dec 28 18:22 ubldr
----------------------------------------------------------------------
I don't know gcc 4.3 or newer, but probably output is more smart.
It seems that there is no reason to use ip in this case.

Does any one know how to prevent above clang output?
(or how to solve this issue for all codes.)

Thanks
-- 
Daisuke Aoyama
 




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9ED42265200A41B1BD637682720E0E9D>