From: Robin Kirkham <Robin.Kirkham@mlb.dmt.csiro.au>
To: egcs@cygnus.com
Cc: joel@OARcorp.com
Subject: CPU32 (was: cpu32 multilib patch)
Date: Mon, 06 Oct 1997 01:07:00 -0000 [thread overview]
Message-ID: <19971006080645.10491.qmail@ragnarok.mlb.dmt.csiro.au> (raw)
On Fri, 3 Oct 1997 12:38:57 -0500 (CDT), Joel Sherrill (joel@OARcorp.com) said:
> A few rtems users have been testing a tree I put together using the 970904
> snapshot. One of them (Eric Norum) has suggested that cpu32 be a multilib
> option for the m68k. I think he is right. There is no real good set of
> libraries which are optimized for cpu32. "m68020 nobitfield" means the
> m68020 libraries could have bitfield instructions and the 68000 ones are
> not optimized for the architecture.
> ...
> [From Eric Norum]
> ...
> b) I think it would be clearer to have a `-mcpu32' flag to gcc instead of
> (or as well as) `-m68332'. The CPU32 covers a family of embedded
> microprocessors of which the 68332 is a single member. GAS already
> supports the -mcpu32 flag.
>
> Specifying -mcpu32 should:
> Set cpu options to -m68020 -mno-bitfield -msoft-float, just like
> the -m68332 option does now.
> Define preprocessor macros mcpu32 and __mcpu32__.
> Pass the -mcpu32 flag on to GAS.
I think this an egcs/gcc issue and not really an RTEMS one.
egcs (but not gcc 2.7) already has a -mcpu32 flag, and I have used it to build
CPU32 multilibs by altering MULTILIB_OPTIONS and MULTILIB_EXCEPTIONS.
It does pass -mcpu32 to gas. Unfortunately, specifying just -mcpu32 does
not imply -msoft-float, so the libraries ended up having 68881 floating-point
instructions in them.
The CPU32 can never be used with a 68881, so I think this is incorrect
behaviour on the part of the compiler. Further, I think specifying
-mcpu32 -m68881 should report an error.
While I think the -mcpu32 flag is the way to go, the -m68332 flag (which is
I think correct) is also useful. The various 683xx processors have different
on-chip peripherals and it is thus useful to be able to have conditional on
these variants. There are quite a number of 683xx's now, and by rights each
one should have its own -m flag. Here is (I hope) a complete list:
68000/EC000 core: 68302 68306 68307 68322 68356
CPU32 core: 68330 68331 68332 68333 68334
68336 68340 68341 68349 68360
In other words, I believe:
1. the CPU32 should be given the status of a distinct CPU type (it should
also be noted that it has instructions that the 68020 does not have)
2. using -mcpu32 should not cause gcc to emit floating-point instructions
3. using -mcpu32 should define __mcpu32__ (etc) and NOT __m68020__.
(Probably it would also define __m68000__ and __m68k__).
4. The various 683xx's should be "aliases" for -mcpu32, so using, for
instance, -m68360 would generate code for a CPU32, and define both
__mcpu32__ and __m68360__.
The above would bring gcc more or less in to line with gas 2.8.1, which treats
the 683xx's as aliases for either a 68000 or a cpu32 as appropriate. gas
however only recognises the 68302, 330, 331, 332, 333, 340 and 360 (and cpu32),
so a patch to gas to add the others would also be needed.
Alternatively, gcc could pass just -mcpu32 to gas, which avoids changing gas.
If there is a consensus that this is the right way to do it in gcc/egcs, I
will try and create a patch, unless someone more skilled than I would like
to do it. I think it requires alteration of gcc/config/m68k/m68k.[ch] and
gcc/config/m68k/t-m68kbare and perhaps other files.
[Please respond to me directly, as I don't receive egcs-list]
Robin Kirkham CSIRO Manufacturing Science and Technology
Project Engineer Locked Bag 9, Preston 3072, Australia
robin.kirkham@mlb.dmt.csiro.au Phone: +61 3 9662-7756 Fax: +61 3 9662-7851
next reply other threads:[~1997-10-06 1:07 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
1997-10-06 1:07 Robin Kirkham [this message]
[not found] <19971006080645.10493.qmail@ragnarok.mlb.dmt.csiro.au>
1997-10-06 7:08 ` Joel Sherrill
1997-10-06 9:03 ` Robin Kirkham
1997-10-07 5:30 ` Joel Sherrill
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=19971006080645.10491.qmail@ragnarok.mlb.dmt.csiro.au \
--to=robin.kirkham@mlb.dmt.csiro.au \
--cc=egcs@cygnus.com \
--cc=joel@OARcorp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).