* Re: Dividing by a non-static value in carl9170-fw?
[not found] ` <201101161245.54221.chunkeey@googlemail.com>
@ 2011-01-16 12:48 ` Ignacy Gawedzki
2011-03-18 19:16 ` Ignacy Gawedzki
0 siblings, 1 reply; 8+ messages in thread
From: Ignacy Gawedzki @ 2011-01-16 12:48 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless
On Sun, Jan 16, 2011 at 12:45:53PM +0100, thus spake Christian Lamparter:
> Hello,
>
> please CC your mails to linux-wireless mailing-list in the future.
Okay, sorry about that.
> On Sunday 16 January 2011 04:16:00 Ignacy Gawedzki wrote:
> > Since I recently noticed that you added the support for the ticks_per_msec
> > field in fw, I thought it would be better to use that to convert durations
> > from ticks to milliseconds, instead of the fixed 44 literal. =)
>
> Is this a regression on my part? I don't see any references to __udivsi3_i4i
> during build.
Absolutely not. I'm talking about my (experimental) modifications to the
firmware code to measure TX frame service time and report that in msec in the
tx status.
> Also, you can almost always get around it by converting "a / b = c" to
> "a = b * c".
I doubt so, since what I need to do is roughly
msec_to_report = ticks_measured / ticks_per_msec;
my input being of course ticks_measured. :/
> > Unfortunately, it seems that dividing by a non-static value is not supported
> > natively on that platform and I get undefined reference to __udivsi3_i4i. Do
> > you, by any chance, know how to fix that? Apparently there are some support
> > libs in the toolchain's gcc with that symbol, but I just got lost in the CMake
> > file hierarchy while looking for a place to start hacking that in.
>
> No need for a hack, just get a udivsi3_i4i.S (a good place is the linux kernel
> library sources in arch/sh/lib, you could also import one from the original
> ar9170fw.git) and place it into carlfw/src. Next, you need to modify the
> carlfw/CMakeLists.txt: add src/udivsi3_i4i.S to carl9170_lib_src and put
> "set_source_files_properties(src/udivsi3_i4i.S PROPERTIES LANGUAGE C)"
> a few lines further down.
>
> compile...
>
> [Note: you probably have to change the name of the __udivsi3_i4i symbol
> to ___udivsi3_i4i too]
Great, thanks for the hint, I'll try that as soon as I can.
Regards,
Ignacy
--
To err is human, to moo bovine.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Dividing by a non-static value in carl9170-fw?
2011-01-16 12:48 ` Dividing by a non-static value in carl9170-fw? Ignacy Gawedzki
@ 2011-03-18 19:16 ` Ignacy Gawedzki
2011-03-19 0:43 ` Christian Lamparter
0 siblings, 1 reply; 8+ messages in thread
From: Ignacy Gawedzki @ 2011-03-18 19:16 UTC (permalink / raw)
To: Christian Lamparter, linux-wireless
Hi,
On Sun, Jan 16, 2011 at 01:48:33PM +0100, thus spake Ignacy Gawedzki:
> On Sun, Jan 16, 2011 at 12:45:53PM +0100, thus spake Christian Lamparter:
> > No need for a hack, just get a udivsi3_i4i.S (a good place is the linux kernel
> > library sources in arch/sh/lib, you could also import one from the original
> > ar9170fw.git) and place it into carlfw/src. Next, you need to modify the
> > carlfw/CMakeLists.txt: add src/udivsi3_i4i.S to carl9170_lib_src and put
> > "set_source_files_properties(src/udivsi3_i4i.S PROPERTIES LANGUAGE C)"
> > a few lines further down.
> >
> > compile...
> >
> > [Note: you probably have to change the name of the __udivsi3_i4i symbol
> > to ___udivsi3_i4i too]
>
> Great, thanks for the hint, I'll try that as soon as I can.
So I finally got the time to test that solution. Compilation worked like a
charm indeed, thanks. All seemed fine until I ran that code. Indeed the
result of the division is completely off. :(
For instance, if I have A = 17719, B = 44, then A / B gives C = 12886, instead
of the expected 402. It is as though the result was multiplied by 32.
At this point, it is much simpler for me to simply return both A and B, and to
perform the division on the host's CPU instead of in the FW. Unless I commit
some gross error and there is a more elegant solution around, I'll stick with
that one, since I don't feel like debugging udivsi3_i4i. :/
Ignacy
--
Information wants to be beer, or something like that.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Dividing by a non-static value in carl9170-fw?
2011-03-18 19:16 ` Ignacy Gawedzki
@ 2011-03-19 0:43 ` Christian Lamparter
2011-03-19 1:22 ` Ignacy Gawedzki
0 siblings, 1 reply; 8+ messages in thread
From: Christian Lamparter @ 2011-03-19 0:43 UTC (permalink / raw)
To: Ignacy Gawedzki; +Cc: linux-wireless
On Friday 18 March 2011 20:16:15 Ignacy Gawedzki wrote:
> On Sun, Jan 16, 2011 at 01:48:33PM +0100, thus spake Ignacy Gawedzki:
> > On Sun, Jan 16, 2011 at 12:45:53PM +0100, thus spake Christian Lamparter:
> > > No need for a hack, just get a udivsi3_i4i.S (a good place is the linux kernel
> > > library sources in arch/sh/lib, you could also import one from the original
> > > ar9170fw.git) and place it into carlfw/src. Next, you need to modify the
> > > carlfw/CMakeLists.txt: add src/udivsi3_i4i.S to carl9170_lib_src and put
> > > "set_source_files_properties(src/udivsi3_i4i.S PROPERTIES LANGUAGE C)"
> > > a few lines further down.
> > >
> > > compile...
> > >
> > > [Note: you probably have to change the name of the __udivsi3_i4i symbol
> > > to ___udivsi3_i4i too]
> >
> > Great, thanks for the hint, I'll try that as soon as I can.
>
> So I finally got the time to test that solution. Compilation worked like a
> charm indeed, thanks. All seemed fine until I ran that code. Indeed the
> result of the division is completely off. :(
>
> For instance, if I have A = 17719, B = 44, then A / B gives C = 12886, instead
> of the expected 402. It is as though the result was multiplied by 32.
I gave it a try and It worked?!
[54670.551750] ieee80211 phy14: FW: a:0x4537 b:0x2c a/b:0x192 (0x192 = 402).
(It was nothing else than just define "a" and "b" (as global variables) and
add the INFO("a:0x%x b:0x%x a/b:0x%x", a, b, a/b);)
Regards,
Chr
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Dividing by a non-static value in carl9170-fw?
2011-03-19 0:43 ` Christian Lamparter
@ 2011-03-19 1:22 ` Ignacy Gawedzki
2011-03-19 2:03 ` Christian Lamparter
0 siblings, 1 reply; 8+ messages in thread
From: Ignacy Gawedzki @ 2011-03-19 1:22 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless
[-- Attachment #1: Type: text/plain, Size: 717 bytes --]
On Sat, Mar 19, 2011 at 01:43:26AM +0100, thus spake Christian Lamparter:
> I gave it a try and It worked?!
>
> [54670.551750] ieee80211 phy14: FW: a:0x4537 b:0x2c a/b:0x192 (0x192 = 402).
>
> (It was nothing else than just define "a" and "b" (as global variables) and
> add the INFO("a:0x%x b:0x%x a/b:0x%x", a, b, a/b);)
I suppose in your case the values are known at compile time and the compiler
does the calculation statically. If you define the global variables as
volatile, then the optimization is forbidden and you should get the bogus
results.
BTW, I used udivsi3_i4i.S from the Linux kernel, modified it as you indicated.
Please find my version attached.
Ignacy
--
To err is human, to purr feline.
[-- Attachment #2: udivsi3_i4i.S --]
[-- Type: text/plain, Size: 10247 bytes --]
/* Copyright (C) 1994, 1995, 1997, 1998, 1999, 2000, 2001, 2002, 2003,
2004, 2005, 2006
Free Software Foundation, Inc.
This file is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the
Free Software Foundation; either version 2, or (at your option) any
later version.
In addition to the permissions in the GNU General Public License, the
Free Software Foundation gives you unlimited permission to link the
compiled version of this file into combinations with other programs,
and to distribute those combinations without any restriction coming
from the use of this file. (The General Public License restrictions
do apply in other respects; for example, they cover modification of
the file, and distribution when not linked into a combine
executable.)
This file is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; see the file COPYING. If not, write to
the Free Software Foundation, 51 Franklin Street, Fifth Floor,
Boston, MA 02110-1301, USA. */
!! libgcc routines for the Renesas / SuperH SH CPUs.
!! Contributed by Steve Chamberlain.
!! sac@cygnus.com
!! ashiftrt_r4_x, ___ashrsi3, ___ashlsi3, ___lshrsi3 routines
!! recoded in assembly by Toshiyasu Morita
!! tm@netcom.com
/* SH2 optimizations for ___ashrsi3, ___ashlsi3, ___lshrsi3 and
ELF local label prefixes by J"orn Rennecke
amylaar@cygnus.com */
/* This code used shld, thus is not suitable for SH1 / SH2. */
/* Signed / unsigned division without use of FPU, optimized for SH4.
Uses a lookup table for divisors in the range -128 .. +128, and
div1 with case distinction for larger divisors in three more ranges.
The code is lumped together with the table to allow the use of mova. */
#ifdef CONFIG_CPU_LITTLE_ENDIAN
#define L_LSB 0
#define L_LSWMSB 1
#define L_MSWLSB 2
#else
#define L_LSB 3
#define L_LSWMSB 2
#define L_MSWLSB 1
#endif
.balign 4
.global ___udivsi3_i4i
.global ___udivsi3_i4
.set ___udivsi3_i4, ___udivsi3_i4i
.type ___udivsi3_i4i, @function
___udivsi3_i4i:
mov.w c128_w, r1
div0u
mov r4,r0
shlr8 r0
cmp/hi r1,r5
extu.w r5,r1
bf udiv_le128
cmp/eq r5,r1
bf udiv_ge64k
shlr r0
mov r5,r1
shll16 r5
mov.l r4,@-r15
div1 r5,r0
mov.l r1,@-r15
div1 r5,r0
div1 r5,r0
bra udiv_25
div1 r5,r0
div_le128:
mova div_table_ix,r0
bra div_le128_2
mov.b @(r0,r5),r1
udiv_le128:
mov.l r4,@-r15
mova div_table_ix,r0
mov.b @(r0,r5),r1
mov.l r5,@-r15
div_le128_2:
mova div_table_inv,r0
mov.l @(r0,r1),r1
mov r5,r0
tst #0xfe,r0
mova div_table_clz,r0
dmulu.l r1,r4
mov.b @(r0,r5),r1
bt/s div_by_1
mov r4,r0
mov.l @r15+,r5
sts mach,r0
/* clrt */
addc r4,r0
mov.l @r15+,r4
rotcr r0
rts
shld r1,r0
div_by_1_neg:
neg r4,r0
div_by_1:
mov.l @r15+,r5
rts
mov.l @r15+,r4
div_ge64k:
bt/s div_r8
div0u
shll8 r5
bra div_ge64k_2
div1 r5,r0
udiv_ge64k:
cmp/hi r0,r5
mov r5,r1
bt udiv_r8
shll8 r5
mov.l r4,@-r15
div1 r5,r0
mov.l r1,@-r15
div_ge64k_2:
div1 r5,r0
mov.l zero_l,r1
.rept 4
div1 r5,r0
.endr
mov.l r1,@-r15
div1 r5,r0
mov.w m256_w,r1
div1 r5,r0
mov.b r0,@(L_LSWMSB,r15)
xor r4,r0
and r1,r0
bra div_ge64k_end
xor r4,r0
div_r8:
shll16 r4
bra div_r8_2
shll8 r4
udiv_r8:
mov.l r4,@-r15
shll16 r4
clrt
shll8 r4
mov.l r5,@-r15
div_r8_2:
rotcl r4
mov r0,r1
div1 r5,r1
mov r4,r0
rotcl r0
mov r5,r4
div1 r5,r1
.rept 5
rotcl r0; div1 r5,r1
.endr
rotcl r0
mov.l @r15+,r5
div1 r4,r1
mov.l @r15+,r4
rts
rotcl r0
.global ___sdivsi3_i4i
.global ___sdivsi3_i4
.global ___sdivsi3
.set ___sdivsi3_i4, ___sdivsi3_i4i
.set ___sdivsi3, ___sdivsi3_i4i
.type ___sdivsi3_i4i, @function
/* This is link-compatible with a __sdivsi3 call,
but we effectively clobber only r1. */
___sdivsi3_i4i:
mov.l r4,@-r15
cmp/pz r5
mov.w c128_w, r1
bt/s pos_divisor
cmp/pz r4
mov.l r5,@-r15
neg r5,r5
bt/s neg_result
cmp/hi r1,r5
neg r4,r4
pos_result:
extu.w r5,r0
bf div_le128
cmp/eq r5,r0
mov r4,r0
shlr8 r0
bf/s div_ge64k
cmp/hi r0,r5
div0u
shll16 r5
div1 r5,r0
div1 r5,r0
div1 r5,r0
udiv_25:
mov.l zero_l,r1
div1 r5,r0
div1 r5,r0
mov.l r1,@-r15
.rept 3
div1 r5,r0
.endr
mov.b r0,@(L_MSWLSB,r15)
xtrct r4,r0
swap.w r0,r0
.rept 8
div1 r5,r0
.endr
mov.b r0,@(L_LSWMSB,r15)
div_ge64k_end:
.rept 8
div1 r5,r0
.endr
mov.l @r15+,r4 ! zero-extension and swap using LS unit.
extu.b r0,r0
mov.l @r15+,r5
or r4,r0
mov.l @r15+,r4
rts
rotcl r0
div_le128_neg:
tst #0xfe,r0
mova div_table_ix,r0
mov.b @(r0,r5),r1
mova div_table_inv,r0
bt/s div_by_1_neg
mov.l @(r0,r1),r1
mova div_table_clz,r0
dmulu.l r1,r4
mov.b @(r0,r5),r1
mov.l @r15+,r5
sts mach,r0
/* clrt */
addc r4,r0
mov.l @r15+,r4
rotcr r0
shld r1,r0
rts
neg r0,r0
pos_divisor:
mov.l r5,@-r15
bt/s pos_result
cmp/hi r1,r5
neg r4,r4
neg_result:
extu.w r5,r0
bf div_le128_neg
cmp/eq r5,r0
mov r4,r0
shlr8 r0
bf/s div_ge64k_neg
cmp/hi r0,r5
div0u
mov.l zero_l,r1
shll16 r5
div1 r5,r0
mov.l r1,@-r15
.rept 7
div1 r5,r0
.endr
mov.b r0,@(L_MSWLSB,r15)
xtrct r4,r0
swap.w r0,r0
.rept 8
div1 r5,r0
.endr
mov.b r0,@(L_LSWMSB,r15)
div_ge64k_neg_end:
.rept 8
div1 r5,r0
.endr
mov.l @r15+,r4 ! zero-extension and swap using LS unit.
extu.b r0,r1
mov.l @r15+,r5
or r4,r1
div_r8_neg_end:
mov.l @r15+,r4
rotcl r1
rts
neg r1,r0
div_ge64k_neg:
bt/s div_r8_neg
div0u
shll8 r5
mov.l zero_l,r1
.rept 6
div1 r5,r0
.endr
mov.l r1,@-r15
div1 r5,r0
mov.w m256_w,r1
div1 r5,r0
mov.b r0,@(L_LSWMSB,r15)
xor r4,r0
and r1,r0
bra div_ge64k_neg_end
xor r4,r0
c128_w:
.word 128
div_r8_neg:
clrt
shll16 r4
mov r4,r1
shll8 r1
mov r5,r4
.rept 7
rotcl r1; div1 r5,r0
.endr
mov.l @r15+,r5
rotcl r1
bra div_r8_neg_end
div1 r4,r0
m256_w:
.word 0xff00
/* This table has been generated by divtab-sh4.c. */
.balign 4
div_table_clz:
.byte 0
.byte 1
.byte 0
.byte -1
.byte -1
.byte -2
.byte -2
.byte -2
.byte -2
.byte -3
.byte -3
.byte -3
.byte -3
.byte -3
.byte -3
.byte -3
.byte -3
.byte -4
.byte -4
.byte -4
.byte -4
.byte -4
.byte -4
.byte -4
.byte -4
.byte -4
.byte -4
.byte -4
.byte -4
.byte -4
.byte -4
.byte -4
.byte -4
.byte -5
.byte -5
.byte -5
.byte -5
.byte -5
.byte -5
.byte -5
.byte -5
.byte -5
.byte -5
.byte -5
.byte -5
.byte -5
.byte -5
.byte -5
.byte -5
.byte -5
.byte -5
.byte -5
.byte -5
.byte -5
.byte -5
.byte -5
.byte -5
.byte -5
.byte -5
.byte -5
.byte -5
.byte -5
.byte -5
.byte -5
.byte -5
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
.byte -6
/* Lookup table translating positive divisor to index into table of
normalized inverse. N.B. the '0' entry is also the last entry of the
previous table, and causes an unaligned access for division by zero. */
div_table_ix:
.byte -6
.byte -128
.byte -128
.byte 0
.byte -128
.byte -64
.byte 0
.byte 64
.byte -128
.byte -96
.byte -64
.byte -32
.byte 0
.byte 32
.byte 64
.byte 96
.byte -128
.byte -112
.byte -96
.byte -80
.byte -64
.byte -48
.byte -32
.byte -16
.byte 0
.byte 16
.byte 32
.byte 48
.byte 64
.byte 80
.byte 96
.byte 112
.byte -128
.byte -120
.byte -112
.byte -104
.byte -96
.byte -88
.byte -80
.byte -72
.byte -64
.byte -56
.byte -48
.byte -40
.byte -32
.byte -24
.byte -16
.byte -8
.byte 0
.byte 8
.byte 16
.byte 24
.byte 32
.byte 40
.byte 48
.byte 56
.byte 64
.byte 72
.byte 80
.byte 88
.byte 96
.byte 104
.byte 112
.byte 120
.byte -128
.byte -124
.byte -120
.byte -116
.byte -112
.byte -108
.byte -104
.byte -100
.byte -96
.byte -92
.byte -88
.byte -84
.byte -80
.byte -76
.byte -72
.byte -68
.byte -64
.byte -60
.byte -56
.byte -52
.byte -48
.byte -44
.byte -40
.byte -36
.byte -32
.byte -28
.byte -24
.byte -20
.byte -16
.byte -12
.byte -8
.byte -4
.byte 0
.byte 4
.byte 8
.byte 12
.byte 16
.byte 20
.byte 24
.byte 28
.byte 32
.byte 36
.byte 40
.byte 44
.byte 48
.byte 52
.byte 56
.byte 60
.byte 64
.byte 68
.byte 72
.byte 76
.byte 80
.byte 84
.byte 88
.byte 92
.byte 96
.byte 100
.byte 104
.byte 108
.byte 112
.byte 116
.byte 120
.byte 124
.byte -128
/* 1/64 .. 1/127, normalized. There is an implicit leading 1 in bit 32. */
.balign 4
zero_l:
.long 0x0
.long 0xF81F81F9
.long 0xF07C1F08
.long 0xE9131AC0
.long 0xE1E1E1E2
.long 0xDAE6076C
.long 0xD41D41D5
.long 0xCD856891
.long 0xC71C71C8
.long 0xC0E07039
.long 0xBACF914D
.long 0xB4E81B4F
.long 0xAF286BCB
.long 0xA98EF607
.long 0xA41A41A5
.long 0x9EC8E952
.long 0x9999999A
.long 0x948B0FCE
.long 0x8F9C18FA
.long 0x8ACB90F7
.long 0x86186187
.long 0x81818182
.long 0x7D05F418
.long 0x78A4C818
.long 0x745D1746
.long 0x702E05C1
.long 0x6C16C16D
.long 0x68168169
.long 0x642C8591
.long 0x60581606
.long 0x5C9882BA
.long 0x58ED2309
div_table_inv:
.long 0x55555556
.long 0x51D07EAF
.long 0x4E5E0A73
.long 0x4AFD6A06
.long 0x47AE147B
.long 0x446F8657
.long 0x41414142
.long 0x3E22CBCF
.long 0x3B13B13C
.long 0x38138139
.long 0x3521CFB3
.long 0x323E34A3
.long 0x2F684BDB
.long 0x2C9FB4D9
.long 0x29E4129F
.long 0x27350B89
.long 0x24924925
.long 0x21FB7813
.long 0x1F7047DD
.long 0x1CF06ADB
.long 0x1A7B9612
.long 0x18118119
.long 0x15B1E5F8
.long 0x135C8114
.long 0x11111112
.long 0xECF56BF
.long 0xC9714FC
.long 0xA6810A7
.long 0x8421085
.long 0x624DD30
.long 0x4104105
.long 0x2040811
/* maximum error: 0.987342 scaled: 0.921875*/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Dividing by a non-static value in carl9170-fw?
2011-03-19 1:22 ` Ignacy Gawedzki
@ 2011-03-19 2:03 ` Christian Lamparter
2011-03-19 9:22 ` Ignacy Gawedzki
0 siblings, 1 reply; 8+ messages in thread
From: Christian Lamparter @ 2011-03-19 2:03 UTC (permalink / raw)
To: Ignacy Gawedzki; +Cc: linux-wireless
[-- Attachment #1: Type: Text/Plain, Size: 1569 bytes --]
On Saturday 19 March 2011 02:22:44 Ignacy Gawedzki wrote:
> On Sat, Mar 19, 2011 at 01:43:26AM +0100, thus spake Christian Lamparter:
> > I gave it a try and It worked?!
> >
> > [54670.551750] ieee80211 phy14: FW: a:0x4537 b:0x2c a/b:0x192 (0x192 = 402).
> >
> > (It was nothing else than just define "a" and "b" (as global variables) and
> > add the INFO("a:0x%x b:0x%x a/b:0x%x", a, b, a/b);)
>
> I suppose in your case the values are known at compile time and the compiler
> does the calculation statically.
sometimes its just down to "luck" ;)
> If you define the global variables as volatile, then the optimization is
> forbidden and you should get the bogus results.
???
No, "global" is enough. As long as you don't select "const".
(In fact there's more of a story behind "const volatile"
than you might think, or have you ever wondered why carl9170
still ships with gcc 4.4 instead of 4.5? Anyway that's OT)
> BTW, I used udivsi3_i4i.S from the Linux kernel, modified it as you indicated.
> Please find my version attached.
You are right, I can reproduce your problem with the attached udiv.
The crux is seems to be "hidden" inside the kernel's Makefile:
>udivsi3-y := udivsi3_i4i-Os.o
>
>ifneq ($(CONFIG_CC_OPTIMIZE_FOR_SIZE),y)
>udivsi3-$(CONFIG_CPU_SH3) := udivsi3_i4i.o
>udivsi3-$(CONFIG_CPU_SH4) := udivsi3_i4i.o
>endif
It looks like the version you are using is "made" for SH3+,
however the AR9170 has a SH2. (Jup, I can't believe it either :-D)
Best Regards,
Chr
(didn't really bother with the "signed" div.)
[-- Attachment #2: udivsi3_i4i-Os.S --]
[-- Type: text/x-csrc, Size: 3461 bytes --]
/* Copyright (C) 2006 Free Software Foundation, Inc.
This file is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the
Free Software Foundation; either version 2, or (at your option) any
later version.
In addition to the permissions in the GNU General Public License, the
Free Software Foundation gives you unlimited permission to link the
compiled version of this file into combinations with other programs,
and to distribute those combinations without any restriction coming
from the use of this file. (The General Public License restrictions
do apply in other respects; for example, they cover modification of
the file, and distribution when not linked into a combine
executable.)
This file is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; see the file COPYING. If not, write to
the Free Software Foundation, 51 Franklin Street, Fifth Floor,
Boston, MA 02110-1301, USA. */
/* Moderately Space-optimized libgcc routines for the Renesas SH /
STMicroelectronics ST40 CPUs.
Contributed by J"orn Rennecke joern.rennecke@st.com. */
/* Size: 186 bytes jointly for udivsi3_i4i and sdivsi3_i4i
sh4-200 run times:
udiv small divisor: 55 cycles
udiv large divisor: 52 cycles
sdiv small divisor, positive result: 59 cycles
sdiv large divisor, positive result: 56 cycles
sdiv small divisor, negative result: 65 cycles (*)
sdiv large divisor, negative result: 62 cycles (*)
(*): r2 is restored in the rts delay slot and has a lingering latency
of two more cycles. */
.balign 4
.global ___udivsi3_i4i
.global ___sdivsi3_i4i
.global ___udivsi3_i4
.set ___udivsi3_i4, ___udivsi3_i4i
.type ___udivsi3_i4i, @function
.type ___sdivsi3_i4i, @function
___udivsi3_i4i:
___sdivsi3_i4i:
sts pr,r1
mov.l r4,@-r15
extu.w r5,r0
cmp/eq r5,r0
swap.w r4,r0
shlr16 r4
bf/s large_divisor
div0u
mov.l r5,@-r15
shll16 r5
sdiv_small_divisor:
div1 r5,r4
bsr div6
div1 r5,r4
div1 r5,r4
bsr div6
div1 r5,r4
xtrct r4,r0
xtrct r0,r4
bsr div7
swap.w r4,r4
div1 r5,r4
bsr div7
div1 r5,r4
xtrct r4,r0
mov.l @r15+,r5
swap.w r0,r0
mov.l @r15+,r4
jmp @r1
rotcl r0
div7:
div1 r5,r4
div6:
div1 r5,r4; div1 r5,r4; div1 r5,r4
div1 r5,r4; div1 r5,r4; rts; div1 r5,r4
divx3:
rotcl r0
div1 r5,r4
rotcl r0
div1 r5,r4
rotcl r0
rts
div1 r5,r4
large_divisor:
mov.l r5,@-r15
sdiv_large_divisor:
xor r4,r0
.rept 4
rotcl r0
bsr divx3
div1 r5,r4
.endr
mov.l @r15+,r5
mov.l @r15+,r4
jmp @r1
rotcl r0
.global __sdivsi3_i4i
.global __sdivsi3_i4
.global __sdivsi3
.set __sdivsi3_i4, __sdivsi3_i4i
.set __sdivsi3, __sdivsi3_i4i
__sdivsi3_i4i:
mov.l r4,@-r15
cmp/pz r5
mov.l r5,@-r15
bt/s pos_divisor
cmp/pz r4
neg r5,r5
extu.w r5,r0
bt/s neg_result
cmp/eq r5,r0
neg r4,r4
pos_result:
swap.w r4,r0
bra sdiv_check_divisor
sts pr,r1
pos_divisor:
extu.w r5,r0
bt/s pos_result
cmp/eq r5,r0
neg r4,r4
neg_result:
mova negate_result,r0
;
mov r0,r1
swap.w r4,r0
lds r2,macl
sts pr,r2
sdiv_check_divisor:
shlr16 r4
bf/s sdiv_large_divisor
div0u
bra sdiv_small_divisor
shll16 r5
.balign 4
negate_result:
neg r0,r0
jmp @r2
sts macl,r2
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Dividing by a non-static value in carl9170-fw?
2011-03-19 2:03 ` Christian Lamparter
@ 2011-03-19 9:22 ` Ignacy Gawedzki
2011-03-19 15:43 ` Christian Lamparter
0 siblings, 1 reply; 8+ messages in thread
From: Ignacy Gawedzki @ 2011-03-19 9:22 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless
On Sat, Mar 19, 2011 at 03:03:06AM +0100, thus spake Christian Lamparter:
> On Saturday 19 March 2011 02:22:44 Ignacy Gawedzki wrote:
> > I suppose in your case the values are known at compile time and the compiler
> > does the calculation statically.
> sometimes its just down to "luck" ;)
>
> > If you define the global variables as volatile, then the optimization is
> > forbidden and you should get the bogus results.
>
> ???
> No, "global" is enough. As long as you don't select "const".
> (In fact there's more of a story behind "const volatile"
> than you might think, or have you ever wondered why carl9170
> still ships with gcc 4.4 instead of 4.5? Anyway that's OT)
As a rule of thumb, I remembered that "volatile" tells the compiler "you're
not the only one to manage that variable, don't make any assumptions about its
current value", as could be the case if the variable is allocated in some
shared memory segment/register/whatever and might change "on its own".
Anyway, in the case at hand, it seems to make a difference.
> > BTW, I used udivsi3_i4i.S from the Linux kernel, modified it as you indicated.
> > Please find my version attached.
> You are right, I can reproduce your problem with the attached udiv.
> The crux is seems to be "hidden" inside the kernel's Makefile:
>
> >udivsi3-y := udivsi3_i4i-Os.o
> >
> >ifneq ($(CONFIG_CC_OPTIMIZE_FOR_SIZE),y)
> >udivsi3-$(CONFIG_CPU_SH3) := udivsi3_i4i.o
> >udivsi3-$(CONFIG_CPU_SH4) := udivsi3_i4i.o
> >endif
>
> It looks like the version you are using is "made" for SH3+,
> however the AR9170 has a SH2. (Jup, I can't believe it either :-D)
Ahaaa. Thanks for your help. It works much better now.
BTW, it seems you have some detailed technical documentation about the AR9170
at your disposal. I was wondering whether this is something available
publicly or not. Could be an interesting read at times. =)
Regards,
Ignacy
--
Everything is more fun naked except cooking with grease.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Dividing by a non-static value in carl9170-fw?
2011-03-19 9:22 ` Ignacy Gawedzki
@ 2011-03-19 15:43 ` Christian Lamparter
2011-03-21 11:05 ` Ignacy Gawedzki
0 siblings, 1 reply; 8+ messages in thread
From: Christian Lamparter @ 2011-03-19 15:43 UTC (permalink / raw)
To: Ignacy Gawedzki; +Cc: linux-wireless
On Saturday 19 March 2011 10:22:37 Ignacy Gawedzki wrote:
> On Sat, Mar 19, 2011 at 03:03:06AM +0100, thus spake Christian Lamparter:
> > On Saturday 19 March 2011 02:22:44 Ignacy Gawedzki wrote:
> > > If you define the global variables as volatile, then the optimization is
> > > forbidden and you should get the bogus results.
> >
> > ???
> > No, "global" is enough. As long as you don't select "const".
> > (In fact there's more of a story behind "const volatile"
> > than you might think, or have you ever wondered why carl9170
> > still ships with gcc 4.4 instead of 4.5? Anyway that's OT)
>
> As a rule of thumb, I remembered that "volatile" tells the compiler "you're
> not the only one to manage that variable, don't make any assumptions about its
> current value", as could be the case if the variable is allocated in some
> shared memory segment/register/whatever and might change "on its own".
> Anyway, in the case at hand, it seems to make a difference.
why not give it a try ;). define a and b as global variables, initialize them
and try if a/b needs __udiv or not. you'll be surprised that no c-compiler
(unless a buggy one) will even think about this sort of "constant"
optimization.
OT: the use of volatile is ill-reputed and many people have complained
about it throughout the history.
http://lwn.net/Articles/233482/ [which ended up in:]
http://kernel.org/doc/Documentation/volatile-considered-harmful.txt
the only reason why we get away with it is because most of
it is locked up behind accessor functions in include/io.h & dma.h
and it should remain that way.
> BTW, it seems you have some detailed technical documentation about the AR9170
> at your disposal. I was wondering whether this is something available
> publicly or not. Could be an interesting read at times. =)
There are a lot of easy accessible docs about the CPU on the net. In fact you
can even get Verilog/VHDL code of various SH2-clones without any problem.
But that's about it, for information about the MAC/USB I have to rely on
Chen.
Best regards,
Christian
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Dividing by a non-static value in carl9170-fw?
2011-03-19 15:43 ` Christian Lamparter
@ 2011-03-21 11:05 ` Ignacy Gawedzki
0 siblings, 0 replies; 8+ messages in thread
From: Ignacy Gawedzki @ 2011-03-21 11:05 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless
On Sat, Mar 19, 2011 at 04:43:46PM +0100, thus spake Christian Lamparter:
> On Saturday 19 March 2011 10:22:37 Ignacy Gawedzki wrote:
> > As a rule of thumb, I remembered that "volatile" tells the compiler "you're
> > not the only one to manage that variable, don't make any assumptions about its
> > current value", as could be the case if the variable is allocated in some
> > shared memory segment/register/whatever and might change "on its own".
> > Anyway, in the case at hand, it seems to make a difference.
>
> why not give it a try ;). define a and b as global variables, initialize them
> and try if a/b needs __udiv or not. you'll be surprised that no c-compiler
> (unless a buggy one) will even think about this sort of "constant"
> optimization.
I almost forgot to reply to this one. Of course you were right and optimizing
globals in this way doesn't make sense anyway. After noticing the unexpected
behavior, I disassembled the object file and saw that the result of the
division was used as an immediate value. Eventually, after this round of
email exchange, I realized that it was all due to my globals being declared as
"static", just for the sake of uniformity with other globals already there. =)
When globals' scope is limited to the compilation unit, the compiler may
optimize things out.
> OT: the use of volatile is ill-reputed and many people have complained
> about it throughout the history.
> http://lwn.net/Articles/233482/ [which ended up in:]
> http://kernel.org/doc/Documentation/volatile-considered-harmful.txt
>
> the only reason why we get away with it is because most of
> it is locked up behind accessor functions in include/io.h & dma.h
> and it should remain that way.
>
> > BTW, it seems you have some detailed technical documentation about the AR9170
> > at your disposal. I was wondering whether this is something available
> > publicly or not. Could be an interesting read at times. =)
> There are a lot of easy accessible docs about the CPU on the net. In fact you
> can even get Verilog/VHDL code of various SH2-clones without any problem.
> But that's about it, for information about the MAC/USB I have to rely on
> Chen.
I see.
Thanks again.
Ignacy
--
NO CARRIER
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2011-03-21 11:05 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20110116031600.GA21973@zenon.in.qult.net>
[not found] ` <201101161245.54221.chunkeey@googlemail.com>
2011-01-16 12:48 ` Dividing by a non-static value in carl9170-fw? Ignacy Gawedzki
2011-03-18 19:16 ` Ignacy Gawedzki
2011-03-19 0:43 ` Christian Lamparter
2011-03-19 1:22 ` Ignacy Gawedzki
2011-03-19 2:03 ` Christian Lamparter
2011-03-19 9:22 ` Ignacy Gawedzki
2011-03-19 15:43 ` Christian Lamparter
2011-03-21 11:05 ` Ignacy Gawedzki
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).