2009-02-13 13:54:57     sqrt_fr16 Functions problem

Document created by Aaronwu Employee on Oct 16, 2013
Version 1Show Document
  • View in full screen mode

2009-02-13 13:54:57     sqrt_fr16 Functions problem

Gildas Allain (FRANCE)

Message: 69424   

 

Hi Everybody,

 

 

 

For an image processing application, I need to use the sqrt function with fract16. This function seems to be declared in the "math_bf.h" but when I compile my code I get the following error:

 

            => undefined reference to '_sqrt_fr16'

 

Then I managed to compile the sqrt_fr16.asm file rev2262 but the function return false results:

 

e.g.: sqrt_fr16(float_to_fr16(0.6))  = -0.420959 ????

 

 

 

Do you have any Idea? Any advice?

 

 

 

Regards,

 

Gildas

TranslateQuoteReplyEditDelete

 

 

2009-02-13 14:11:33     Re: sqrt_fr16 Functions problem

Mike Frysinger (UNITED STATES)

Message: 69426   

 

do not compile libbfdsp yourself.  just link with -lbfdsp.

QuoteReplyEditDelete

 

 

2009-02-13 15:34:31     Re: sqrt_fr16 Functions problem

Gildas Allain (FRANCE)

Message: 69428   

 

I have added -L$(LIB_PATH) -lbfdsp to link the library but I still have the error.

 

I forgot to the specify that I use blackfin-toolchain-win32-2008R1.5.exe with bfin-linux-uclibc for the cross compiler

TranslateQuoteReplyEditDelete

 

 

2009-02-13 15:43:43     Re: sqrt_fr16 Functions problem

Mike Frysinger (UNITED STATES)

Message: 69429   

 

works under Linux:

$ cat test.c

#include <math_bf.h>

int main() { return sqrt_fr16(float_to_fr16(0.6)); }

$ bfin-linux-uclibc-gcc test.c -lbfdsp

$

QuoteReplyEditDelete

 

 

2009-02-13 15:45:43     Re: sqrt_fr16 Functions problem

Mike Frysinger (UNITED STATES)

Message: 69430   

 

seems to work with wine (i dont have any Windows systems available atm);

$ wine ./bin/bfin-linux-uclibc-gcc.exe ~/test.c -o ~/a.out -lbfdsp

$

QuoteReplyEditDelete

 

 

2009-02-14 04:51:10     Re: sqrt_fr16 Functions problem

Gildas Allain (FRANCE)

Message: 69445   

 

Thanks for your support.

 

I managed to compile with the option -lbfdsp. The only difference with my makefile is the position of the option on the command line. When I add -lbfdsp at the end it compile else it doesn't ????

 

 

 

Regards,

 

Gildas

TranslateQuoteReplyEditDelete

 

 

2009-02-14 07:43:12     Re: sqrt_fr16 Functions problem

Gildas Allain (FRANCE)

Message: 69446   

 

Mike,

 

Did you verify the output of the sqrt_fr16(float_to_fr16(0.6)) ?  I get 0.44... instead of  0.7745...

 

 

 

Gildas

TranslateQuoteReplyEditDelete

 

 

2009-02-14 18:54:29     Re: sqrt_fr16 Functions problem

Mike Frysinger (UNITED STATES)

Message: 69455   

 

that's how static linking works

 

QuoteReplyEditDelete

 

 

2009-02-15 04:45:36     Re: sqrt_fr16 Functions problem

Gildas Allain (FRANCE)

Message: 69457   

 

Ok, and what about the result? Do you verify it?

TranslateQuoteReplyEditDelete

 

 

2009-02-15 13:14:14     Re: sqrt_fr16 Functions problem

Mike Frysinger (UNITED STATES)

Message: 69459   

 

no

QuoteReplyEditDelete

 

 

2009-02-16 03:50:28     Re: sqrt_fr16 Functions problem

Gildas Allain (FRANCE)

Message: 69478   

 

Sorry for all these stupid questions,

 

Could you please check the result of the last example you posted?

 

Which version of the Toolchain are you using? I saw in the forum that the float_to_fr16 function is not implemented in the revision 2008r1.5.

Sorry to be so annoying I'm just a beginner with the GNU toolchain,

Gildas

TranslateQuoteReplyEditDelete

 

 

2009-02-18 17:52:38     Re: sqrt_fr16 Functions problem

Mike Frysinger (UNITED STATES)

Message: 69586   

 

i'm using the latest trunk toolchain.  i think you're right in that float_to_fr16() did not exist in the 2008R1.5 toolchain.

 

as for interpreting the values, i'm not familiar with the fract16 and such functions, so perhaps Robin can chime in here.

QuoteReplyEditDelete

 

 

2009-02-19 01:43:26     Re: sqrt_fr16 Functions problem

