#206 Put some declarations in one of SDCC header

open
nobody
None
5
2007-05-10
2007-05-10
Patryk
No

I found two such declarations usable, but there may be more I don't know of:
unsigned char _sdcc_external_startup(void);
extern __idata TByte _start__stack[];

First only as a sanity check for definition (during compilation of a library or an user module). Second allows it's use in C (to fill stack with some value or for runtime sanity check).

BTW: is there a way to access some assembler/linker symbols in C other than inline assembler? For example s_SSEG (__start__stack equivalent?), l_SSEG, s_CSEG, l_CSEG etc. There are many uses for them.

About using that symbols in inline assembler:
MOV (s_SSEG+0x38), #0xA5 ; works
MOV (s_SSEG+l_SSEG), #0xA5 ; but this not (causes ?ASxxxx-Error-<r> relocation error)
(I'm aware that I should use indirect addressing here, but this way example is simple)
Is below the only way to do this:
MOV A, #s_SSEG
ADD A, #l_SSEG
MOV R0, A
MOV @R0, #0xA5

Discussion

  • Logged In: YES
    user_id=589052
    Originator: NO

    It might be attractive to change:

    unsigned char _sdcc_external_startup(void);

    for the mcs51 into:

    __bit _sdcc_external_startup(void);

    in later versions of SDCC. So, yes, the declaration
    might need attention.

     
  • Patryk
    Patryk
    2007-05-10

    Logged In: YES
    user_id=1788180
    Originator: YES

    Wouldn't
    BOOL _sdcc_external_startup(void);
    be better? Probably for all ports, not only mcs51.

     
  • Logged In: YES
    user_id=589052
    Originator: NO

    BOOL looks more clean but I believe it is not.

    Using BOOL would pretend a flexibility that is not there.
    The assembler code in crtstart.asm would have to either
    check for the carry bit or check DPL.
    It would do so without looking at (or wanting to look at)
    whether BOOL in stdbool.h might be __bit or char.

    So I'd prefer to say "__bit" if one day a switch to a bit
    returning function (saving ~4 byte for each program
    compiled for mcs51) is done.

     
  • Patryk
    Patryk
    2007-05-11

    Logged In: YES
    user_id=1788180
    Originator: YES

    I was about to protest (not all platforms support bit instructions), but probably all possible platforms got carry bit and many means to handle it :-) So __bit should be OK, at least for return boolean value from function.
    But isn't __bit type available only for mcs51? crtstart.asm is platform specific, and BOOL is defined as __bit for mcs51 (so no mess in crtstart.asm), so maybe still BOOL is better, leaving _sdcc_external_startup() declaration same for all platforms?

     
  • Maarten Brock
    Maarten Brock
    2007-11-14

    Logged In: YES
    user_id=888171
    Originator: NO

    Patryk,

    Could it be that MOV (s_SSEG+l_SSEG),#0xA5 does not work because the address is above 0x80? Have you tried this:
    MOV R0,#(s_SSEG+l_SSEG)
    MOV @R0,#0xA5
    Or does the assembler bail out because it won't add two symbols at all? (And thus the above fails too)

    To access these symbols from C they need to be renamed to something starting with an underscore. And to comply with the C standard only symbols starting in C with double underscore are reserved for compiler specific symbols. This would give them 3 underscores in assembler. Then a header with their declaration could also be created.

    Regarding _sdcc_external_startup I would also vote for BOOL when changing its behaviour. BOOL does not change with different compiler options except the target architecture. But actually this is a totally different RFE and only the request to also specify it in a header is relevant here.

    Any bright ideas for which current header file or a name for a new one?

    Maarten

     
  • Patryk
    Patryk
    2007-11-15

    Logged In: YES
    user_id=1788180
    Originator: YES

    Maarten,

    MOV R0,#(s_SSEG+l_SSEG) causes same error: assembler can't add two symbols, or more precisely probably has no way to pass such operation to linker.

    Assembler symbols: so problem lies only in name? If s_DSEG would be named ___s_DSEG, would it be accessible in C as "extern char __s_DSEG[];"? (BTW: _sdcc_external_startup() should be renamed to ___sdcc_external_startup()/__sdcc_external_startup()?)
    That is a way to access addresses in C. But how to access constants like l_DSEG?
    "const unsigned char size = l_DSEG;" seems not to be the correct way: compiler would rather take value stored in RAM at address equal to l_DSEG value.
    "const unsigned char size = (unsigned char)(&l_DSEG);" is correct? Not so convenient nor readable way, but I see no other - do I miss something?

    I missed that stdbool.h has changed between SDCC 2.7.2 #4871 and #4885. By the way: SDCC build number next to dates in change log (https://sdcc.svn.sourceforge.net/svnroot/sdcc/trunk/sdcc/ChangeLog)
    would be much appreciated!

    As of header name: it is target specific, so maybe compiler.h? Other targets don't have compiler.h yet. Or maybe one file (asm_symbols.h or lkr_symbols.h) with sections for different targets?
    BTW: what 80c51xa.h (and ds80c390.h and others) does in "include" directory? Shouldn't it be placed in "include\mcs51"? z180.h to "include\z80".

    Patryk

     
  • Patryk
    Patryk
    2008-04-01

    Logged In: YES
    user_id=1788180
    Originator: YES

    I think I found suitable header:
    SDCC\include\sdcc-lib.h

    Will someone (Maarten?) say something about assembler symbols names and accessing them from C (questions in my last post)?

     
  • Patryk
    Patryk
    2008-04-01

    Logged In: YES
    user_id=1788180
    Originator: YES

    I think I found suitable header:
    SDCC\include\sdcc-lib.h

    Will someone (Maarten?) say something about assembler symbols names and accessing them from C (questions in my last post)?

     
  • Patryk
    Patryk
    2008-04-01

    Logged In: YES
    user_id=1788180
    Originator: YES

    Sorry for double post: it must be caused by navigating back in browser (IE 6.0).