(sdcc new c lib) 64-bit integer type now supported

New features and project activity between releases
Post Reply
alvin
Well known member
Posts: 1872
Joined: Mon Jul 16, 2007 7:39 pm

(sdcc new c lib) 64-bit integer type now supported

Post by alvin »

Additions have been made to the library to support sdcc's 64-bit integer type (long long / uint64_t) starting with the May 11 nightly build.

The type can be added, subtracted, multiplied, divided, shifted and passed by value as parameter to functions.
Conversions between float and longlong is supported.

* inttypes.h

For sdcc compiles the maximum size integer type has been changed to longlong from long.

* limits.h

For sdcc compiles integer limits for longlong have been defined.

* stdint.h

For sdcc compiles all 64-bit integer types have been defined per the standard (eg int64_t, uint64_t)

* string.h

int ffsll(longlong)

* stdlib.h

types lldiv_t and lldivu_t defined
long long atoll(char *buf)
_lldiv_(lldiv_t *ld, long long numer, long long denom)
_lldivu_(lldivu_t, unsigned long long numer, unsigned long long denom)
long long llabs(long long)
char *lltoa(long long num, char *buf, int radix)
strtoll(char *nptr, char **endptr, int base)
strtoull(char *nptr, char **endptr, int base)
char *ulltoa(unsigned long long num, char *buf, int radix)

* stdio.h

printf converters %lld, %llu, %llx, %llX, %llo, %lli added
scanf converters %lld, %llu, %llx, %llX, %llo, %lli added


All functions are written in assembly language. The 64-bit math functions are not yet optimized for the fast integer math library but there will be some speed improvement over the small integer math library nevertheless.


Known Issues:

* strtoll, strtoull (and therefore scanf) cannot reliably detect overflow when converting from string to 64-bit integer.

* sdcc is currently generating voluminous code when using 64-bit ints so try to keep their use to a minimum.

* sdcc has a bug that will occur in most programs containing 64-bit code ( https://sourceforge.net/p/sdcc/discussi ... it=25#9c04 ). This bug occurs when the compiler attempts to reuse a 64-bit value in a following statement but cannot because 64-bit values cannot be held in registers. The problem is easy to circumvent by inserting a do-nothing function call between statements.

Eg:

Code: Select all

      z.a = d;
      // in_pause(10);
      lltoa(z.a, buffer_0, 10);
results in a fatal error:

error.c:24: error 9: FATAL Compiler Internal Error in file '/home/sdcc-builder/build/sdcc-build/orig/sdcc/src/z80/gen.c' line number '1579' : Symbol in register, but no register assigned.
Contact Author with source code
Symbol iTemp10 at ic 14.

caused by the compiler's attempted reuse of z.a in the second statement above. Inserting a function call between the two statements circumvents the problem.

This is a serious bug so hopefully it will be fixed in sdcc soon.



By default the library configuration for targets has the %ll specifiers for printf and scanf disabled. To printf and scanf 64-bit long longs, they must be enabled in the target's config file and the library rebuilt. This is the same situation as for floats and is done to ensure longlong code is absent from typical compiles.

It is a simple matter to rebuild the library under any OS so if you are not sure how to do this just ask in the forum.
alvin
Well known member
Posts: 1872
Joined: Mon Jul 16, 2007 7:39 pm

Post by alvin »

correct link to sdcc bug report:
https://sourceforge.net/p/sdcc/bugs/2501/
alvin
Well known member
Posts: 1872
Joined: Mon Jul 16, 2007 7:39 pm

Post by alvin »

strtoll and strtotull overflow detection issue resolved in May 12 build
alvin
Well known member
Posts: 1872
Joined: Mon Jul 16, 2007 7:39 pm

Post by alvin »

May 13 build:

* 64-bit division by zero now returning correct value for remainder (the original dividend). Register transposition was scrambling the returned value.

* In intrinsics.h, intrinsic_stub() introduced as a do-nothing function call that is later removed by the backend, leaving no call in the actual output code. This was added to act as a dummy function call to temporarily resolve the issue noted above.

I think with that we've inched across the finish line for 64-bit integration. We may yet look at speeding up the 64-bit integer math for the fast version of the integer library but it may be more compelling to keep the code size small since loop unrolling may be expensive. There is also some possible progress toward reducing the code size of generated 64-bit programs so that will be investigated over the next several days.
Post Reply