Jean-Christian de Rivaz (SWITZERLAND)

Message: 69601   

 

I use this code to get a very fast sqrt_fr16() based on a table lookup. The drawback is that it eat 128K of memory and some load at the start of the application.

 

static fract16 internal_sqrt_fr16(fract16 x)

{

        float a = ((float)x) / ((float)32768);

        float b = sqrt(a);

        short y = ( b * ((float)32768) );

        return (fract16)y;

}

 

static short sqrt_fr16_table[65536];

 

fract16 sqrt_fr16(fract16 x)

{

        return sqrt_fr16_table[x];

}

 

void fract_missing_init(void)

{

        for( unsigned int index = 0; index < ( sizeof(sqrt_fr16_table) / sizeof(short) ); index ++) {

                short a = (short)index;

                short y = internal_sqrt_fr16(a);

                sqrt_fr16_table[index] = y;

        }

}

 

 

Regards,

 

 

QuoteReplyEditDelete

 

 

2010-10-28 13:30:31     Re: sqrt_fr16 Functions problem

Jeremie RAFIN (FRANCE)

Message: 95367   

 

Lady and Gentlemen,

 

I would like to re-open this thread as I can see the same kind of problem on my system.

Here is the code:

 

$ cat test.c

#include <math_bf.h>

#include <stdio.h>

 

int main()

{

  printf("%d; expected is 181\n", sqrt_fr16(1));

  return 0;

}

 

$ bfin-linux-uclibc-gcc test.c -lbfdsp -o test

 

If I execute it on the board, I get:

# /mnt/test

200; expected is 181

 

 

Now I just make this change (in bold):

$ cat test.c

#include <math_bf.h>

#include <stdio.h>

 

int main()

{

  {

    static int i;

    i++;

  }

  printf("%d; expected is 181\n", sqrt_fr16(1));

  return 0;

}

 

$ bfin-linux-uclibc-gcc test.c -lbfdsp -o test

 

If I execute it on the board, I get:

# /mnt/test

388; expected is 181

 

 

!!! The same code does not give the same result !!!

...and obviously not the good one (181)...

 

 

I have investigated in detail and found this. Please comment.

 

If I look at the assembly code of the sqrt_fr16, constant arrays are used in the computation. These constant addresses are got thanks to "hard" init (P1.L = .sqrtcoef0 etc.). Well.

But if I create a constant array by myself in C, and I look at the reverse assembly to guess what the compiler does, I can see that FP and P3 are used in a very complicated computation to get the address of the constant array. Not the same convention?

 

Moreover, if I look in memory at address where sqrt_fr16 reads for its computation (during the execution of my code; I do not explain how I do that, this would need too much time, but trust me), the memory dump (while the code is being executed, I insist) is completly different from expectation (the initialized values in the assembly code). And last but not least, if I look at the correct address in memory while my code is being executed (I do not explain either how I did that: the constant being not global, I needed to find tips), the expected values are there!

 

My conclusion is that the assembly code does not respect the convention access for constant arrays (and maybe other variable types) in case of dynamic link (FDPIC ELF) generated by bfin-linux-uclibc-gcc. This is all the more my best conclusion so far that with bfin-uclinux-gcc (BFLT), the two above codes return 181 as expected! What do you think? The key question being: how to include libbfdsp in a FDPIC ELF so that it works?

 

 

Please advise,

Thanks a lot!

Regards,

Jérémie Rafin

QuoteReplyEditDelete

 

 

2010-10-28 13:54:26     Re: sqrt_fr16 Functions problem

Mike Frysinger (UNITED STATES)

Message: 95368   

 

this thread is over a year old and presumably with a different toolchain version.  please start a new one and just refer to the old one if you like.

QuoteReplyEditDelete

 

 

2010-10-29 03:02:15     Re: sqrt_fr16 Functions problem

Steve Kilbane (UNITED KINGDOM)

Message: 95379   

 

The libbfdsp sources are taken from VisualDSP++ largely unchanged, and were not written with the FDPIC ABI in mind, so I would not recommend using libbfdsp functions with FDPIC unless you've inspected the functions' sources yourself.

 

We plan to address this in a future release, but have not gotten to it yet.

QuoteReplyEditDelete

 

 

2010-11-02 04:47:25     Re: sqrt_fr16 Functions problem

Jeremie RAFIN (FRANCE)

Message: 95474   

 

Thanks for your help.

 

For your information I have changed sqrt_fr16.asm (details hereafter), then recompiled the toolchain and it works perfectly (in all above cases).

 

Thanks and regards,

 

Jérémie

 

 

 

 

 

$ diff -u sqrt_fr16.asm.old sqrt_fr16.asm

--- sqrt_fr16.asm.old    2010-10-28 16:03:25.823326120 +0200

+++ sqrt_fr16.asm    2010-10-29 10:21:53.283307011 +0200

