[sdcc-devel] [ sdcc-Feature Requests-1593259 ] cheaper return types for some library functions

[SourceForge.net <no...@so...>]

Feature Requests item #1593259, was opened at 2006-11-09 10:45
Message generated for change (Comment added) made by spth
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1593259&group_id=599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Frieder Ferlemann (frief)
Assigned to: Nobody/Anonymous (nobody)
Summary: cheaper return types for some library functions

Initial Comment:
some functions of SDCC's library could probably
use a smaller return type:

Functions iscntrl() isdigit() isgraph() islower() isprint()
ispunct() isspace() isupper() isxdigit() could probably
return
bit (on mcs51) instead of char without causing problems.

Also _sdcc_external_startup() could return bit instead of
unsigned char. If this is changed it might make sense to
bumb the version number as some user code will require
adapting.

memcmp() strcmp() strncmp() could probably return
char instead of int without causing problems.


----------------------------------------------------------------------

>Comment By: Philipp Krause (spth)
Date: 2010-01-17 16:17

Message:
Using a smaller return type than what the standard mandates could cause
ansty surprises when calling these functions via function pointers.

Philipp


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2007-03-26 21:59

Message:
Logged In: NO 

#ifdef BITBOOL
// :-)
#endif

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2007-03-21 15:24

Message:
Logged In: NO 


I would also favor the macro-based approach, where we can simply configure
our requirements at compile time, however when we actually do use
custom/reduced return types, there should probably be an obligatory
warning, informing the user that the function's return type may no longer
be ANSI-C conforming, which might become a factor when interfacing with
standard's compliant code.
This could be easily achieved by using a #warning directive in the
corresponding macro definitions which references a detailed description
about how to enable/disable this.

likewise, it might be a good idea to also consider the same case in a
backwards scenario, i.e. where a user is asking for highly optimized
assembly output, while possibly using unnessesarily expensive return types
from the library, in such cases there might also be a short info that
cheaper return types may be available, if the user is willing to sacrifice
ANSI compliance

----------------------------------------------------------------------

Comment By: Frieder Ferlemann (frief)
Date: 2006-11-10 14:34

Message:
Logged In: YES 
user_id=589052

> But you can start being surprised right now ...

I'am!)


> Are you sure SDCC sums (bit)1 + (bit)1 to (bit)0 ? 
> That's not what I would expect.

Seems so:

#include <stdbool.h>
#include <stdio.h>

volatile bool a=1;
volatile bool b=1;
volatile bool c;

bit f (void)
{
 c = a + b;
 return c;
}

gives:

_f:
;       bit2.c:10: c = a + b;
;       genPlus
;       genPlusBits
        mov     c,_b
        jnb     _a,00103$
        cpl     c
00103$:
        mov     _c,c
;       bit2.c:11: return c;
;       genRet
        clr     a
        mov     c,_c
        rlc     a
        add     a,#0xff
        ret

whereas this is generated with the '|':

;       bit2.c:10: c = a | b;
;       genOr
        mov     c,_a
        orl     c,_b
        mov     _c,c

the || operator generates ineffective code 
including jumps and an sloc.


----------------------------------------------------------------------

Comment By: Maarten Brock (maartenbrock)
Date: 2006-11-10 14:06

Message:
Logged In: YES 
user_id=888171

I don't mind giving up ANSI compliance in these cases as all results can
be automatically upcasted 
when used.

But you can start being surprised right now because I'm sure IAR does not
give up compliance and they 
probably generate more compact code than SDCC can.

Are you sure SDCC sums (bit)1 + (bit)1 to (bit)0 ? That's not what I would
expect.

Maarten

----------------------------------------------------------------------

Comment By: Frieder Ferlemann (frief)
Date: 2006-11-10 11:25

Message:
Logged In: YES 
user_id=589052

> These changes would probably be incompatible with ANSI C.

Yes. My attitude towards that is somewhat mixed, as 
we have mutually rationales there: small code, ANSI 
compatibility and to a lesser extend compatibility 
towards other 8-bit compilers.

Our library is (I think with good reason) not 
ANSI with respekt to f.e. int getchar(void) and 
int putchar(int c).
I would be surprised to learn if other mcs51 
compilers used 16 bit variables there.

I also see that with our current implementation
of bitwise additions (1+1=0) (gcc: 1+1=1) we'd 
run into problems with expressions like
isprint('A') + isupper('A') being evaluated to 
false.
This should probably be changed to the behaviour
of GCC!?

A sidelook to other 8-bit compilers would 
probably tell us that function return
the smallest type that can fit the range
of results. I think we should follow that
path.

(Duck and cover, Frieder)

----------------------------------------------------------------------

Comment By: Raphael Neider (tecodev)
Date: 2006-11-09 12:22

Message:
Logged In: YES 
user_id=1115835

These changes would probably be incompatible with ANSI C.
Some defines a la

#define ANSI_C_COMPLIANT 1 // enabled by default
#if defined(ANSI_C_COMPLIANT) && ANSI_C_COMPLIANT > 0
  #define BOOL_RET_T char
  #define CMP_T int
#else
  #define BOOL_RET_T bit
  #define CMP_T char
#endif

BOOL_RET_T iscntl(...);
CMP_T strcmp(...);

might help, but introduce more options for the user to
choose from---and more options to raise incompatibilities
among compiled library versions...

Regards,
Raphael


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1593259&group_id=599