CPU32 (was: cpu32 multilib patch) (fwd)

[Robin Kirkham]

On Mon,  6 Oct 97, Eric Norum writes:

> Joel Sherrill forwarded me your reply.   Thanks for such a detailed  
> proposal!

I've just sent a long reply to Joel and the egcs list. I'll try and keep
myself under control here... (also this is sent to egcs list).

> > 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.
> 
> Yes, but for the m68k-rtems target at least, the cpu32 is not part  
> of the MULTILIB_OPTIONS and MULTILIB_EXCEPTIONS.  I have a shell  
> script that massages the Makefile after the configure, but I'd rather  
> see the egcs distribution modified.

So would I.

> > 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)
> 
> I agree that it should be elevated to the status of a distinct CPU type.
> What do you mean by `it should be noted....'?  I can't see why the  
> compiler would care about the extra instructions since they're pretty  
> much `assembly-level-only'.

Yes. The aside was simply to strengthen the case a little...


> > 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__.
> 
> Here's where we part company  :-)

Not necessarily. I am prepared to be convinced otherwise on this point,
(but not just yet).


> I have two objections to this, one philosophical, one practical:
> 
> 1) The compiler produces code for a target *architecture*, not for
>    a bunch of attached peripherals.  The compiler options should
>    reflect this.
> ...
> For example, I think the CFLAGS for an embeddded processor should
> look something like:
>         CFLAGS = ......... -mcpu32 -Dm68360 ......
> or
>         CFLAGS = ......... -mcpu32 -Dm68340 ......

This is a valid point. Yes, the on-chip peripherals are irrelevent to the
compiler. The (say) -m68360 switches are for convenience of the programmer,
who can specify the precise chip type succinctly with one flag, and use a
dependable, compiler-generated cpp symbol (such as __m68360__) for chip
conditional code, or __cpu32__  in CPU conditionals. (I think an application
Makefile should never have CFLAGS defines of a __anything__).


> 2) The `specs' strings for the m68k are already ridiculously
>    complicated.  Adding a large number of additional options
>    would make them even more difficult to understand.

Well, I think this is a problem with the specs stuff, which I admit I never
understood really. But I think it's reasonably clear what has to happen.


>    Also, the compiler shouldn't need modifications each time
>    Motorola comes out with an embedded microprocessor having a
>    different set of peripherals.

There are a fair number in the family, and thus a fair number to go in. I think
that's just a symptom of gcc not having kept up in recent years. They aren't
coming out that fast really.


> > 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.
> 
> Yep, this gets back to my second point above.  GAS should have to know
> no more than `-mcpu32'.

Well, my other reason for suggesting all those -m switches is that gas (and
egcs) has already started down that route. If you eliminated the extant
-m68330, -m68331 etc switches, and got to the neat-and-tidy situation you
suggest, you will break extant Makefiles that invoke gas/gasp directly.
If you leave it as it is, in a sort-of half-done situation, I think people
might get confused about what chips are supported, even though they all are 
really.

Interestingly, the -mcpu32 flag is actually redundant, if all the -m683xx
flags are implemented...!! 8-(


> > 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.
> >
> 
> Well, agreement on 3 out of 4 isn't *too* bad......

As I say I'm prepared to be talked out of point 4. I'd like to hear some
other opinions...

 
> The required changes would seem to be:
> 
> - Add /mcpu32 to the MULTILIB_OPTIONS.
> - Remove the m68000=m68332 from MULTILIB_MATCHES
> - Add *mcpu32/*m68881 *mcpu32/*msoft-float to MULTILIB_EXCEPTIONS
> - Add MASK_68881 to the list of flags to turn off when -mcpu32 is
>   specified (around line 175 of gcc/config/m68k/m68k.h).
> - Change the CPP_SPEC string so that -mcpu32 defines  __mcpu32__,
>   __m68000__, __m68k__ (and the non __xxxx__ versions??) and does
>   not define __m68020__.
> - Change the ASM_SPEC string so that -mcpu32 passes the -mcpu32 on
>   to GAS.
> 
> I guess that -m68332 should be an alias for -mcpu32 except that it
> should also define __m68332__ (for compatability with old makefiles).

That's essentially what I had in mind...

Thanks for everyone's responses so far...

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