Menu
▾
▴
[sdcc-devel] [ sdcc-Feature Requests-1493816 ] option --no-gen-comments
|
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 |