#33 changes to the PIC16 library


Santa Claus had two presents for PIC16:

(a) include/stdarg.h
PIC16's stack grows downwards, so the standard
macros fail,
new macros added for #if defined (SDCC_pic16)

(b) include/stdbool.h
bits are not yet too well supported so #define BOOL
#if defined (SDCC_pic16)

(c) lib/sincos.f
redundant y = fabsf(x); removed

(d) lib/pic16/libsdcc/float/fs2ulong.c
exp >>= -exp fails for exp>0 (shows strange
behaviour shifting arbitrary many times (exp & 0x1F) as
well as for exp<-32 (again due to modulo 32 arithmetics)
fixed in "our" version only (as it consts
additional cycles for the range checking and seems to
work for other ports...)
e.g. (long)sinf(180*(PI/180.0)) resulted in -345
instead of 0

Raphael Neider


  • Raphael Neider

    Raphael Neider - 2004-12-26

    patches to the library

  • Vangelis Rokas

    Vangelis Rokas - 2004-12-28
    • assigned_to: nobody --> vrokas
  • Vangelis Rokas

    Vangelis Rokas - 2004-12-28

    Logged In: YES

    All necessery pic16 include files are placed in
    sdcc/device/include/pic16 .
    You'll find stdarg.h there. Stdbool.h isn't added yet.

    PIC16 port redirects the include file search path to
    search at {install directory}/sdcc/include/pic16 and
    not the standard ./sdcc/include directory.
    The same happens for the library directories.

    (d) shall we fix the shifting rountine?(!)

  • Raphael Neider

    Raphael Neider - 2004-12-29

    Logged In: YES

    Concerning the include paths: you are of course right, it's
    just me having messed up my include paths... (I knew varargs
    worked at some stage...)

    (d) I agree, fixing the shift routine would be the best way.
    But (in my opinion) it incurs quite a large overhead in code
    size as well as in execution time (each shift would be there
    effectively twice for left and right shifting plus the check
    on the sign of the right operand).

    I thought of putting it into a support function which would
    produce additional moves (argument passing, write-back to

    Right now I am rather unhappy with both alternatives. I
    think I'll try out both in a week or so and publish my

    Raphael Neider

  • Raphael Neider

    Raphael Neider - 2005-01-04
    • status: open --> closed
  • Raphael Neider

    Raphael Neider - 2005-01-04

    Logged In: YES

    Implemented genericShift supporting shifting by negative
    (variable) values for left and right shifts in #920.

    This only blows up code size for "a >>= b;" for *signed* b,
    literals are not affected (shifting by negative literals is
    prevented by the frontend turning "a >> -4" into "0"),
    runtime is only minimally affected (one or two cycles).



Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks