Broken asm/div64.h macro

Broken asm/div64.h macro

[Troy Benjegerdes]

Our div64.h macro is quite broken, and causes printk to not be able to do
a long long format.

Is there a 'fast' generic C algorithm we can replace it with, instead of
mucking with ASM?

--
Troy Benjegerdes | master of mispeeling | 'da hozer' |  hozer@drgw.net
-----"If this message isn't misspelled, I didn't write it" -- Me -----
"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't. That's
why I draw cartoons. It's my life." -- Charles Schulz

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Broken asm/div64.h macro

[Geert Uytterhoeven]

On Sat, 26 Jan 2002, Troy Benjegerdes wrote:
> Our div64.h macro is quite broken, and causes printk to not be able to do
> a long long format.
>
> Is there a 'fast' generic C algorithm we can replace it with, instead of
> mucking with ASM?

Usually you can copy the asm version from the gcc sources (libgcc).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Broken asm/div64.h macro

[Gabriel Paubert]

On Sat, 26 Jan 2002, Troy Benjegerdes wrote:

>
> Our div64.h macro is quite broken, and causes printk to not be able to do
> a long long format.
>
> Is there a 'fast' generic C algorithm we can replace it with, instead of
> mucking with ASM?

If depends on what you want from do_div. If you guarantee that in
do_div(n,base) base will be constant it's fairly easy (provided GCC does
proper constant propagation). I also have the expanded code for 10
explicitly somewhere in prepboot, I just wrote it for fun for my own
printb(==printk for bootloader). I also wrote a generic 64 by 32 divide
for the x86 ROM BIOS emulator (stupid looping, slow but ok for this, I
short-circuit it for 32/32 divides which are the most common).

On a somewhat relared topic, there is also an inverse estimator to use
mulhwu somewhere in the time code (mulhwu_scale_factor IIRC what I
wrote:-)), but it's deliberately compact and slow.

Which flavour would you prefer ? (The one in do_div is only for 64 bit
targets, someone clearly goofed on that one).

	Regards,
	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Broken asm/div64.h macro

[Momchil Velikov]

>>>>> "Troy" == Troy Benjegerdes <hozer@drgw.net> writes:

Troy> Our div64.h macro is quite broken, and causes printk to not be able to do
Troy> a long long format.

Troy> Is there a 'fast' generic C algorithm we can replace it with, instead of
Troy> mucking with ASM?

Hmm, I sent a patchlet to lkml with Subject: [PATCH] 64-bit divide tweaks.

Doesn't it work for you ?

Regards,
-velco

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Broken asm/div64.h macro

[Troy Benjegerdes]

On Sun, Jan 27, 2002 at 12:51:42AM +0200, Momchil Velikov wrote:
> >>>>> "Troy" == Troy Benjegerdes <hozer@drgw.net> writes:
>
> Troy> Our div64.h macro is quite broken, and causes printk to not be able to do
> Troy> a long long format.
>
> Troy> Is there a 'fast' generic C algorithm we can replace it with, instead of
> Troy> mucking with ASM?
>
> Hmm, I sent a patchlet to lkml with Subject: [PATCH] 64-bit divide tweaks.
>
> Doesn't it work for you ?

Didn't seee it..

Did you actually try compiling PPC this way??

vsprintf.o(.text+0x494): undefined reference to `__umoddi3'
vsprintf.o(.text+0x494): relocation truncated to fit: R_PPC_REL24
__umoddi3
vsprintf.o(.text+0x4ac): undefined reference to `__udivdi3'
vsprintf.o(.text+0x4ac): relocation truncated to fit: R_PPC_REL24
__udivdi3

--
Troy Benjegerdes | master of mispeeling | 'da hozer' |  hozer@drgw.net
-----"If this message isn't misspelled, I didn't write it" -- Me -----
"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't. That's
why I draw cartoons. It's my life." -- Charles Schulz

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Broken asm/div64.h macro

[Kaoru Fukui]

On 27 Jan, Troy Benjegerdes wrote:
> Did you actually try compiling PPC this way??
>
> vsprintf.o(.text+0x494): undefined reference to `__umoddi3'
> vsprintf.o(.text+0x494): relocation truncated to fit: R_PPC_REL24
> __umoddi3
> vsprintf.o(.text+0x4ac): undefined reference to `__udivdi3'
> vsprintf.o(.text+0x4ac): relocation truncated to fit: R_PPC_REL24
> __udivdi3

libgcc.a has those libraries.

Kaoru


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Broken asm/div64.h macro

[Momchil Velikov]

>>>>> "Kaoru" == Kaoru Fukui <k_fukui@highway.ne.jp> writes:

