"long long" division

[NOTNULL]

Hi all,

When I try to divide a "long long" variable by some number, I get the linker error "undefined reference to ___divdi3". So, I understand that the division has to be carried out by 4 bytes at a time. Is there any optimized way of implementing the above opearation?

Thanks in advance.

[Solar]

Huh?

No, you shouldn't have to do anything special to do long long divisions.

One, check that your compiler is running in C99 mode. For GCC, the option is [tt]-std=c99[/tt].

Two, make sure your compiler doesn't use any builtins ([tt]-nostdlib -nodefaultlibs[/tt], possibly [tt]-fno-builtin[/tt]).

[hendric]

Yea as What Solar said,gcc has provided a pretty good built-in support for long long variables.

[NOTNULL]

Thanks Solar.

I use DJGPP, gcc version 4.0.0. Also, all builtins have been suppressed. I tried to use the option -std=c99. But, still, it gives the same error mesage.

[paulbarker]

Perhaps the error is because builtins have been disabled. If GCC has such great builtin support for long longs, what happens when you disable builtins?? I'm thinking its a builtin that usually handles these kinds of things.

All I can suggest is google, or grep thrugh the gcc & glibc sources. Have fun!

[Solar]

Uh? I'm surprised to see that DJGPP seems to be not half as outdated a GCC version than I thought.

Anyway... it would take some testing Re GCC long long support, and I don't have a GCC at hand ATM. I'd be interested in any findings, though (so that I can rub them into the FAQ).

[paulbarker]

I've just found the OpenBSD version of this function, and its under a modified BSD license (ie. no advertising clause).

I could email it you or you could try and find it. Its in 'src/sys/lib/libkern' in the CVS repository, which you can get by anonymous cvs or webcvs. Its named 'divdi3.c'. Theres also files for add, and, left & right shift, etc. Theres quite a few actually.

[Pype.Clicker]

iirc, functions for long long division require some library code (that should be in the "language support library" libgcc.a or something. Asking "no builtin" just prevented the linker to use that library when generating your file. IIrc too, that specific library should be safe for inclusion even in a kernel, and you could still have the benefits of "avoid anything that is host-related" through "-ffreestanding", yet i have to toy with that in real programming condition before i could validate the stuff.

[paulbarker]

I've had this discussion before, and '-ffreestanding -fbuiltin' should be safe for use. I'm using them and havent had any problems yet.

[NOTNULL]

I've had this discussion before, and '-ffreestanding -fbuiltin' should be safe for use. I'm using them and havent had any problems yet.

Hey, I tried using '-ffreestanding -fbuiltin'. It's not working. When I removed all the flags and compiled my kernel, still it throws the error, while linking. Does gcc have support for "long long" division? ???

[paulbarker]

Does gcc have support for "long long" division?

Of course it does, you might need to provide the library functions though. See my earlier post.

[Solar]

Does this help in any way?

http://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/Long-Long.html

[Colonel Kernel]

I've had this discussion before, and '-ffreestanding -fbuiltin' should be safe for use. I'm using them and havent had any problems yet.

Hmmm... does that work for memcpy() as well? I'm not that interesting in trying to write my own optimized version...

@Solar: What problems do you forsee with using builtins in a kernel? Are they licensing or technical concerns that you have?

[Pype.Clicker]

afaik (in gcc3.x), the language support library (that is, libgcc.a, which you can find in /usr/lib/gcc/<version>/, but also libsupc++ afaik.) is license-friendly, linking against it doesn't taint your program to the library's license in any way. This is actually mandatory since it is linked to _any_ program GCC generates (that would mean any commercial project couldn't use GCC -- and FSF isn't *that* nasty)

Note: not _all_ parts of libgcc.a are that osdevers-friendly. Among others, _eh.o do contain pthread_xxx calls, but as long as you don't use language's exceptions handlers, that specific part shouldn't be needed (that's the nice part of static libraries: you only get what you need, not the rest )

In your case, "_divdi3.o" offers __divdi3 and requires no other part of libgcc.a ... if it still doesn't work with "-ffreestanding", try to locate your compiler's libgcc.a and link explicitly against it. That should do the trick.

[Solar]

Colonel Kernel: I foresee nothing. I just mix a bag of "I think I have seen this somewhere" with a shot of xenophobia ("not invented here") and a bucket of paranoia.