This is the mail archive of the
mailing list for the GCC project.
Re: Proposed targets to deprecate for 3.4
- From: "Zack Weinberg" <zack at codesourcery dot com>
- To: neroden at twcny dot rr dot com (Nathanael Nerode)
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 30 Sep 2003 13:11:18 -0700
- Subject: Re: Proposed targets to deprecate for 3.4
- References: <20030930114232.GA5344@twcny.rr.com>
Nathanael, are you interested in coordinating the development of the
obsoleted targets list for this cycle? I'll be quite happy to let you
do it. ;-)
(Note preferred terminology - "obsoleted" not "deprecated")
You might find this chart of interest. I was meaning to follow it up
with a similar chart of properties for individual targets but I ran
out of spare time.
--- arch-obs-criteria.txt ---
I've begun to compile a giant table of criteria for deciding whether
or not any given architecture should be preserved. The table lists
desirable characteristics for all architectures supported by gcc.
Each characteristic has a unique letter. In all cases, a letter
appearing is the desirable case; no letter is the undesirable case;
and a question mark means I don't know whether the architecture has
the characteristic or not.
Characteristics describing fundamental properties of the architecture
or target use CAPITAL LETTERS; characteristics describing properties
of the GCC port to that architecture or target use small letters.
Yes, many of these things are quite trivial.
Architectures are identified by their gcc/config subdirectory, *not*
their CPU field in config.guess output.
Architecture characteristic key
H A hardware implementation exists.
M A hardware implementation is currently being manufactured.
S A Free simulator exists.
L Integer registers are at least 32 bits wide.
Q Integer registers are at least 64 bits wide.
N Memory is byte addressable and bytes are eight bits.
F Floating point arithmetic is supported
(not necessarily by all implementations)
I IEEE floating point is supported
(possibly with software assistance for full conformance)
C Architecture does not have a single condition code register.
B Architecture does not have delay slots.
D Architecture has a stack that grows downward.
l Port can 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 does not use cc0.
p Port does not use define_peephole.
f Port defines prologue and/or epilogue RTL expanders.
g Port does not define TARGET_ASM_FUNCTION_(PRO|EPI)LOGUE.
m Port uses define_constants.
b Port does not use '"* ..."' notation for output template code.
d Port uses DFA scheduler descriptions.
h Port does not contain old scheduler descriptions.
a Port generates multiple inheritance thunks using
t All insns either produce exactly one assembly instruction, or
trigger a define_split.
e <arch>-elf is a supported target.
s <arch>-elf is the correct target to use with the simulator
Target | HMSLQNFICBD lqrcpfgmbdhates
alpha | H??LQNFICBD lq cpfgmbdha
arc | ???L N D l cp e
arm | HMSL NFI BD l c f m dha es
avr | H?? N BD h e
c4x | H??L F l c fgm t
cris | ???L N D l ha e
d30v | ??SL N CBD l cpf es
dsp16xx | ??? B
fr30 | ??SL N D l c fg h tes
frv | ??SL NFI D l cpf m dha es
h8300 | ??SL N BD l pf m h e
i370 | H ?L NF B l p h
i386 | HM?LQNFI BD lq cpf m d a e
i860 | H ?L NFI BD l p m h
i960 | H SL NFI B l c a
ia64 | HM?LQNFICBD lqrcpf m dha e
ip2k | ??? N BD b h e
iq2000 | ???L N C D l cpfgm te
m32r | ??SL N BD l c f es
m68hc11 | ??S N BD f m h tes
m68k | HM?L NFI BD l m ha e
mcore | H?SL N BD l c fg es
mips | HMSLQNFIC D lqrc f mbd es
mmix | SLQNFICBD lq cpf mb ha
mn10300 | ??SL NFI BD l fgm h es
ns32k | H ?L NFI BD l h
pa | HM?LQNFIC lqrc f dha
pdp11 | H ? NF BD p h
rs6000 | HMSLQNFI BD lqrc f m dha e
s390 | HM?LQNFI BD lqrcpfgmbd a
sh | HMSLQNFIC D lqrc f m d a e
sparc | HMSLQNFI D lqrc f mbdha e
stormy16 | ??? N CB cpf hate
v850 | ??SL N BD l pfg es
vax | H ?L NF BD l pf m ha
xtensa | HM?L NFICBD l cpf mb e