[FFmpeg-devel] pre discussion around Blackfin dct_quantize_bfin routine

[Marc Hoffman]

On 6/12/07, Reimar Doeffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de> wrote:
> Hello,
>
> Btw.: Do you know of debian or SuSE packages for the compilers and stuff
> needed for blackfin? As probably everyone knows by now, my main (gentoo)
> development box (the laptop I also had at LinuxTag) is probably dead
> forever so I can't do things the easy way right now :-(

Sorry to here about your dead machine Reimar, do you have something
else to work on right now?


You can get the tools and stuff at

http://blackfin.uclinux.org/gf/

I guess if one digs down into the compiler stuff, you come up with
this as the released package:
http://blackfin.uclinux.org/gf/download/frsrelease/50/2781/blackfin-toolchain-07r1-9.i386.rpm

And here is the kernel and apps distribution.

http://blackfin.uclinux.org/gf/download/frsrelease/49/2791/uClinux-dist-2007R1-RC3.tar.bz2

I personally prefer to use the svn mechanism but this works too.


>
> On Tue, Jun 12, 2007 at 11:47:33AM -0400, Marc Hoffman wrote:
> [...]
> > unsigned long long read_time (void)
>
> you must really like typing if you don't use just uint64_t *g*
>

yep, I do like that much better.

> > {
> >   unsigned long long t0;
> >   unsigned lo,hi;
> >   asm volatile ("%0=cycles; %1=cycles2;" : "=d" (lo), "=d" (hi));
> >   t0 = lo;
>
> Just out of curiousity:
> can the compiler handle "=d" (t0) ?
> getting rid of the seperate lo in some way removes one possibility for
> the compiler to mess up...
>

YEP THATS IT! just curious if r1 has really been allocated or not
tho..  I was walking through print_insn inside the compiler and %H0
just selects the successor register i.e. REGNO+1.  I'm not sure if
this really does what we want it to.

  asm volatile ("%0=cycles; %H0=cycles2;" : "=d" (t0));


.file "readtime.c";
.text;
        .align 4
.global _read_time7;
.type _read_time7, STT_FUNC;
_read_time7:
        LINK 0;
#APP
        R0=cycles; R1=cycles2;
#NO_APP
        UNLINK;
        rts;
        .size   _read_time7, .-_read_time7


> >   t0 |= (unsigned long long)hi << 32;
> >   return t0;
>
> And how about doing
> return lo + (uint64_t)hi << 32;
> ?
>

unsigned long long read_time8 (void)
{
  unsigned long long t0;
  unsigned lo,hi;
  asm volatile ("%0=cycles; %1=cycles2;" : "=d" (lo), "=d" (hi));
  return lo + (unsigned long long)hi<<32;
}

produces:

.file "readtime.c";
.text;
        .align 4
.global _read_time8;
.type _read_time8, STT_FUNC;
_read_time8:
        [--sp] = ( r7:7 );

        LINK 0;
#APP
        R0=cycles; R1=cycles2;
#NO_APP
        R3 = 0 (X);
        R2 = R0;
        R0 = R1;
        R1 = 0 (X);
        R2 = R2 + R0; cc = ac0; R7 = cc; R3 = R3 + R1; R3 = R3 + R7;
        UNLINK;
        R1 = R2;
        R0 = 0 (X);
        ( r7:7 ) = [sp++];

        rts;
        .size   _read_time8, .-_read_time8

Not what we want at all argh......  Actually its broken completely.

> I personally would just only 32 bit instead of the ugly union
> construct, at least until the compiler is fixed...



Marc