This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Patch to add extensions to asm_fprintf()
- To: richard dot earnshaw at arm dot com
- Subject: Re: Patch to add extensions to asm_fprintf()
- From: Nick Clifton <nickc at cygnus dot com>
- Date: Fri, 16 Jul 1999 15:33:31 +0100
- CC: egcs-patches at egcs dot cygnus dot com
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