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);
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.