From: SourceForge.net <no...@so...> - 2007-05-10 11:32:29
|
Feature Requests item #1716427, was opened at 2007-05-10 13:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1716427&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: Patryk (patryks) Assigned to: Nobody/Anonymous (nobody) Summary: Put some declarations in one of SDCC header Initial Comment: 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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1716427&group_id=599 |
From: SourceForge.net <no...@so...> - 2007-05-10 11:54:16
|
Feature Requests item #1716427, was opened at 2007-05-10 13:32 Message generated for change (Comment added) made by frief You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1716427&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: Patryk (patryks) Assigned to: Nobody/Anonymous (nobody) Summary: Put some declarations in one of SDCC header Initial Comment: 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 ---------------------------------------------------------------------- >Comment By: Frieder Ferlemann (frief) Date: 2007-05-10 13:54 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1716427&group_id=599 |
From: SourceForge.net <no...@so...> - 2007-05-10 12:13:23
|
Feature Requests item #1716427, was opened at 2007-05-10 13:32 Message generated for change (Comment added) made by patryks You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1716427&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: Patryk (patryks) Assigned to: Nobody/Anonymous (nobody) Summary: Put some declarations in one of SDCC header Initial Comment: 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 ---------------------------------------------------------------------- >Comment By: Patryk (patryks) Date: 2007-05-10 14:13 Message: Logged In: YES user_id=1788180 Originator: YES Wouldn't BOOL _sdcc_external_startup(void); be better? Probably for all ports, not only mcs51. ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2007-05-10 13:54 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1716427&group_id=599 |
From: SourceForge.net <no...@so...> - 2007-05-10 14:35:32
|
Feature Requests item #1716427, was opened at 2007-05-10 13:32 Message generated for change (Comment added) made by frief You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1716427&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: Patryk (patryks) Assigned to: Nobody/Anonymous (nobody) Summary: Put some declarations in one of SDCC header Initial Comment: 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 ---------------------------------------------------------------------- >Comment By: Frieder Ferlemann (frief) Date: 2007-05-10 16:35 Message: 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. ---------------------------------------------------------------------- Comment By: Patryk (patryks) Date: 2007-05-10 14:13 Message: Logged In: YES user_id=1788180 Originator: YES Wouldn't BOOL _sdcc_external_startup(void); be better? Probably for all ports, not only mcs51. ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2007-05-10 13:54 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1716427&group_id=599 |
From: SourceForge.net <no...@so...> - 2007-05-11 09:39:33
|
Feature Requests item #1716427, was opened at 2007-05-10 13:32 Message generated for change (Comment added) made by patryks You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1716427&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: Patryk (patryks) Assigned to: Nobody/Anonymous (nobody) Summary: Put some declarations in one of SDCC header Initial Comment: 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 ---------------------------------------------------------------------- >Comment By: Patryk (patryks) Date: 2007-05-11 11:39 Message: 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? ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2007-05-10 16:35 Message: 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. ---------------------------------------------------------------------- Comment By: Patryk (patryks) Date: 2007-05-10 14:13 Message: Logged In: YES user_id=1788180 Originator: YES Wouldn't BOOL _sdcc_external_startup(void); be better? Probably for all ports, not only mcs51. ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2007-05-10 13:54 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1716427&group_id=599 |
From: SourceForge.net <no...@so...> - 2007-11-14 20:49:45
|
Feature Requests item #1716427, was opened at 2007-05-10 13:32 Message generated for change (Comment added) made by maartenbrock You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1716427&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: Patryk (patryks) Assigned to: Nobody/Anonymous (nobody) Summary: Put some declarations in one of SDCC header Initial Comment: 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 ---------------------------------------------------------------------- >Comment By: Maarten Brock (maartenbrock) Date: 2007-11-14 21:49 Message: 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 ---------------------------------------------------------------------- Comment By: Patryk (patryks) Date: 2007-05-11 11:39 Message: 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? ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2007-05-10 16:35 Message: 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. ---------------------------------------------------------------------- Comment By: Patryk (patryks) Date: 2007-05-10 14:13 Message: Logged In: YES user_id=1788180 Originator: YES Wouldn't BOOL _sdcc_external_startup(void); be better? Probably for all ports, not only mcs51. ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2007-05-10 13:54 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1716427&group_id=599 |
From: SourceForge.net <no...@so...> - 2007-11-15 09:45:36
|
Feature Requests item #1716427, was opened at 2007-05-10 13:32 Message generated for change (Comment added) made by patryks You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1716427&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: Patryk (patryks) Assigned to: Nobody/Anonymous (nobody) Summary: Put some declarations in one of SDCC header Initial Comment: 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 ---------------------------------------------------------------------- >Comment By: Patryk (patryks) Date: 2007-11-15 10:45 Message: 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 ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2007-11-14 21:49 Message: 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 ---------------------------------------------------------------------- Comment By: Patryk (patryks) Date: 2007-05-11 11:39 Message: 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? ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2007-05-10 16:35 Message: 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. ---------------------------------------------------------------------- Comment By: Patryk (patryks) Date: 2007-05-10 14:13 Message: Logged In: YES user_id=1788180 Originator: YES Wouldn't BOOL _sdcc_external_startup(void); be better? Probably for all ports, not only mcs51. ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2007-05-10 13:54 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1716427&group_id=599 |
From: SourceForge.net <no...@so...> - 2008-04-01 07:20:33
|
Feature Requests item #1716427, was opened at 2007-05-10 13:32 Message generated for change (Comment added) made by patryks You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1716427&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: Patryk (patryks) Assigned to: Nobody/Anonymous (nobody) Summary: Put some declarations in one of SDCC header Initial Comment: 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 ---------------------------------------------------------------------- >Comment By: Patryk (patryks) Date: 2008-04-01 09:20 Message: 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)? ---------------------------------------------------------------------- Comment By: Patryk (patryks) Date: 2007-11-15 10:45 Message: 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 ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2007-11-14 21:49 Message: 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 ---------------------------------------------------------------------- Comment By: Patryk (patryks) Date: 2007-05-11 11:39 Message: 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? ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2007-05-10 16:35 Message: 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. ---------------------------------------------------------------------- Comment By: Patryk (patryks) Date: 2007-05-10 14:13 Message: Logged In: YES user_id=1788180 Originator: YES Wouldn't BOOL _sdcc_external_startup(void); be better? Probably for all ports, not only mcs51. ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2007-05-10 13:54 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1716427&group_id=599 |
From: SourceForge.net <no...@so...> - 2008-04-01 07:21:59
|
Feature Requests item #1716427, was opened at 2007-05-10 13:32 Message generated for change (Comment added) made by patryks You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1716427&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: Patryk (patryks) Assigned to: Nobody/Anonymous (nobody) Summary: Put some declarations in one of SDCC header Initial Comment: 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 ---------------------------------------------------------------------- >Comment By: Patryk (patryks) Date: 2008-04-01 09:21 Message: 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)? ---------------------------------------------------------------------- Comment By: Patryk (patryks) Date: 2008-04-01 09:20 Message: 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)? ---------------------------------------------------------------------- Comment By: Patryk (patryks) Date: 2007-11-15 10:45 Message: 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 ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2007-11-14 21:49 Message: 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 ---------------------------------------------------------------------- Comment By: Patryk (patryks) Date: 2007-05-11 11:39 Message: 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? ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2007-05-10 16:35 Message: 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. ---------------------------------------------------------------------- Comment By: Patryk (patryks) Date: 2007-05-10 14:13 Message: Logged In: YES user_id=1788180 Originator: YES Wouldn't BOOL _sdcc_external_startup(void); be better? Probably for all ports, not only mcs51. ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2007-05-10 13:54 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1716427&group_id=599 |
From: SourceForge.net <no...@so...> - 2008-04-01 07:48:26
|
Feature Requests item #1716427, was opened at 2007-05-10 13:32 Message generated for change (Comment added) made by patryks You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1716427&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: Patryk (patryks) Assigned to: Nobody/Anonymous (nobody) Summary: Put some declarations in one of SDCC header Initial Comment: 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 ---------------------------------------------------------------------- >Comment By: Patryk (patryks) Date: 2008-04-01 09:48 Message: Logged In: YES user_id=1788180 Originator: YES Sorry for double post: it must be caused by navigating back in browser (IE 6.0). ---------------------------------------------------------------------- Comment By: Patryk (patryks) Date: 2008-04-01 09:21 Message: 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)? ---------------------------------------------------------------------- Comment By: Patryk (patryks) Date: 2008-04-01 09:20 Message: 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)? ---------------------------------------------------------------------- Comment By: Patryk (patryks) Date: 2007-11-15 10:45 Message: 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 ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2007-11-14 21:49 Message: 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 ---------------------------------------------------------------------- Comment By: Patryk (patryks) Date: 2007-05-11 11:39 Message: 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? ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2007-05-10 16:35 Message: 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. ---------------------------------------------------------------------- Comment By: Patryk (patryks) Date: 2007-05-10 14:13 Message: Logged In: YES user_id=1788180 Originator: YES Wouldn't BOOL _sdcc_external_startup(void); be better? Probably for all ports, not only mcs51. ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2007-05-10 13:54 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1716427&group_id=599 |