This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Patch to add extensions to asm_fprintf()


Hi Richard,

: > : I like it.  It would certainly make some of the ARM assembly code cleaner. 
: > :  But shouldn't we reserve some characters for the back end to use, rather 
: > : than making the whole remaining space a free-for-all?  If we don't then we 
: > : may have problems in the future if we wish to add a feature which is 
: > : common to all targets.
: > 
: > Hmm, good point.  Maybe we could reserve all uppercase letters for
: > generic extensions to asm_fprintf (since that seems to be the
: > convetion that the current extension use) and allow back ends to use
: > any other characters (apart from  %defgilopsuwx  which are already
: > used).
: 
: Something like that is what I had in mind, but it's not really my call.  
: You've also missed 'X' from the list of currently used chars.

'X' is upper case, so it is already forbidden to back ends.  [If we
implement the suggestion above].

: What about control character extensions?

Well in theory they could be used by back ends if they wanted to.

 
: On a style note, I think I'd prefer to see the macro take arguments
: rather than operating directly on variables in the function.  But
: thats personal taste.

No, I agree with you there.  There is a modified patch below.

: Also, since I believe that users would get access to these
: extensions (via "__asm"),

err how ?  asm() goes through to fprintf not asm_fprintf.  At least
that is what it looks to me upon examining final_scan_insn().

: don't the md-specific extensions need to be documented in the   
: same way as register constraint extensions are?

Well they ought to be documented regardless.  I supose the question is
where they should be documented.  If they are only accessible to the
internals of the target specific code then a comment in the sources
should be sufficient, but if they are, as you say, accessible to the
user-of-gcc then yes they ought to be documented in md.texi.

Cheers
	Nick

Thu Jul 15 15:37:36 1999  Nick Clifton  <nickc@cygnus.com>

	* final.c (asm_fprintf): Accept ASM_FPRINTF_EXTENSIONS, if
	defined.

	* tm.texi: Document ASM_FPRINTF_EXTENSIONS.

Index: final.c
===================================================================
RCS file: /egcs/carton/cvsfiles/egcs/gcc/final.c,v
retrieving revision 1.78
diff -p -r1.78 final.c
*** final.c	1999/06/21 23:22:35	1.78
--- final.c	1999/07/16 14:32:53
*************** asm_fprintf VPROTO((FILE *file, const ch
*** 3825,3830 ****
--- 3825,3844 ----
  	    fputs (user_label_prefix, file);
  	    break;
  
+ #ifdef ASM_FPRINTF_EXTENSIONS
+ 	    /* Upper case letters are reserved for general use by asm_fprintf
+ 	       and so are not available to target specific code.  In order to
+ 	       prevent the ASM_FPRINTF_EXTENSIONS macro from using them then,
+ 	       they are defined here.  As they get turned into real extensions
+ 	       to asm_fprintf they should be removed from this list.  */
+ 	  case 'A': case 'B': case 'C': case 'D': case 'E':
+ 	  case 'F': case 'G': case 'H': case 'J': case 'K':
+ 	  case 'M': case 'N': case 'P': case 'Q': case 'S':
+ 	  case 'T': case 'V': case 'W': case 'Y': case 'Z':
+ 	    break;
+ 	    
+ 	  ASM_FPRINTF_EXTENSIONS (file, argptr, p)
+ #endif
  	  default:
  	    abort ();
  	  }

Index: tm.texi
===================================================================
RCS file: /egcs/carton/cvsfiles/egcs/gcc/tm.texi,v
retrieving revision 1.78
diff -p -r1.78 tm.texi
*** tm.texi	1999/06/18 01:03:36	1.78
--- tm.texi	1999/07/16 14:32:33
*************** If defined, C string expressions to be u
*** 6236,6241 ****
--- 6236,6254 ----
  support multiple assembler formats.  In that case, the various @file{tm.h}
  files can define these macros differently.
  
+ @item ASM_FPRINTF_EXTENSIONS(@var{file}, @var{argptr}, @var{format})
+ @findex ASM_FPRINTF_EXTENSIONS
+ If defiend this macro should expand to a series of @code{case}
+ statements which will be parsed inside the @code{switch} statement of
+ the @code{asm_fprintf} function.  This allows targets to define extra
+ printf formats which may useful when generating their assembler
+ statements.  Noet that upper case letters are reserved for future
+ generic extensions to asm_fprintf, and so are not available to target
+ specific code.  The output file is given by the parameter @var{file}.
+ The varargs input pointer is @var{argptr} and the rest of the format
+ string, starting the character after the one that is being switched
+ upon, is pointed to by @var{format}.
+ 
  @findex ASSEMBLER_DIALECT
  @item ASSEMBLER_DIALECT
  If your target supports multiple dialects of assembler language (such as


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]