@@ -95,20 +95,12 @@

.FILE_ATTR FuncName      = __sqrt_fr16;

#endif

 

-

-#define  N_SEEDS   5

-

-.section .rodata;

-.ALIGN 2;

-    .type    .sqrtcoef0, @object

-    .size    .sqrtcoef0, (N_SEEDS) * 2

-.sqrtcoef0:

-    .short 0x2D41,0xD2CE,0xE7E8,0xF848,0xAC7C;

-    .type    .sqrtcoef1, @object

-    .size    .sqrtcoef1, (N_SEEDS) * 2

-.sqrtcoef1:

-    .short 0x2D42,0x2D31,0xEA5D,0x1021,0xF89E;

-

+.data;

+ .align 2;

+ .sqrtcoef0:

+ .short 0x2D41,0xD2CE,0xE7E8,0xF848,0xAC7C;

+ .sqrtcoef1:

+ .short 0x2D42,0x2D31,0xEA5D,0x1021,0xF89E;

 

.GLOBAL  __sqrt_fr16;

.TYPE    __sqrt_fr16, STT_FUNC;

@@ -120,11 +112,16 @@

        CC = R0 <= 0;                   // Check for <= 0

        IF CC JUMP .done;               // Return 0 for x <= 0

 

+#ifdef __FDPIC__

+       P1 = [P3 + .sqrtcoef0@GOT17M4]; // Pointer to coefficents 0

+       P2 = [P3 + .sqrtcoef1@GOT17M4]; // Pointer to coefficents 1

+#else

        P1.L = .sqrtcoef0;          // Pointer to coefficients 0

        P1.H = .sqrtcoef0;

 

        P2.L = .sqrtcoef1;          // Pointer to coefficients 1

        P2.H = .sqrtcoef1;

+#endif

 

        R3.L = SIGNBITS R0.L;           // Signbits(x) - 1

        R2.L = R3.L >> 1;

QuoteReplyEditDelete

 

 

2010-11-09 05:42:43     Re: sqrt_fr16 Functions problem

Mike Frysinger (UNITED STATES)

Message: 95698   

 

are you sure you need to change the storage declaration ?  changing the loads to use P3 makes sense for __FDPIC__, but that should work fine with .rodata or .data sections.

QuoteReplyEditDelete

 

 

2010-11-09 05:47:55     Re: sqrt_fr16 Functions problem

Mike Frysinger (UNITED STATES)

Message: 95699   

 

most functions do work with FDPIC.  only the square root funcs were missed.

QuoteReplyEditDelete

 

 

2010-11-09 15:31:48     Re: sqrt_fr16 Functions problem

Jeremie RAFIN (FRANCE)

Message: 95709   

 

Hi,

 

I was expecting such a question!

And if I were kidding, I would answer that I did that for making you comment! ;))

 

My real (and bad?) reason is because of efficiency...

I am not an expert in assembly, I am not an expect in FDPIC and its ABI either, and the compilation of the toolchain needs between 2 and 3 hours on my desktop (and this is a professional project, so time is money).

Having seen that in other files of the library that are using array of coefficients these arrays are not rodata while they could be, I just aimed at avoiding to compile twice, once with rodata (assuming that would fail and that would explain why other files are not using rodata) and once with data (so I decided to choose the solution with a maximum luck of success).

 

Of course I did guess that a rodata should have worked; and if you don't mind, I would advise to those who will "officially" make that change to do the same in all files, a const (rodata) being, to my mind, cleaner for **all** files... But my advise stops there, since my knowledge on the topic is very poor... But my wondering keep the same, like you: does a rodata work?

 

 

Regarding the other likely impacted file, and if I correctly remember my investigation (I have not the results close to me), sqrt_fr16 is not the only one; I beleive the sqrt for float (or double) needs also to be fixed. A grep on "rodata" or something else to catch the needed changes is surely safer...

 

 

My last one-peny question: is there any plan for a full and "official" FDPIC porting of this library? If yes, does anybody know any "estimated time of arrival"?

 

Thanks for all,

Best Regards,

Jeremie

QuoteReplyEditDelete

 

 

2010-11-09 17:49:03     Re: sqrt_fr16 Functions problem

Mike Frysinger (UNITED STATES)

Message: 95712   

 

FDPIC has long been "officially" supported.  a bug or two slipping in doesnt change the support status.  Steve was simply mistaken about the status and misspoke.

 

you dont need to rebuild the whole toolchain to get an updated lib.  just run `make` with the right CROSS prefix and then copy the libbfdsp.a to right place in your toolchain.

 

ive already fixed the loads for these symbols and the related ones in the trunk svn.  there is one bug left, but i need to talk to someone who knows this code better before i can fix it.

QuoteReplyEditDelete

Attachments

    Outcomes