This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
[patch] arch-status.html: New. (Take 6)
- From: Kazu Hirata <kazu at cs dot umass dot edu>
- To: gcc-patches at gcc dot gnu dot org
- Date: Thu, 02 Oct 2003 16:23:14 -0400 (EDT)
- Subject: [patch] arch-status.html: New. (Take 6)
Hi,
Here is a take 6 in html. I renamed the file to backends.html, picked
style.mhtml as a parent, and revised the intro as suggested by Janis.
I also incorporated the suggestion from H-P about the desirable/common
issue.
I flipped most of the characteristics so that the table would be least
dense. One ugly thing is that L is flipped, whereas Q is not.
This time I attached a patch instead of including it within the
message. Hopefully, it works.
Kazu Hirata
Index: style.mhtml
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/style.mhtml,v
retrieving revision 1.65
diff -u -r1.65 style.mhtml
--- style.mhtml 17 Aug 2003 22:59:18 -0000 1.65
+++ style.mhtml 2 Oct 2003 19:18:55 -0000
@@ -219,7 +219,8 @@
<a href="<get-var BACKPATH>contributewhy.html">...Why?</a><br />
<a href="<get-var BACKPATH>projects/">Open projects</a><br />
<a href="<get-var BACKPATH>frontends.html">Front ends</a><br />
+ <a href="<get-var BACKPATH>backends.html">Back ends</a><br />
<a href="<get-var BACKPATH>extensions.html">Extensions</a><br />
<a href="<get-var BACKPATH>cvs.html">CVS read access</a><br />
<a href="<get-var BACKPATH>rsync.html">Rsync read access</a><br />
--- /dev/null 2003-01-30 05:24:37.000000000 -0500
+++ backends.html 2003-10-02 16:16:11.000000000 -0400
@@ -0,0 +1,115 @@
+<html>
+
+<head>
+<title>Status of Supported Architectures from Maintainers' Point of View</title>
+</head>
+
+<body>
+<h1>Status of Supported Architectures from Maintainers' Point of View</h1>
+
+<p>The table below shows various characteristics for all architectures
+supported by GCC. It can be used to determine an appropriate variety
+of targets on which to test patches, and is also used by GCC
+maintainers to track of criteria that are considered when determining
+which targets to obsolete.</p>
+
+<p>Each characteristic has a unique letter. Characteristics
+describing fundamental properties of the architecture or target use
+uppercase letters, and characteristics describing properties of the
+GCC port to that architecture use lowercase letters. The appearance
+of a letter means that the architecture has that characteristic, a
+blank means it does not, and a question mark means the author didn't
+know whether the architecture had the characteristic or not. For
+criteria used to determine whether an architecture should be
+obsoleted, the appearance of a letter is the common case and the lack
+of a letter is the less common case.</p>
+
+<p>Architectures are identified by the names of their subdirectories
+in gcc/config, not by the CPU fields that config.guess reports.</p>
+
+<pre>
+Architecture characteristic key
+-----------------------------------------------------------------------
+H A hardware implementation does not exist.
+M A hardware implementation is not currently being manufactured.
+S A Free simulator does not exist.
+L Integer registers are narrower than 32 bits.
+Q Integer registers are at least 64 bits wide.
+N Memory is not byte addressable, and/or bytes are not eight bits.
+F Floating point arithmetic is not supported
+ (not necessarily by all implementations)
+I IEEE floating point is not supported
+ (possibly with software assistance for full conformance)
+C Architecture does not have a single condition code register.
+B Architecture has delay slots.
+D Architecture has a stack that grows upward.
+
+l Port cannot use ILP32 mode integer arithmetic.
+q Port can use LP64 mode integer arithmetic.
+r Port can switch between ILP32 and LP64 at runtime.
+ (Not necessarily supported by all subtargets.)
+c Port uses cc0.
+p Port does not use define_peephole.
+f Port does not define prologue and/or epilogue RTL expanders.
+g Port does not define TARGET_ASM_FUNCTION_(PRO|EPI)LOGUE.
+m Port does not use define_constants.
+b Port does not use '"* ..."' notation for output template code.
+d Port uses DFA scheduler descriptions.
+h Port contains old scheduler descriptions.
+a Port generates multiple inheritance thunks using
+ TARGET_ASM_OUTPUT_MI(_VCALL)_THUNK.
+t All insns either produce exactly one assembly instruction, or
+ trigger a define_split.
+e <arch>-elf is not a supported target.
+s <arch>-elf is the correct target to use with the simulator
+ in /cvs/src.
+</pre>
+
+<pre>
+ | Characteristics
+Target | HMSLQNFICBD lqrcpfgmbdhates
+---------+----------------------------
+alpha | ?? Q C q p g bd a e
+arc | ??? FI B pf m h
+arm | d a s
+avr | L FI l c f m
+c4x | ?? N I BD g h te
+cris | S F B c f m a
+d30v | ?? FIC p m h s
+dsp16xx | ???L NFI D l c f m h e
+fr30 | ?? FI B gm t s
+frv | ?? B p d a s
+h8300 | FI cp s
+i370 | M? I D cpf m e
+i386 | ? Q q p dha
+i860 | M? cpf e
+i960 | M D f m ha e
+ia64 | ? Q C qr p d a
+ip2k | ???L FI l c f mb
+iq2000 | ??? FICB p g h t
+m32r | ?? FI m h s
+m68hc11 | L FI l c t s
+m68k | ? c f a
+mcore | ? FI gm h s
+mips | Q CB qr bdh s
+mmix | HM Q C q p b a e
+mn10300 | ?? c g s
+ns32k | M? c f m e
+pa | ? Q CBD qr m d a e
+pdp11 | L I rcpf m e
+rs6000 | Q qr d a
+s390 | ? Q qr p g bdha e
+sh | Q CB qr dha
+sparc | Q CB qr bd a
+stormy16 | ???L FIC D l p m at
+v850 | ?? FI cp gm h s
+vax | M? I cp a e
+xtensa | ? C p b h
+</pre>
+
+<p>For AVR simulator, see <a
+href="http://gcc.gnu.org/ml/gcc/2003-10/msg00027.html";>
+http://gcc.gnu.org/ml/gcc/2003-10/msg00027.html</a>.</p>
+
+</body>
+</html>