CPU32 (was: cpu32 multilib patch)

[Robin Kirkham <Robin dot Kirkham at mlb dot dmt dot csiro dot au>]

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