[okl4-developer] S3C2440A and okl4

[Frank Kaiser]

> -----Original Message-----
> From: developer-bounces at okl4.org [mailto:developer-bounces at okl4.org] On Behalf
> Of Rémy Gottschalk
> Sent: Tuesday, August 19, 2008 6:01 PM
> To: Frank Kaiser
> Cc: developer at okl4.org; support.opensynergy at portal.ok-labs.com
> Subject: Re: [okl4-developer] S3C2440A and okl4
> 
> Frank Kaiser a écrit :
> > Hello, Folks
> >
> > I have to tell you that there are also two CLZ instructions in v2.1 of
> 'traps.spp': at line 480 and line 494. Since they are in a code section led by
> an "#ifdef CONFIG_IPC_FASTPATH" directive, I tried to compile my AT91RM9200
> platform with the parameter "IPC_FASTPATH=0", but unfortunately this breaks
> the compilation of 'traps.spp': the constant "L4_ANYTHREAD", which is defined
> in line 263 after "#ifdef CONFIG_IPC_FASTPATH", is referred in line 1445 which
> lies after the corresponding #else directive so that it is undefined.
> > So I have the situation that my platform runs into an 'undefined
> instruction' exception with IPC_FASTPATH on, and is not compilable with
> IPC_FASTPATH off. Any suggestions how to proceed?
> > Remy, I think you will face the same problem when you build with
> "PROJECT=iguana" instead of "PROJECT=l4test".
> >
> 
> I managed to get rid off those two CLZ instructions with a pretty dirty
> patch I got my inspiration from the linux kernel :
> http://lxr.linux.no/linux+v2.6.26.2/arch/arm/lib/lib1funcs.S#L106
> ie :
>   106.macro ARM_DIV2_ORDER divisor, order
>   107
>   108#if __LINUX_ARM_ARCH__ >= 5
>   109
>   110        clz     \order, \divisor
>   111        rsb     \order, \order, #31
>   112
>   113#else
>   114
>   115        cmp     \divisor, #(1 << 16)
>   116        movhs   \divisor, \divisor, lsr #16
>   117        movhs   \order, #16
>   118        movlo   \order, #0
>   119
>   120        cmp     \divisor, #(1 << 8)
>   121        movhs   \divisor, \divisor, lsr #8
>   122        addhs   \order, \order, #8
>   123
>   124        cmp     \divisor, #(1 << 4)
>   125        movhs   \divisor, \divisor, lsr #4
>   126        addhs   \order, \order, #4
>   127
>   128        cmp     \divisor, #(1 << 2)
>   129        addhi   \order, \order, #3
>   130        addls   \order, \order, \divisor, lsr #1
>   131
>   132#endif
> 
> And our two culprits are :
> clz     tmp3,   tmp3
> rsb     tmp3,   tmp3, #31
> and :
> And our two culprits are
> clz     tmp2,   tmp2
> rsb     tmp2,   tmp2, #31
> 
> Pretty similar no ?
> 
> Since I am pretty busy and not really knowledgeable about ARM assembly
> I tested to insert a similar macro in v2.1. I can't guaranty this is the
> right thing to do but this compile, all l4test pass and okl4 and wombat
> are now running apparently fine. This need of course some confirmation
> to more skilled foe than myself.
> 
> About the clzeq that still keep me from using the latest version I am
> still clueless so I'll personally stay with this version for now.
> 
> Regards,
> 
> --
> Remy Gottschalk - rgottschalk at linagora.com
> Ingénieur informatique embarquée
> Groupe LINAGORA - http://www.linagora.com
> Tél.: +33(0)1 58 18 68 28 - Fax : +33(0)1 58 18 68 29
> 
> _______________________________________________
Hi, Remy

CLZEQ means that CLZ is carried out dependent on the current condition code, in the case only when condition EQ is set. When you have a working replacement for CLZ, a BNE instruction branching behind the CLZ replacement should work.
Additional hint: since CLZ does not update the condition code, any replacement should do neither.
Anyway, many thanks for your suggestion.

Frank