Kaoru> On 27 Jan, Troy Benjegerdes wrote:
>> Did you actually try compiling PPC this way??
>>
>> vsprintf.o(.text+0x494): undefined reference to `__umoddi3'
>> vsprintf.o(.text+0x494): relocation truncated to fit: R_PPC_REL24
>> __umoddi3
>> vsprintf.o(.text+0x4ac): undefined reference to `__udivdi3'
>> vsprintf.o(.text+0x4ac): relocation truncated to fit: R_PPC_REL24
>> __udivdi3

Kaoru> libgcc.a has those libraries.

Yeah, but we don't link with libgcc.a. (which I forgot).

I'll do something along the lines of
#ifndef __HAVE_ARCH_DO_DIV
...
#endif

... soon.

Regards,
-velco


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Broken asm/div64.h macro

[Tom Rini]

On Mon, Jan 28, 2002 at 10:16:28AM +0200, Momchil Velikov wrote:
>
> >>>>> "Kaoru" == Kaoru Fukui <k_fukui@highway.ne.jp> writes:
>
> Kaoru> On 27 Jan, Troy Benjegerdes wrote:
> >> Did you actually try compiling PPC this way??
> >>
> >> vsprintf.o(.text+0x494): undefined reference to `__umoddi3'
> >> vsprintf.o(.text+0x494): relocation truncated to fit: R_PPC_REL24
> >> __umoddi3
> >> vsprintf.o(.text+0x4ac): undefined reference to `__udivdi3'
> >> vsprintf.o(.text+0x4ac): relocation truncated to fit: R_PPC_REL24
> >> __udivdi3
>
> Kaoru> libgcc.a has those libraries.
>
> Yeah, but we don't link with libgcc.a. (which I forgot).

Er, but isn't it (sort-of) considered a bug if the kernel links with
libgcc.a ?  I think the consensious on l-k would be yes.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Broken asm/div64.h macro

[Geert Uytterhoeven]

On Mon, 28 Jan 2002, Tom Rini wrote:
> On Mon, Jan 28, 2002 at 10:16:28AM +0200, Momchil Velikov wrote:
> > >>>>> "Kaoru" == Kaoru Fukui <k_fukui@highway.ne.jp> writes:
> >
> > Kaoru> On 27 Jan, Troy Benjegerdes wrote:
> > >> Did you actually try compiling PPC this way??
> > >>
> > >> vsprintf.o(.text+0x494): undefined reference to `__umoddi3'
> > >> vsprintf.o(.text+0x494): relocation truncated to fit: R_PPC_REL24
> > >> __umoddi3
> > >> vsprintf.o(.text+0x4ac): undefined reference to `__udivdi3'
> > >> vsprintf.o(.text+0x4ac): relocation truncated to fit: R_PPC_REL24
> > >> __udivdi3
> >
> > Kaoru> libgcc.a has those libraries.
> >
> > Yeah, but we don't link with libgcc.a. (which I forgot).
>
> Er, but isn't it (sort-of) considered a bug if the kernel links with
> libgcc.a ?  I think the consensious on l-k would be yes.

So you copy the code from the libgcc sources, cfr. arch/m68k/lib/.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Broken asm/div64.h macro

[Tom Rini]

On Mon, Jan 28, 2002 at 08:45:31PM +0100, Geert Uytterhoeven wrote:
> On Mon, 28 Jan 2002, Tom Rini wrote:
> > On Mon, Jan 28, 2002 at 10:16:28AM +0200, Momchil Velikov wrote:
> > > >>>>> "Kaoru" == Kaoru Fukui <k_fukui@highway.ne.jp> writes:
> > >
> > > Kaoru> On 27 Jan, Troy Benjegerdes wrote:
> > > >> Did you actually try compiling PPC this way??
> > > >>
> > > >> vsprintf.o(.text+0x494): undefined reference to `__umoddi3'
> > > >> vsprintf.o(.text+0x494): relocation truncated to fit: R_PPC_REL24
> > > >> __umoddi3
> > > >> vsprintf.o(.text+0x4ac): undefined reference to `__udivdi3'
> > > >> vsprintf.o(.text+0x4ac): relocation truncated to fit: R_PPC_REL24
> > > >> __udivdi3
> > >
> > > Kaoru> libgcc.a has those libraries.
> > >
> > > Yeah, but we don't link with libgcc.a. (which I forgot).
> >
> > Er, but isn't it (sort-of) considered a bug if the kernel links with
> > libgcc.a ?  I think the consensious on l-k would be yes.
>
> So you copy the code from the libgcc sources, cfr. arch/m68k/lib/.

Or optimize that, yes.  But linking directly is a no-no. :)

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Broken asm/div64.h macro

[Kaoru Fukui]

