/ and %: Dangerous in a portable kernel?

[Colonel Kernel]

There is some code in my kernel that uses the % and / C operators on integer types (uint64_t, with some integer literals). I realize that on x86 this likely gets compiled to non-FP instructions and is therefore ok... My concern is for other processor architectures where there may not be integer divide and modulus instructions (there are some RISC architectures with this trait... I don't remember which ones offhand).

Basically, I'm trying to avoid any use of FP code in the kernel. Does anyone see a potential problem with % and / in this regard? BTW, the code in question is my kernel's equivalent to atoi()...

[Colonel Kernel]

Aha! The linker has answered my question for me:

Code: Select all

../../Lib/libKLib.a(TextWriter.o)(.text+0x107): In function `TextWriter_writeDecimal':
: undefined reference to `__udivdi3'
../../Lib/libKLib.a(TextWriter.o)(.text+0x15b): In function `TextWriter_writeDecimal':
: undefined reference to `__umoddi3'
../../Lib/libKLib.a(TextWriter.o)(.text+0x188): In function `TextWriter_writeDecimal':
: undefined reference to `__udivdi3'
collect2: ld returned 1 exit status

I guess I'll have to whip up some asm magic to make this work. Anybody else have this problem and some cleaner solutions to it?

[Gnome]

GCC implements 64-bit arithmetic on 32-bit architectures (via the long long type or a typedef thereof) with the helper functions the linker is complaining it can't find.

So, you either need to link in libgcc, or implement these yourself. Reimplementing these shouldn't be too hard. You could even look at a disassembly of libgcc.

[Colonel Kernel]

I ended up solving my immediate problem by replacing writeInt64() with writeIntPtr()... in other words, no outputting 64-bit ints on 32-bit machines. I don't think this is a big deal, since the kernel will be outputting mostly machine-specific registers and pointers anyway, for diagnostic purposes.

Anyway, the bigger question still remains -- will the use of integer / and % get me into trouble on other processor architectures...? I guess the short answer is that if it will, GCC will probably be using some builtins to implement these operators and the linker will kindly let me know. Nevertheless, if anyone has any experience porting this kind of code to a non-x86 machine, I'd like to hear about your experiences...

[Gnome]

Only for types that the processor cannot handle natively and thus require helper functions. You can always provide these functions if required.

In general, no.