Re: CPU32 (was: cpu32 multilib patch)

[Joel Sherrill <joel@OARcorp.com>]

On Mon, 6 Oct 1997, Robin Kirkham wrote:


> I think this an egcs/gcc issue and not really an RTEMS one.

I agree 100%.  I just act as a conduit for gripes/patches/suggestions. :)

> 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.

This is unfortunate and I would consider it a bug.

> 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.

This is reasonable.

> 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:

The PPC 8xx series seems to share some of the same peripherals.  The 860
and 360 both have the QUICC for example.

> 	68000/EC000 core:	68302	68306	68307	68322	68356
> 
> 	CPU32 core:		68330	68331	68332	68333	68334
> 				68336	68340	68341	68349	68360

Is the 68000 embedded core different from the vanilla 68000 one?  I know
it is instruction set compatible.  I was thinking more along the lines of
instruction timing.  There may be different optimization tradeoffs.

>    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)

Yes.  This is a good idea.

>    2. using -mcpu32 should not cause gcc to emit floating-point instructions

So far none of the embedded 683xx's have FP, right?

>    3. using -mcpu32 should define __mcpu32__ (etc) and NOT __m68020__.
>       (Probably it would also define __m68000__ and __m68k__).

This would get the defines correct from a compatibility standpoint.

>    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__. 

Only the ones which have a CPU32 core -- not the embedded 68000 core.

> 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.

This is OK except for the embedded 68000 cores.  It might be nice to have
a generic name for this core like cpu32.  Is 68ec000 the Motorola name?

Thinking ahead Motorola will continue to introduce weird variants in this
family.  There need to be generic names while indicate the cores so odd
variants don't necessarily have to be added.  I think Mototrola will
produce custom versions of these if the volume/money is right.  I seem to
recall reading that the Canon bubble jet printers had a custom version of
a 68xxx.  Did this model ever go public? 

> 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.

I think this approach is correct.  I don't think there should be a LOT of
new multilib options added -- only the cpu32 and maybe the 68ec000 core.
Increasing the number of multilib options must be taken seriously as it
impacts build time and space as well as installed size.

> [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

--joel
Joel Sherrill                    Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (205) 722-9985