From: SourceForge.net <no...@so...> - 2007-02-27 12:41:55
|
Feature Requests item #1493816, was opened at 2006-05-23 22:10 Message generated for change (Comment added) made by frief You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1493816&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: Closed Priority: 1 Private: No Submitted By: Frieder Ferlemann (frief) Assigned to: Nobody/Anonymous (nobody) Summary: option --no-gen-comments Initial Comment: (This is a very low priority request:) There is the high level option --no-c-code-in-asm and the low level option --no-peep-comments to suppress comments generated by SDCC, but there is no option to suppress the medium level comments like: 460 ; genCmpGt 461 ; genCmp 462 ; genIfxJump I occasionally find myself filtering out these comments "manually" using the command: grep -v "; gen" MY_FILE.ASM just to be able to read assembly files smoothly. Would be nice if the compiler could be directly told to ommit them. ---------------------------------------------------------------------- >Comment By: Frieder Ferlemann (frief) Date: 2007-02-27 13:41 Message: Logged In: YES user_id=589052 Originator: YES implemented (for mcs51, ds390) in SDCC #4658. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1493816&group_id=599 |
From: SourceForge.net <no...@so...> - 2007-02-28 06:36:53
|
Feature Requests item #1493816, was opened at 2006-05-23 22:10 Message generated for change (Comment added) made by borutr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1493816&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: 1 Private: No Submitted By: Frieder Ferlemann (frief) Assigned to: Nobody/Anonymous (nobody) Summary: option --no-gen-comments Initial Comment: (This is a very low priority request:) There is the high level option --no-c-code-in-asm and the low level option --no-peep-comments to suppress comments generated by SDCC, but there is no option to suppress the medium level comments like: 460 ; genCmpGt 461 ; genCmp 462 ; genIfxJump I occasionally find myself filtering out these comments "manually" using the command: grep -v "; gen" MY_FILE.ASM just to be able to read assembly files smoothly. Would be nice if the compiler could be directly told to ommit them. ---------------------------------------------------------------------- >Comment By: Borut Razem (borutr) Date: 2007-02-28 07:36 Message: Logged In: YES user_id=568035 Originator: NO I reopened the RFE because it is only partially fixed. NOTE: sdcc does not generate the code only for msc51 and ds390 targets. We should care for the compatibility between all targets as much as possible. Borut ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2007-02-27 13:41 Message: Logged In: YES user_id=589052 Originator: YES implemented (for mcs51, ds390) in SDCC #4658. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1493816&group_id=599 |
From: SourceForge.net <no...@so...> - 2007-02-28 09:24:14
|
Feature Requests item #1493816, was opened at 2006-05-23 22:10 Message generated for change (Comment added) made by frief You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1493816&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: 1 Private: No Submitted By: Frieder Ferlemann (frief) Assigned to: Nobody/Anonymous (nobody) Summary: option --no-gen-comments Initial Comment: (This is a very low priority request:) There is the high level option --no-c-code-in-asm and the low level option --no-peep-comments to suppress comments generated by SDCC, but there is no option to suppress the medium level comments like: 460 ; genCmpGt 461 ; genCmp 462 ; genIfxJump I occasionally find myself filtering out these comments "manually" using the command: grep -v "; gen" MY_FILE.ASM just to be able to read assembly files smoothly. Would be nice if the compiler could be directly told to ommit them. ---------------------------------------------------------------------- >Comment By: Frieder Ferlemann (frief) Date: 2007-02-28 10:24 Message: Logged In: YES user_id=589052 Originator: YES yes, I should not have closed the RFE. The pic and pic16 ports seemed to me to be using a different scheme (an "opt in" rather than an "opt out" option for debugging information). Option --debug-xtra would switch on extra information by setting port specific variables. (Nothing wrong with an opt in scheme, but it led me to the assumption the RFE would not apply to pic/pic16.) I implemented this RFE for the 'hc08 port. There is a macro DD() for even more detailed debug information within the 'hc08 port. Eventually make --debug-xtra a global option and couple with DD() ? (Note: the pic/pic16 option is documented as --debug-extra in the manual but the source uses the SMS'ed --debug-xtra) ---------------------------------------------------------------------- Comment By: Borut Razem (borutr) Date: 2007-02-28 07:36 Message: Logged In: YES user_id=568035 Originator: NO I reopened the RFE because it is only partially fixed. NOTE: sdcc does not generate the code only for msc51 and ds390 targets. We should care for the compatibility between all targets as much as possible. Borut ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2007-02-27 13:41 Message: Logged In: YES user_id=589052 Originator: YES implemented (for mcs51, ds390) in SDCC #4658. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1493816&group_id=599 |
From: SourceForge.net <no...@so...> - 2007-02-28 18:02:49
|
Feature Requests item #1493816, was opened at 2006-05-23 22:10 Message generated for change (Comment added) made by borutr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1493816&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: 1 Private: No Submitted By: Frieder Ferlemann (frief) Assigned to: Nobody/Anonymous (nobody) Summary: option --no-gen-comments Initial Comment: (This is a very low priority request:) There is the high level option --no-c-code-in-asm and the low level option --no-peep-comments to suppress comments generated by SDCC, but there is no option to suppress the medium level comments like: 460 ; genCmpGt 461 ; genCmp 462 ; genIfxJump I occasionally find myself filtering out these comments "manually" using the command: grep -v "; gen" MY_FILE.ASM just to be able to read assembly files smoothly. Would be nice if the compiler could be directly told to ommit them. ---------------------------------------------------------------------- >Comment By: Borut Razem (borutr) Date: 2007-02-28 19:02 Message: Logged In: YES user_id=568035 Originator: NO My opinion is to unify the command line options as much as possible. So we should: - keep the --debug-(e)xtra option for pic16 and invert and rename the --no-gen-comments option for other targets or - keep the --no-gen-comments option and invert and rename the --debug-(e)xtra option for pic16 target In case that we chose the --debug-xtra I prefer to add the missing 'e' (--debug-extra). What about other targets: gbz80/z80/avr/pic14/TININative/xa51? Borut ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2007-02-28 10:24 Message: Logged In: YES user_id=589052 Originator: YES yes, I should not have closed the RFE. The pic and pic16 ports seemed to me to be using a different scheme (an "opt in" rather than an "opt out" option for debugging information). Option --debug-xtra would switch on extra information by setting port specific variables. (Nothing wrong with an opt in scheme, but it led me to the assumption the RFE would not apply to pic/pic16.) I implemented this RFE for the 'hc08 port. There is a macro DD() for even more detailed debug information within the 'hc08 port. Eventually make --debug-xtra a global option and couple with DD() ? (Note: the pic/pic16 option is documented as --debug-extra in the manual but the source uses the SMS'ed --debug-xtra) ---------------------------------------------------------------------- Comment By: Borut Razem (borutr) Date: 2007-02-28 07:36 Message: Logged In: YES user_id=568035 Originator: NO I reopened the RFE because it is only partially fixed. NOTE: sdcc does not generate the code only for msc51 and ds390 targets. We should care for the compatibility between all targets as much as possible. Borut ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2007-02-27 13:41 Message: Logged In: YES user_id=589052 Originator: YES implemented (for mcs51, ds390) in SDCC #4658. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1493816&group_id=599 |
From: SourceForge.net <no...@so...> - 2007-03-01 07:48:26
|
Feature Requests item #1493816, was opened at 2006-05-23 22:10 Message generated for change (Comment added) made by maartenbrock You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1493816&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: 1 Private: No Submitted By: Frieder Ferlemann (frief) Assigned to: Nobody/Anonymous (nobody) Summary: option --no-gen-comments Initial Comment: (This is a very low priority request:) There is the high level option --no-c-code-in-asm and the low level option --no-peep-comments to suppress comments generated by SDCC, but there is no option to suppress the medium level comments like: 460 ; genCmpGt 461 ; genCmp 462 ; genIfxJump I occasionally find myself filtering out these comments "manually" using the command: grep -v "; gen" MY_FILE.ASM just to be able to read assembly files smoothly. Would be nice if the compiler could be directly told to ommit them. ---------------------------------------------------------------------- >Comment By: Maarten Brock (maartenbrock) Date: 2007-03-01 08:48 Message: Logged In: YES user_id=888171 Originator: NO I agree we should try to unify the options. I also do not see the need for two/more options for different levels of verboseness in the comments. How about --gen-comments <n>, where n==0 generates no comments, n==1 outputs D() comments and n==2 outputs DD() comments. Personally I don't care too much about avr/xa51 targets. Noone has maintained them for a very long time and I doubt anyone uses them. I even suspect them to be broken. TININative is probably covered by ds390 already. The others should comply. Maarten ---------------------------------------------------------------------- Comment By: Borut Razem (borutr) Date: 2007-02-28 19:02 Message: Logged In: YES user_id=568035 Originator: NO My opinion is to unify the command line options as much as possible. So we should: - keep the --debug-(e)xtra option for pic16 and invert and rename the --no-gen-comments option for other targets or - keep the --no-gen-comments option and invert and rename the --debug-(e)xtra option for pic16 target In case that we chose the --debug-xtra I prefer to add the missing 'e' (--debug-extra). What about other targets: gbz80/z80/avr/pic14/TININative/xa51? Borut ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2007-02-28 10:24 Message: Logged In: YES user_id=589052 Originator: YES yes, I should not have closed the RFE. The pic and pic16 ports seemed to me to be using a different scheme (an "opt in" rather than an "opt out" option for debugging information). Option --debug-xtra would switch on extra information by setting port specific variables. (Nothing wrong with an opt in scheme, but it led me to the assumption the RFE would not apply to pic/pic16.) I implemented this RFE for the 'hc08 port. There is a macro DD() for even more detailed debug information within the 'hc08 port. Eventually make --debug-xtra a global option and couple with DD() ? (Note: the pic/pic16 option is documented as --debug-extra in the manual but the source uses the SMS'ed --debug-xtra) ---------------------------------------------------------------------- Comment By: Borut Razem (borutr) Date: 2007-02-28 07:36 Message: Logged In: YES user_id=568035 Originator: NO I reopened the RFE because it is only partially fixed. NOTE: sdcc does not generate the code only for msc51 and ds390 targets. We should care for the compatibility between all targets as much as possible. Borut ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2007-02-27 13:41 Message: Logged In: YES user_id=589052 Originator: YES implemented (for mcs51, ds390) in SDCC #4658. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1493816&group_id=599 |
From: SourceForge.net <no...@so...> - 2007-03-01 08:06:15
|
Feature Requests item #1493816, was opened at 2006-05-23 22:10 Message generated for change (Comment added) made by frief You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1493816&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: 1 Private: No Submitted By: Frieder Ferlemann (frief) Assigned to: Nobody/Anonymous (nobody) Summary: option --no-gen-comments Initial Comment: (This is a very low priority request:) There is the high level option --no-c-code-in-asm and the low level option --no-peep-comments to suppress comments generated by SDCC, but there is no option to suppress the medium level comments like: 460 ; genCmpGt 461 ; genCmp 462 ; genIfxJump I occasionally find myself filtering out these comments "manually" using the command: grep -v "; gen" MY_FILE.ASM just to be able to read assembly files smoothly. Would be nice if the compiler could be directly told to ommit them. ---------------------------------------------------------------------- >Comment By: Frieder Ferlemann (frief) Date: 2007-03-01 09:06 Message: Logged In: YES user_id=589052 Originator: YES I'd see drawbacks for both --debug-extra and the --no-gen-comments I have chosen. as for --no-gen-comments : it will probably be memorized as no-generate-comments instead of no-gen.c-comments and thus users will be surprised another --no-peep-comments has to be specified to have less verbose assembly output. (Maybe --no-gen-comments should imply --no-peep-comments) as for --debug-extra : this seems like an extension to --debug which (for the 8051, besides embedding line info in the asm) turns on generation of the AOMF file. (--debug is probably what a majority of Windows users use anyway.) The "extra" could then suggest generation of (the yet unknown) Keil's extended AOMF file. gcc would know "-fverbose-asm" and "-fno-verbose-asm". Another option would be to drop both --no-gen-comments and --debug-(e)xtra in favour of gcc'ish options? ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2007-03-01 08:48 Message: Logged In: YES user_id=888171 Originator: NO I agree we should try to unify the options. I also do not see the need for two/more options for different levels of verboseness in the comments. How about --gen-comments <n>, where n==0 generates no comments, n==1 outputs D() comments and n==2 outputs DD() comments. Personally I don't care too much about avr/xa51 targets. Noone has maintained them for a very long time and I doubt anyone uses them. I even suspect them to be broken. TININative is probably covered by ds390 already. The others should comply. Maarten ---------------------------------------------------------------------- Comment By: Borut Razem (borutr) Date: 2007-02-28 19:02 Message: Logged In: YES user_id=568035 Originator: NO My opinion is to unify the command line options as much as possible. So we should: - keep the --debug-(e)xtra option for pic16 and invert and rename the --no-gen-comments option for other targets or - keep the --no-gen-comments option and invert and rename the --debug-(e)xtra option for pic16 target In case that we chose the --debug-xtra I prefer to add the missing 'e' (--debug-extra). What about other targets: gbz80/z80/avr/pic14/TININative/xa51? Borut ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2007-02-28 10:24 Message: Logged In: YES user_id=589052 Originator: YES yes, I should not have closed the RFE. The pic and pic16 ports seemed to me to be using a different scheme (an "opt in" rather than an "opt out" option for debugging information). Option --debug-xtra would switch on extra information by setting port specific variables. (Nothing wrong with an opt in scheme, but it led me to the assumption the RFE would not apply to pic/pic16.) I implemented this RFE for the 'hc08 port. There is a macro DD() for even more detailed debug information within the 'hc08 port. Eventually make --debug-xtra a global option and couple with DD() ? (Note: the pic/pic16 option is documented as --debug-extra in the manual but the source uses the SMS'ed --debug-xtra) ---------------------------------------------------------------------- Comment By: Borut Razem (borutr) Date: 2007-02-28 07:36 Message: Logged In: YES user_id=568035 Originator: NO I reopened the RFE because it is only partially fixed. NOTE: sdcc does not generate the code only for msc51 and ds390 targets. We should care for the compatibility between all targets as much as possible. Borut ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2007-02-27 13:41 Message: Logged In: YES user_id=589052 Originator: YES implemented (for mcs51, ds390) in SDCC #4658. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1493816&group_id=599 |
From: SourceForge.net <no...@so...> - 2007-03-06 17:39:58
|
Feature Requests item #1493816, was opened at 2006-05-23 22:10 Message generated for change (Comment added) made by borutr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1493816&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: 1 Private: No Submitted By: Frieder Ferlemann (frief) Assigned to: Nobody/Anonymous (nobody) Summary: option --no-gen-comments Initial Comment: (This is a very low priority request:) There is the high level option --no-c-code-in-asm and the low level option --no-peep-comments to suppress comments generated by SDCC, but there is no option to suppress the medium level comments like: 460 ; genCmpGt 461 ; genCmp 462 ; genIfxJump I occasionally find myself filtering out these comments "manually" using the command: grep -v "; gen" MY_FILE.ASM just to be able to read assembly files smoothly. Would be nice if the compiler could be directly told to ommit them. ---------------------------------------------------------------------- >Comment By: Borut Razem (borutr) Date: 2007-03-06 18:39 Message: Logged In: YES user_id=568035 Originator: NO I vote to drop both --no-gen-comments and --debug-(e)xtra in favour of gcc'ish --fverbose-asm. Borut ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2007-03-01 09:06 Message: Logged In: YES user_id=589052 Originator: YES I'd see drawbacks for both --debug-extra and the --no-gen-comments I have chosen. as for --no-gen-comments : it will probably be memorized as no-generate-comments instead of no-gen.c-comments and thus users will be surprised another --no-peep-comments has to be specified to have less verbose assembly output. (Maybe --no-gen-comments should imply --no-peep-comments) as for --debug-extra : this seems like an extension to --debug which (for the 8051, besides embedding line info in the asm) turns on generation of the AOMF file. (--debug is probably what a majority of Windows users use anyway.) The "extra" could then suggest generation of (the yet unknown) Keil's extended AOMF file. gcc would know "-fverbose-asm" and "-fno-verbose-asm". Another option would be to drop both --no-gen-comments and --debug-(e)xtra in favour of gcc'ish options? ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2007-03-01 08:48 Message: Logged In: YES user_id=888171 Originator: NO I agree we should try to unify the options. I also do not see the need for two/more options for different levels of verboseness in the comments. How about --gen-comments <n>, where n==0 generates no comments, n==1 outputs D() comments and n==2 outputs DD() comments. Personally I don't care too much about avr/xa51 targets. Noone has maintained them for a very long time and I doubt anyone uses them. I even suspect them to be broken. TININative is probably covered by ds390 already. The others should comply. Maarten ---------------------------------------------------------------------- Comment By: Borut Razem (borutr) Date: 2007-02-28 19:02 Message: Logged In: YES user_id=568035 Originator: NO My opinion is to unify the command line options as much as possible. So we should: - keep the --debug-(e)xtra option for pic16 and invert and rename the --no-gen-comments option for other targets or - keep the --no-gen-comments option and invert and rename the --debug-(e)xtra option for pic16 target In case that we chose the --debug-xtra I prefer to add the missing 'e' (--debug-extra). What about other targets: gbz80/z80/avr/pic14/TININative/xa51? Borut ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2007-02-28 10:24 Message: Logged In: YES user_id=589052 Originator: YES yes, I should not have closed the RFE. The pic and pic16 ports seemed to me to be using a different scheme (an "opt in" rather than an "opt out" option for debugging information). Option --debug-xtra would switch on extra information by setting port specific variables. (Nothing wrong with an opt in scheme, but it led me to the assumption the RFE would not apply to pic/pic16.) I implemented this RFE for the 'hc08 port. There is a macro DD() for even more detailed debug information within the 'hc08 port. Eventually make --debug-xtra a global option and couple with DD() ? (Note: the pic/pic16 option is documented as --debug-extra in the manual but the source uses the SMS'ed --debug-xtra) ---------------------------------------------------------------------- Comment By: Borut Razem (borutr) Date: 2007-02-28 07:36 Message: Logged In: YES user_id=568035 Originator: NO I reopened the RFE because it is only partially fixed. NOTE: sdcc does not generate the code only for msc51 and ds390 targets. We should care for the compatibility between all targets as much as possible. Borut ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2007-02-27 13:41 Message: Logged In: YES user_id=589052 Originator: YES implemented (for mcs51, ds390) in SDCC #4658. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1493816&group_id=599 |
From: SourceForge.net <no...@so...> - 2007-03-06 18:42:07
|
Feature Requests item #1493816, was opened at 2006-05-23 22:10 Message generated for change (Comment added) made by maartenbrock You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1493816&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: 1 Private: No Submitted By: Frieder Ferlemann (frief) Assigned to: Nobody/Anonymous (nobody) Summary: option --no-gen-comments Initial Comment: (This is a very low priority request:) There is the high level option --no-c-code-in-asm and the low level option --no-peep-comments to suppress comments generated by SDCC, but there is no option to suppress the medium level comments like: 460 ; genCmpGt 461 ; genCmp 462 ; genIfxJump I occasionally find myself filtering out these comments "manually" using the command: grep -v "; gen" MY_FILE.ASM just to be able to read assembly files smoothly. Would be nice if the compiler could be directly told to ommit them. ---------------------------------------------------------------------- >Comment By: Maarten Brock (maartenbrock) Date: 2007-03-06 19:42 Message: Logged In: YES user_id=888171 Originator: NO Does that include a level of verboseness? If not and we do like to have this level, we might as well use --gen-comments <n> like I proposed earlier. ---------------------------------------------------------------------- Comment By: Borut Razem (borutr) Date: 2007-03-06 18:39 Message: Logged In: YES user_id=568035 Originator: NO I vote to drop both --no-gen-comments and --debug-(e)xtra in favour of gcc'ish --fverbose-asm. Borut ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2007-03-01 09:06 Message: Logged In: YES user_id=589052 Originator: YES I'd see drawbacks for both --debug-extra and the --no-gen-comments I have chosen. as for --no-gen-comments : it will probably be memorized as no-generate-comments instead of no-gen.c-comments and thus users will be surprised another --no-peep-comments has to be specified to have less verbose assembly output. (Maybe --no-gen-comments should imply --no-peep-comments) as for --debug-extra : this seems like an extension to --debug which (for the 8051, besides embedding line info in the asm) turns on generation of the AOMF file. (--debug is probably what a majority of Windows users use anyway.) The "extra" could then suggest generation of (the yet unknown) Keil's extended AOMF file. gcc would know "-fverbose-asm" and "-fno-verbose-asm". Another option would be to drop both --no-gen-comments and --debug-(e)xtra in favour of gcc'ish options? ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2007-03-01 08:48 Message: Logged In: YES user_id=888171 Originator: NO I agree we should try to unify the options. I also do not see the need for two/more options for different levels of verboseness in the comments. How about --gen-comments <n>, where n==0 generates no comments, n==1 outputs D() comments and n==2 outputs DD() comments. Personally I don't care too much about avr/xa51 targets. Noone has maintained them for a very long time and I doubt anyone uses them. I even suspect them to be broken. TININative is probably covered by ds390 already. The others should comply. Maarten ---------------------------------------------------------------------- Comment By: Borut Razem (borutr) Date: 2007-02-28 19:02 Message: Logged In: YES user_id=568035 Originator: NO My opinion is to unify the command line options as much as possible. So we should: - keep the --debug-(e)xtra option for pic16 and invert and rename the --no-gen-comments option for other targets or - keep the --no-gen-comments option and invert and rename the --debug-(e)xtra option for pic16 target In case that we chose the --debug-xtra I prefer to add the missing 'e' (--debug-extra). What about other targets: gbz80/z80/avr/pic14/TININative/xa51? Borut ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2007-02-28 10:24 Message: Logged In: YES user_id=589052 Originator: YES yes, I should not have closed the RFE. The pic and pic16 ports seemed to me to be using a different scheme (an "opt in" rather than an "opt out" option for debugging information). Option --debug-xtra would switch on extra information by setting port specific variables. (Nothing wrong with an opt in scheme, but it led me to the assumption the RFE would not apply to pic/pic16.) I implemented this RFE for the 'hc08 port. There is a macro DD() for even more detailed debug information within the 'hc08 port. Eventually make --debug-xtra a global option and couple with DD() ? (Note: the pic/pic16 option is documented as --debug-extra in the manual but the source uses the SMS'ed --debug-xtra) ---------------------------------------------------------------------- Comment By: Borut Razem (borutr) Date: 2007-02-28 07:36 Message: Logged In: YES user_id=568035 Originator: NO I reopened the RFE because it is only partially fixed. NOTE: sdcc does not generate the code only for msc51 and ds390 targets. We should care for the compatibility between all targets as much as possible. Borut ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2007-02-27 13:41 Message: Logged In: YES user_id=589052 Originator: YES implemented (for mcs51, ds390) in SDCC #4658. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1493816&group_id=599 |
From: SourceForge.net <no...@so...> - 2007-03-14 17:21:05
|
Feature Requests item #1493816, was opened at 2006-05-23 22:10 Message generated for change (Comment added) made by borutr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1493816&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: 1 Private: No Submitted By: Frieder Ferlemann (frief) Assigned to: Nobody/Anonymous (nobody) Summary: option --no-gen-comments Initial Comment: (This is a very low priority request:) There is the high level option --no-c-code-in-asm and the low level option --no-peep-comments to suppress comments generated by SDCC, but there is no option to suppress the medium level comments like: 460 ; genCmpGt 461 ; genCmp 462 ; genIfxJump I occasionally find myself filtering out these comments "manually" using the command: grep -v "; gen" MY_FILE.ASM just to be able to read assembly files smoothly. Would be nice if the compiler could be directly told to ommit them. ---------------------------------------------------------------------- >Comment By: Borut Razem (borutr) Date: 2007-03-14 18:21 Message: Logged In: YES user_id=568035 Originator: NO man gcc says: <quote> -fverbose-asm Put extra commentary information in the generated assembly code to make it more readable. This option is generally only of use to those who actually need to read the generated assembly code (per- haps while debugging the compiler itself). </quote> so there is no level of verbosity - is "all or nothing" approach. If this is not acceptable for sdcc, I would rephrase --gen-comments <n> to --gen-asm-comments <n>. Borut ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2007-03-06 19:42 Message: Logged In: YES user_id=888171 Originator: NO Does that include a level of verboseness? If not and we do like to have this level, we might as well use --gen-comments <n> like I proposed earlier. ---------------------------------------------------------------------- Comment By: Borut Razem (borutr) Date: 2007-03-06 18:39 Message: Logged In: YES user_id=568035 Originator: NO I vote to drop both --no-gen-comments and --debug-(e)xtra in favour of gcc'ish --fverbose-asm. Borut ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2007-03-01 09:06 Message: Logged In: YES user_id=589052 Originator: YES I'd see drawbacks for both --debug-extra and the --no-gen-comments I have chosen. as for --no-gen-comments : it will probably be memorized as no-generate-comments instead of no-gen.c-comments and thus users will be surprised another --no-peep-comments has to be specified to have less verbose assembly output. (Maybe --no-gen-comments should imply --no-peep-comments) as for --debug-extra : this seems like an extension to --debug which (for the 8051, besides embedding line info in the asm) turns on generation of the AOMF file. (--debug is probably what a majority of Windows users use anyway.) The "extra" could then suggest generation of (the yet unknown) Keil's extended AOMF file. gcc would know "-fverbose-asm" and "-fno-verbose-asm". Another option would be to drop both --no-gen-comments and --debug-(e)xtra in favour of gcc'ish options? ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2007-03-01 08:48 Message: Logged In: YES user_id=888171 Originator: NO I agree we should try to unify the options. I also do not see the need for two/more options for different levels of verboseness in the comments. How about --gen-comments <n>, where n==0 generates no comments, n==1 outputs D() comments and n==2 outputs DD() comments. Personally I don't care too much about avr/xa51 targets. Noone has maintained them for a very long time and I doubt anyone uses them. I even suspect them to be broken. TININative is probably covered by ds390 already. The others should comply. Maarten ---------------------------------------------------------------------- Comment By: Borut Razem (borutr) Date: 2007-02-28 19:02 Message: Logged In: YES user_id=568035 Originator: NO My opinion is to unify the command line options as much as possible. So we should: - keep the --debug-(e)xtra option for pic16 and invert and rename the --no-gen-comments option for other targets or - keep the --no-gen-comments option and invert and rename the --debug-(e)xtra option for pic16 target In case that we chose the --debug-xtra I prefer to add the missing 'e' (--debug-extra). What about other targets: gbz80/z80/avr/pic14/TININative/xa51? Borut ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2007-02-28 10:24 Message: Logged In: YES user_id=589052 Originator: YES yes, I should not have closed the RFE. The pic and pic16 ports seemed to me to be using a different scheme (an "opt in" rather than an "opt out" option for debugging information). Option --debug-xtra would switch on extra information by setting port specific variables. (Nothing wrong with an opt in scheme, but it led me to the assumption the RFE would not apply to pic/pic16.) I implemented this RFE for the 'hc08 port. There is a macro DD() for even more detailed debug information within the 'hc08 port. Eventually make --debug-xtra a global option and couple with DD() ? (Note: the pic/pic16 option is documented as --debug-extra in the manual but the source uses the SMS'ed --debug-xtra) ---------------------------------------------------------------------- Comment By: Borut Razem (borutr) Date: 2007-02-28 07:36 Message: Logged In: YES user_id=568035 Originator: NO I reopened the RFE because it is only partially fixed. NOTE: sdcc does not generate the code only for msc51 and ds390 targets. We should care for the compatibility between all targets as much as possible. Borut ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2007-02-27 13:41 Message: Logged In: YES user_id=589052 Originator: YES implemented (for mcs51, ds390) in SDCC #4658. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1493816&group_id=599 |
From: SourceForge.net <no...@so...> - 2007-03-21 16:37:59
|
Feature Requests item #1493816, was opened at 2006-05-23 13:10 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1493816&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: 1 Private: No Submitted By: Frieder Ferlemann (frief) Assigned to: Nobody/Anonymous (nobody) Summary: option --no-gen-comments Initial Comment: (This is a very low priority request:) There is the high level option --no-c-code-in-asm and the low level option --no-peep-comments to suppress comments generated by SDCC, but there is no option to suppress the medium level comments like: 460 ; genCmpGt 461 ; genCmp 462 ; genIfxJump I occasionally find myself filtering out these comments "manually" using the command: grep -v "; gen" MY_FILE.ASM just to be able to read assembly files smoothly. Would be nice if the compiler could be directly told to ommit them. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-03-21 09:37 Message: Logged In: NO Just to provide some additional feedback: Personally, I really do like these commented assembly outputs - I find them particularly useful when trying to get familiar with a new chip, so that I actually get to see a mapping between my HLL C code and the actual ASM. While I do realize that some people may even find the current implementation sometimes offensive or annoying, I would personally even vote for an extension of this, simply because it can truly help understanding the compilation process, as well as the ISA. Thus, I would like to propose providing an additional (optional) parameter that would tell the compiler to create VERY VERBOSE assembly output, which would preferably contain ALL of the HLL C code, added as comments in the proper locations. Preferably, also adding additional comments along the lines of: - " start/end of [[do/while/for] loop]/[function $funcname]" - " setting up arg x of type Y to call function $funcname" ... While this may seem very verbose and redundant to someone already familiar with the instruction set, it surely is very beneficial in situations where you are yet to become really familiar with the chip. Likewise, having a mode where variable names from the C code are sort of retained in the asm output (by naming the macros/ constants accordingly), would also be helpful. If necessary, variable names could be somewhat mangled to account for identical names. Also, I feel that it might be a good idea to also add some more info to the introductory comment, namely: - target assembler/version & URL (i.e. "gpasm-0.13.4 beta) - the sdcc SF.net URL. This would directly provide crucial background information for users who may not yet be all that familiar with the sdcc suite of tools and its dependencies (namely, gputils). ---------------------------------------------------------------------- Comment By: Borut Razem (borutr) Date: 2007-03-14 10:21 Message: Logged In: YES user_id=568035 Originator: NO man gcc says: <quote> -fverbose-asm Put extra commentary information in the generated assembly code to make it more readable. This option is generally only of use to those who actually need to read the generated assembly code (per- haps while debugging the compiler itself). </quote> so there is no level of verbosity - is "all or nothing" approach. If this is not acceptable for sdcc, I would rephrase --gen-comments <n> to --gen-asm-comments <n>. Borut ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2007-03-06 10:42 Message: Logged In: YES user_id=888171 Originator: NO Does that include a level of verboseness? If not and we do like to have this level, we might as well use --gen-comments <n> like I proposed earlier. ---------------------------------------------------------------------- Comment By: Borut Razem (borutr) Date: 2007-03-06 09:39 Message: Logged In: YES user_id=568035 Originator: NO I vote to drop both --no-gen-comments and --debug-(e)xtra in favour of gcc'ish --fverbose-asm. Borut ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2007-03-01 00:06 Message: Logged In: YES user_id=589052 Originator: YES I'd see drawbacks for both --debug-extra and the --no-gen-comments I have chosen. as for --no-gen-comments : it will probably be memorized as no-generate-comments instead of no-gen.c-comments and thus users will be surprised another --no-peep-comments has to be specified to have less verbose assembly output. (Maybe --no-gen-comments should imply --no-peep-comments) as for --debug-extra : this seems like an extension to --debug which (for the 8051, besides embedding line info in the asm) turns on generation of the AOMF file. (--debug is probably what a majority of Windows users use anyway.) The "extra" could then suggest generation of (the yet unknown) Keil's extended AOMF file. gcc would know "-fverbose-asm" and "-fno-verbose-asm". Another option would be to drop both --no-gen-comments and --debug-(e)xtra in favour of gcc'ish options? ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2007-02-28 23:48 Message: Logged In: YES user_id=888171 Originator: NO I agree we should try to unify the options. I also do not see the need for two/more options for different levels of verboseness in the comments. How about --gen-comments <n>, where n==0 generates no comments, n==1 outputs D() comments and n==2 outputs DD() comments. Personally I don't care too much about avr/xa51 targets. Noone has maintained them for a very long time and I doubt anyone uses them. I even suspect them to be broken. TININative is probably covered by ds390 already. The others should comply. Maarten ---------------------------------------------------------------------- Comment By: Borut Razem (borutr) Date: 2007-02-28 10:02 Message: Logged In: YES user_id=568035 Originator: NO My opinion is to unify the command line options as much as possible. So we should: - keep the --debug-(e)xtra option for pic16 and invert and rename the --no-gen-comments option for other targets or - keep the --no-gen-comments option and invert and rename the --debug-(e)xtra option for pic16 target In case that we chose the --debug-xtra I prefer to add the missing 'e' (--debug-extra). What about other targets: gbz80/z80/avr/pic14/TININative/xa51? Borut ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2007-02-28 01:24 Message: Logged In: YES user_id=589052 Originator: YES yes, I should not have closed the RFE. The pic and pic16 ports seemed to me to be using a different scheme (an "opt in" rather than an "opt out" option for debugging information). Option --debug-xtra would switch on extra information by setting port specific variables. (Nothing wrong with an opt in scheme, but it led me to the assumption the RFE would not apply to pic/pic16.) I implemented this RFE for the 'hc08 port. There is a macro DD() for even more detailed debug information within the 'hc08 port. Eventually make --debug-xtra a global option and couple with DD() ? (Note: the pic/pic16 option is documented as --debug-extra in the manual but the source uses the SMS'ed --debug-xtra) ---------------------------------------------------------------------- Comment By: Borut Razem (borutr) Date: 2007-02-27 22:36 Message: Logged In: YES user_id=568035 Originator: NO I reopened the RFE because it is only partially fixed. NOTE: sdcc does not generate the code only for msc51 and ds390 targets. We should care for the compatibility between all targets as much as possible. Borut ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2007-02-27 04:41 Message: Logged In: YES user_id=589052 Originator: YES implemented (for mcs51, ds390) in SDCC #4658. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1493816&group_id=599 |
From: SourceForge.net <no...@so...> - 2007-04-17 19:23:38
|
Feature Requests item #1493816, was opened at 2006-05-23 22:10 Message generated for change (Comment added) made by borutr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1493816&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: 1 Private: No Submitted By: Frieder Ferlemann (frief) Assigned to: Nobody/Anonymous (nobody) Summary: option --no-gen-comments Initial Comment: (This is a very low priority request:) There is the high level option --no-c-code-in-asm and the low level option --no-peep-comments to suppress comments generated by SDCC, but there is no option to suppress the medium level comments like: 460 ; genCmpGt 461 ; genCmp 462 ; genIfxJump I occasionally find myself filtering out these comments "manually" using the command: grep -v "; gen" MY_FILE.ASM just to be able to read assembly files smoothly. Would be nice if the compiler could be directly told to ommit them. ---------------------------------------------------------------------- >Comment By: Borut Razem (borutr) Date: 2007-04-17 21:23 Message: Logged In: YES user_id=568035 Originator: NO I took a other look to the code and I realize that we probably shouldn't mix the --no-gen-comments with --debug-xtra: the fist deals with the comments, which are useful to the sdcc user, while the second adds additional debugging info, useful to sdcc developer (I hope that I understood it well). My current ;-) proposal is to: - leave --debug-xtra as it is, eventually couple it with DD macro in hc08 target, as proposed by Frieder. And I changed my mind about the name too: it should remain --debug-xtra and the documentation should be corrected. - replace --no-gen-comments with --fverbose-asm, obviously by reversing the logic Borut ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-03-21 17:37 Message: Logged In: NO Just to provide some additional feedback: Personally, I really do like these commented assembly outputs - I find them particularly useful when trying to get familiar with a new chip, so that I actually get to see a mapping between my HLL C code and the actual ASM. While I do realize that some people may even find the current implementation sometimes offensive or annoying, I would personally even vote for an extension of this, simply because it can truly help understanding the compilation process, as well as the ISA. Thus, I would like to propose providing an additional (optional) parameter that would tell the compiler to create VERY VERBOSE assembly output, which would preferably contain ALL of the HLL C code, added as comments in the proper locations. Preferably, also adding additional comments along the lines of: - " start/end of [[do/while/for] loop]/[function $funcname]" - " setting up arg x of type Y to call function $funcname" ... While this may seem very verbose and redundant to someone already familiar with the instruction set, it surely is very beneficial in situations where you are yet to become really familiar with the chip. Likewise, having a mode where variable names from the C code are sort of retained in the asm output (by naming the macros/ constants accordingly), would also be helpful. If necessary, variable names could be somewhat mangled to account for identical names. Also, I feel that it might be a good idea to also add some more info to the introductory comment, namely: - target assembler/version & URL (i.e. "gpasm-0.13.4 beta) - the sdcc SF.net URL. This would directly provide crucial background information for users who may not yet be all that familiar with the sdcc suite of tools and its dependencies (namely, gputils). ---------------------------------------------------------------------- Comment By: Borut Razem (borutr) Date: 2007-03-14 18:21 Message: Logged In: YES user_id=568035 Originator: NO man gcc says: <quote> -fverbose-asm Put extra commentary information in the generated assembly code to make it more readable. This option is generally only of use to those who actually need to read the generated assembly code (per- haps while debugging the compiler itself). </quote> so there is no level of verbosity - is "all or nothing" approach. If this is not acceptable for sdcc, I would rephrase --gen-comments <n> to --gen-asm-comments <n>. Borut ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2007-03-06 19:42 Message: Logged In: YES user_id=888171 Originator: NO Does that include a level of verboseness? If not and we do like to have this level, we might as well use --gen-comments <n> like I proposed earlier. ---------------------------------------------------------------------- Comment By: Borut Razem (borutr) Date: 2007-03-06 18:39 Message: Logged In: YES user_id=568035 Originator: NO I vote to drop both --no-gen-comments and --debug-(e)xtra in favour of gcc'ish --fverbose-asm. Borut ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2007-03-01 09:06 Message: Logged In: YES user_id=589052 Originator: YES I'd see drawbacks for both --debug-extra and the --no-gen-comments I have chosen. as for --no-gen-comments : it will probably be memorized as no-generate-comments instead of no-gen.c-comments and thus users will be surprised another --no-peep-comments has to be specified to have less verbose assembly output. (Maybe --no-gen-comments should imply --no-peep-comments) as for --debug-extra : this seems like an extension to --debug which (for the 8051, besides embedding line info in the asm) turns on generation of the AOMF file. (--debug is probably what a majority of Windows users use anyway.) The "extra" could then suggest generation of (the yet unknown) Keil's extended AOMF file. gcc would know "-fverbose-asm" and "-fno-verbose-asm". Another option would be to drop both --no-gen-comments and --debug-(e)xtra in favour of gcc'ish options? ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2007-03-01 08:48 Message: Logged In: YES user_id=888171 Originator: NO I agree we should try to unify the options. I also do not see the need for two/more options for different levels of verboseness in the comments. How about --gen-comments <n>, where n==0 generates no comments, n==1 outputs D() comments and n==2 outputs DD() comments. Personally I don't care too much about avr/xa51 targets. Noone has maintained them for a very long time and I doubt anyone uses them. I even suspect them to be broken. TININative is probably covered by ds390 already. The others should comply. Maarten ---------------------------------------------------------------------- Comment By: Borut Razem (borutr) Date: 2007-02-28 19:02 Message: Logged In: YES user_id=568035 Originator: NO My opinion is to unify the command line options as much as possible. So we should: - keep the --debug-(e)xtra option for pic16 and invert and rename the --no-gen-comments option for other targets or - keep the --no-gen-comments option and invert and rename the --debug-(e)xtra option for pic16 target In case that we chose the --debug-xtra I prefer to add the missing 'e' (--debug-extra). What about other targets: gbz80/z80/avr/pic14/TININative/xa51? Borut ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2007-02-28 10:24 Message: Logged In: YES user_id=589052 Originator: YES yes, I should not have closed the RFE. The pic and pic16 ports seemed to me to be using a different scheme (an "opt in" rather than an "opt out" option for debugging information). Option --debug-xtra would switch on extra information by setting port specific variables. (Nothing wrong with an opt in scheme, but it led me to the assumption the RFE would not apply to pic/pic16.) I implemented this RFE for the 'hc08 port. There is a macro DD() for even more detailed debug information within the 'hc08 port. Eventually make --debug-xtra a global option and couple with DD() ? (Note: the pic/pic16 option is documented as --debug-extra in the manual but the source uses the SMS'ed --debug-xtra) ---------------------------------------------------------------------- Comment By: Borut Razem (borutr) Date: 2007-02-28 07:36 Message: Logged In: YES user_id=568035 Originator: NO I reopened the RFE because it is only partially fixed. NOTE: sdcc does not generate the code only for msc51 and ds390 targets. We should care for the compatibility between all targets as much as possible. Borut ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2007-02-27 13:41 Message: Logged In: YES user_id=589052 Originator: YES implemented (for mcs51, ds390) in SDCC #4658. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1493816&group_id=599 |
From: SourceForge.net <no...@so...> - 2007-04-17 20:15:48
|
Feature Requests item #1493816, was opened at 2006-05-23 22:10 Message generated for change (Comment added) made by borutr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1493816&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: Closed Priority: 1 Private: No Submitted By: Frieder Ferlemann (frief) >Assigned to: Borut Razem (borutr) Summary: option --no-gen-comments Initial Comment: (This is a very low priority request:) There is the high level option --no-c-code-in-asm and the low level option --no-peep-comments to suppress comments generated by SDCC, but there is no option to suppress the medium level comments like: 460 ; genCmpGt 461 ; genCmp 462 ; genIfxJump I occasionally find myself filtering out these comments "manually" using the command: grep -v "; gen" MY_FILE.ASM just to be able to read assembly files smoothly. Would be nice if the compiler could be directly told to ommit them. ---------------------------------------------------------------------- >Comment By: Borut Razem (borutr) Date: 2007-04-17 22:15 Message: Logged In: YES user_id=568035 Originator: NO I implemented it in the following way: - --debug-extra corrected to --debug-xtra in the sdccman.lyx - DD macro in hc08 is not coupled to --debuf-xtra - --no-gen-comments replaced with --fverbose-asm and reversing the logic ---------------------------------------------------------------------- Comment By: Borut Razem (borutr) Date: 2007-04-17 21:23 Message: Logged In: YES user_id=568035 Originator: NO I took a other look to the code and I realize that we probably shouldn't mix the --no-gen-comments with --debug-xtra: the fist deals with the comments, which are useful to the sdcc user, while the second adds additional debugging info, useful to sdcc developer (I hope that I understood it well). My current ;-) proposal is to: - leave --debug-xtra as it is, eventually couple it with DD macro in hc08 target, as proposed by Frieder. And I changed my mind about the name too: it should remain --debug-xtra and the documentation should be corrected. - replace --no-gen-comments with --fverbose-asm, obviously by reversing the logic Borut ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-03-21 17:37 Message: Logged In: NO Just to provide some additional feedback: Personally, I really do like these commented assembly outputs - I find them particularly useful when trying to get familiar with a new chip, so that I actually get to see a mapping between my HLL C code and the actual ASM. While I do realize that some people may even find the current implementation sometimes offensive or annoying, I would personally even vote for an extension of this, simply because it can truly help understanding the compilation process, as well as the ISA. Thus, I would like to propose providing an additional (optional) parameter that would tell the compiler to create VERY VERBOSE assembly output, which would preferably contain ALL of the HLL C code, added as comments in the proper locations. Preferably, also adding additional comments along the lines of: - " start/end of [[do/while/for] loop]/[function $funcname]" - " setting up arg x of type Y to call function $funcname" ... While this may seem very verbose and redundant to someone already familiar with the instruction set, it surely is very beneficial in situations where you are yet to become really familiar with the chip. Likewise, having a mode where variable names from the C code are sort of retained in the asm output (by naming the macros/ constants accordingly), would also be helpful. If necessary, variable names could be somewhat mangled to account for identical names. Also, I feel that it might be a good idea to also add some more info to the introductory comment, namely: - target assembler/version & URL (i.e. "gpasm-0.13.4 beta) - the sdcc SF.net URL. This would directly provide crucial background information for users who may not yet be all that familiar with the sdcc suite of tools and its dependencies (namely, gputils). ---------------------------------------------------------------------- Comment By: Borut Razem (borutr) Date: 2007-03-14 18:21 Message: Logged In: YES user_id=568035 Originator: NO man gcc says: <quote> -fverbose-asm Put extra commentary information in the generated assembly code to make it more readable. This option is generally only of use to those who actually need to read the generated assembly code (per- haps while debugging the compiler itself). </quote> so there is no level of verbosity - is "all or nothing" approach. If this is not acceptable for sdcc, I would rephrase --gen-comments <n> to --gen-asm-comments <n>. Borut ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2007-03-06 19:42 Message: Logged In: YES user_id=888171 Originator: NO Does that include a level of verboseness? If not and we do like to have this level, we might as well use --gen-comments <n> like I proposed earlier. ---------------------------------------------------------------------- Comment By: Borut Razem (borutr) Date: 2007-03-06 18:39 Message: Logged In: YES user_id=568035 Originator: NO I vote to drop both --no-gen-comments and --debug-(e)xtra in favour of gcc'ish --fverbose-asm. Borut ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2007-03-01 09:06 Message: Logged In: YES user_id=589052 Originator: YES I'd see drawbacks for both --debug-extra and the --no-gen-comments I have chosen. as for --no-gen-comments : it will probably be memorized as no-generate-comments instead of no-gen.c-comments and thus users will be surprised another --no-peep-comments has to be specified to have less verbose assembly output. (Maybe --no-gen-comments should imply --no-peep-comments) as for --debug-extra : this seems like an extension to --debug which (for the 8051, besides embedding line info in the asm) turns on generation of the AOMF file. (--debug is probably what a majority of Windows users use anyway.) The "extra" could then suggest generation of (the yet unknown) Keil's extended AOMF file. gcc would know "-fverbose-asm" and "-fno-verbose-asm". Another option would be to drop both --no-gen-comments and --debug-(e)xtra in favour of gcc'ish options? ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2007-03-01 08:48 Message: Logged In: YES user_id=888171 Originator: NO I agree we should try to unify the options. I also do not see the need for two/more options for different levels of verboseness in the comments. How about --gen-comments <n>, where n==0 generates no comments, n==1 outputs D() comments and n==2 outputs DD() comments. Personally I don't care too much about avr/xa51 targets. Noone has maintained them for a very long time and I doubt anyone uses them. I even suspect them to be broken. TININative is probably covered by ds390 already. The others should comply. Maarten ---------------------------------------------------------------------- Comment By: Borut Razem (borutr) Date: 2007-02-28 19:02 Message: Logged In: YES user_id=568035 Originator: NO My opinion is to unify the command line options as much as possible. So we should: - keep the --debug-(e)xtra option for pic16 and invert and rename the --no-gen-comments option for other targets or - keep the --no-gen-comments option and invert and rename the --debug-(e)xtra option for pic16 target In case that we chose the --debug-xtra I prefer to add the missing 'e' (--debug-extra). What about other targets: gbz80/z80/avr/pic14/TININative/xa51? Borut ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2007-02-28 10:24 Message: Logged In: YES user_id=589052 Originator: YES yes, I should not have closed the RFE. The pic and pic16 ports seemed to me to be using a different scheme (an "opt in" rather than an "opt out" option for debugging information). Option --debug-xtra would switch on extra information by setting port specific variables. (Nothing wrong with an opt in scheme, but it led me to the assumption the RFE would not apply to pic/pic16.) I implemented this RFE for the 'hc08 port. There is a macro DD() for even more detailed debug information within the 'hc08 port. Eventually make --debug-xtra a global option and couple with DD() ? (Note: the pic/pic16 option is documented as --debug-extra in the manual but the source uses the SMS'ed --debug-xtra) ---------------------------------------------------------------------- Comment By: Borut Razem (borutr) Date: 2007-02-28 07:36 Message: Logged In: YES user_id=568035 Originator: NO I reopened the RFE because it is only partially fixed. NOTE: sdcc does not generate the code only for msc51 and ds390 targets. We should care for the compatibility between all targets as much as possible. Borut ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2007-02-27 13:41 Message: Logged In: YES user_id=589052 Originator: YES implemented (for mcs51, ds390) in SDCC #4658. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1493816&group_id=599 |
From: SourceForge.net <no...@so...> - 2007-04-17 20:17:15
|
Feature Requests item #1493816, was opened at 2006-05-23 22:10 Message generated for change (Comment added) made by borutr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1493816&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: Closed Priority: 1 Private: No Submitted By: Frieder Ferlemann (frief) Assigned to: Borut Razem (borutr) Summary: option --no-gen-comments Initial Comment: (This is a very low priority request:) There is the high level option --no-c-code-in-asm and the low level option --no-peep-comments to suppress comments generated by SDCC, but there is no option to suppress the medium level comments like: 460 ; genCmpGt 461 ; genCmp 462 ; genIfxJump I occasionally find myself filtering out these comments "manually" using the command: grep -v "; gen" MY_FILE.ASM just to be able to read assembly files smoothly. Would be nice if the compiler could be directly told to ommit them. ---------------------------------------------------------------------- >Comment By: Borut Razem (borutr) Date: 2007-04-17 22:17 Message: Logged In: YES user_id=568035 Originator: NO fixed in sdcc revision #4754 Borut ---------------------------------------------------------------------- Comment By: Borut Razem (borutr) Date: 2007-04-17 22:15 Message: Logged In: YES user_id=568035 Originator: NO I implemented it in the following way: - --debug-extra corrected to --debug-xtra in the sdccman.lyx - DD macro in hc08 is not coupled to --debuf-xtra - --no-gen-comments replaced with --fverbose-asm and reversing the logic ---------------------------------------------------------------------- Comment By: Borut Razem (borutr) Date: 2007-04-17 21:23 Message: Logged In: YES user_id=568035 Originator: NO I took a other look to the code and I realize that we probably shouldn't mix the --no-gen-comments with --debug-xtra: the fist deals with the comments, which are useful to the sdcc user, while the second adds additional debugging info, useful to sdcc developer (I hope that I understood it well). My current ;-) proposal is to: - leave --debug-xtra as it is, eventually couple it with DD macro in hc08 target, as proposed by Frieder. And I changed my mind about the name too: it should remain --debug-xtra and the documentation should be corrected. - replace --no-gen-comments with --fverbose-asm, obviously by reversing the logic Borut ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-03-21 17:37 Message: Logged In: NO Just to provide some additional feedback: Personally, I really do like these commented assembly outputs - I find them particularly useful when trying to get familiar with a new chip, so that I actually get to see a mapping between my HLL C code and the actual ASM. While I do realize that some people may even find the current implementation sometimes offensive or annoying, I would personally even vote for an extension of this, simply because it can truly help understanding the compilation process, as well as the ISA. Thus, I would like to propose providing an additional (optional) parameter that would tell the compiler to create VERY VERBOSE assembly output, which would preferably contain ALL of the HLL C code, added as comments in the proper locations. Preferably, also adding additional comments along the lines of: - " start/end of [[do/while/for] loop]/[function $funcname]" - " setting up arg x of type Y to call function $funcname" ... While this may seem very verbose and redundant to someone already familiar with the instruction set, it surely is very beneficial in situations where you are yet to become really familiar with the chip. Likewise, having a mode where variable names from the C code are sort of retained in the asm output (by naming the macros/ constants accordingly), would also be helpful. If necessary, variable names could be somewhat mangled to account for identical names. Also, I feel that it might be a good idea to also add some more info to the introductory comment, namely: - target assembler/version & URL (i.e. "gpasm-0.13.4 beta) - the sdcc SF.net URL. This would directly provide crucial background information for users who may not yet be all that familiar with the sdcc suite of tools and its dependencies (namely, gputils). ---------------------------------------------------------------------- Comment By: Borut Razem (borutr) Date: 2007-03-14 18:21 Message: Logged In: YES user_id=568035 Originator: NO man gcc says: <quote> -fverbose-asm Put extra commentary information in the generated assembly code to make it more readable. This option is generally only of use to those who actually need to read the generated assembly code (per- haps while debugging the compiler itself). </quote> so there is no level of verbosity - is "all or nothing" approach. If this is not acceptable for sdcc, I would rephrase --gen-comments <n> to --gen-asm-comments <n>. Borut ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2007-03-06 19:42 Message: Logged In: YES user_id=888171 Originator: NO Does that include a level of verboseness? If not and we do like to have this level, we might as well use --gen-comments <n> like I proposed earlier. ---------------------------------------------------------------------- Comment By: Borut Razem (borutr) Date: 2007-03-06 18:39 Message: Logged In: YES user_id=568035 Originator: NO I vote to drop both --no-gen-comments and --debug-(e)xtra in favour of gcc'ish --fverbose-asm. Borut ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2007-03-01 09:06 Message: Logged In: YES user_id=589052 Originator: YES I'd see drawbacks for both --debug-extra and the --no-gen-comments I have chosen. as for --no-gen-comments : it will probably be memorized as no-generate-comments instead of no-gen.c-comments and thus users will be surprised another --no-peep-comments has to be specified to have less verbose assembly output. (Maybe --no-gen-comments should imply --no-peep-comments) as for --debug-extra : this seems like an extension to --debug which (for the 8051, besides embedding line info in the asm) turns on generation of the AOMF file. (--debug is probably what a majority of Windows users use anyway.) The "extra" could then suggest generation of (the yet unknown) Keil's extended AOMF file. gcc would know "-fverbose-asm" and "-fno-verbose-asm". Another option would be to drop both --no-gen-comments and --debug-(e)xtra in favour of gcc'ish options? ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2007-03-01 08:48 Message: Logged In: YES user_id=888171 Originator: NO I agree we should try to unify the options. I also do not see the need for two/more options for different levels of verboseness in the comments. How about --gen-comments <n>, where n==0 generates no comments, n==1 outputs D() comments and n==2 outputs DD() comments. Personally I don't care too much about avr/xa51 targets. Noone has maintained them for a very long time and I doubt anyone uses them. I even suspect them to be broken. TININative is probably covered by ds390 already. The others should comply. Maarten ---------------------------------------------------------------------- Comment By: Borut Razem (borutr) Date: 2007-02-28 19:02 Message: Logged In: YES user_id=568035 Originator: NO My opinion is to unify the command line options as much as possible. So we should: - keep the --debug-(e)xtra option for pic16 and invert and rename the --no-gen-comments option for other targets or - keep the --no-gen-comments option and invert and rename the --debug-(e)xtra option for pic16 target In case that we chose the --debug-xtra I prefer to add the missing 'e' (--debug-extra). What about other targets: gbz80/z80/avr/pic14/TININative/xa51? Borut ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2007-02-28 10:24 Message: Logged In: YES user_id=589052 Originator: YES yes, I should not have closed the RFE. The pic and pic16 ports seemed to me to be using a different scheme (an "opt in" rather than an "opt out" option for debugging information). Option --debug-xtra would switch on extra information by setting port specific variables. (Nothing wrong with an opt in scheme, but it led me to the assumption the RFE would not apply to pic/pic16.) I implemented this RFE for the 'hc08 port. There is a macro DD() for even more detailed debug information within the 'hc08 port. Eventually make --debug-xtra a global option and couple with DD() ? (Note: the pic/pic16 option is documented as --debug-extra in the manual but the source uses the SMS'ed --debug-xtra) ---------------------------------------------------------------------- Comment By: Borut Razem (borutr) Date: 2007-02-28 07:36 Message: Logged In: YES user_id=568035 Originator: NO I reopened the RFE because it is only partially fixed. NOTE: sdcc does not generate the code only for msc51 and ds390 targets. We should care for the compatibility between all targets as much as possible. Borut ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2007-02-27 13:41 Message: Logged In: YES user_id=589052 Originator: YES implemented (for mcs51, ds390) in SDCC #4658. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1493816&group_id=599 |