On 28 Jan, Tom Rini wrote:
> On Mon, Jan 28, 2002 at 08:45:31PM +0100, Geert Uytterhoeven wrote:
>> On Mon, 28 Jan 2002, Tom Rini wrote:
>> > On Mon, Jan 28, 2002 at 10:16:28AM +0200, Momchil Velikov wrote:
>> > > >>>>> "Kaoru" == Kaoru Fukui <k_fukui@highway.ne.jp> writes:
>> > >
>> > > Kaoru> On 27 Jan, Troy Benjegerdes wrote:
>> > > >> Did you actually try compiling PPC this way??
>> > > >>
>> > > >> vsprintf.o(.text+0x494): undefined reference to `__umoddi3'
>> > > >> vsprintf.o(.text+0x494): relocation truncated to fit: R_PPC_REL24
>> > > >> __umoddi3
>> > > >> vsprintf.o(.text+0x4ac): undefined reference to `__udivdi3'
>> > > >> vsprintf.o(.text+0x4ac): relocation truncated to fit: R_PPC_REL24
>> > > >> __udivdi3
>> > >
>> > > Kaoru> libgcc.a has those libraries.
>> > >
>> > > Yeah, but we don't link with libgcc.a. (which I forgot).
>> >
>> > Er, but isn't it (sort-of) considered a bug if the kernel links with
>> > libgcc.a ?  I think the consensious on l-k would be yes.
>>
>> So you copy the code from the libgcc sources, cfr. arch/m68k/lib/.
>
> Or optimize that, yes.  But linking directly is a no-no. :)

Yes,it's should has the source in the kernel.

However,the other archies(arm,cris,sh) use libgcc.a with static
link.
Those makefiles have
LIBGCC  := $(shell $(CC) $(CFLAGS) --print-libgcc-file-name)

If it's static link, it is same result isn't it?

Kaoru


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Broken asm/div64.h macro

[Troy Benjegerdes]

> >> So you copy the code from the libgcc sources, cfr. arch/m68k/lib/.
> >
> > Or optimize that, yes.  But linking directly is a no-no. :)
>
> Yes,it's should has the source in the kernel.
>
> However,the other archies(arm,cris,sh) use libgcc.a with static
> link.
> Those makefiles have
> LIBGCC  := $(shell $(CC) $(CFLAGS) --print-libgcc-file-name)
>
> If it's static link, it is same result isn't it?


libgcc is a no-no.. it's big, and also encourages users to do silly
things like long long divides and multiples in kernel fast-paths.

I posted a patch to linux-kernel (subject was 64 bit divides, or
something), regarding a cleanup for the whole asm/div64.h macro mess.

--
Troy Benjegerdes | master of mispeeling | 'da hozer' |  hozer@drgw.net
-----"If this message isn't misspelled, I didn't write it" -- Me -----
"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't. That's
why I draw cartoons. It's my life." -- Charles Schulz

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Broken asm/div64.h macro

[Tom Rini]

On Tue, Jan 29, 2002 at 02:05:28PM +0900, Kaoru Fukui wrote:
> On 28 Jan, Tom Rini wrote:
> > On Mon, Jan 28, 2002 at 08:45:31PM +0100, Geert Uytterhoeven wrote:
> >> On Mon, 28 Jan 2002, Tom Rini wrote:
> >> > On Mon, Jan 28, 2002 at 10:16:28AM +0200, Momchil Velikov wrote:
> >> > > >>>>> "Kaoru" == Kaoru Fukui <k_fukui@highway.ne.jp> writes:
> >> > >
> >> > > Kaoru> On 27 Jan, Troy Benjegerdes wrote:
> >> > > >> Did you actually try compiling PPC this way??
> >> > > >>
> >> > > >> vsprintf.o(.text+0x494): undefined reference to `__umoddi3'
> >> > > >> vsprintf.o(.text+0x494): relocation truncated to fit: R_PPC_REL24
> >> > > >> __umoddi3
> >> > > >> vsprintf.o(.text+0x4ac): undefined reference to `__udivdi3'
> >> > > >> vsprintf.o(.text+0x4ac): relocation truncated to fit: R_PPC_REL24
> >> > > >> __udivdi3
> >> > >
> >> > > Kaoru> libgcc.a has those libraries.
> >> > >
> >> > > Yeah, but we don't link with libgcc.a. (which I forgot).
> >> >
> >> > Er, but isn't it (sort-of) considered a bug if the kernel links with
> >> > libgcc.a ?  I think the consensious on l-k would be yes.
> >>
> >> So you copy the code from the libgcc sources, cfr. arch/m68k/lib/.
> >
> > Or optimize that, yes.  But linking directly is a no-no. :)
>
> Yes,it's should has the source in the kernel.
>
> However,the other archies(arm,cris,sh) use libgcc.a with static
> link.
> Those makefiles have
> LIBGCC  := $(shell $(CC) $(CFLAGS) --print-libgcc-file-name)

ARM doesn't do this anymore, since it required having the correct target
libgcc around.  SH is planning on moving away from this in 2.5.x from
what I understand.

> If it's static link, it is same result isn't it?

Sort of.  It depends on a certain libgcc, which is bad.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/