Re: CPU32 (was: cpu32 multilib patch) (fwd)

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

Re: CPU32 (was: cpu32 multilib patch) (fwd)

[Mark Phillips]

Sorry I'm not sure who wrote the text that I'm commenting on (can't
figure it out from the quotes so I've dropped all the surrounding text to 
make this email smaller).

Just a quick comment/correction:-

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

Actually the 68360 is NOT a CPU32 it is a CPU32P, it is very similar to
the straight CPU32, but has several differences:-

Can access data with any alignment.
Supports wider memory (32 bit data bus).
Has different instruction timings.

Personally it is MUCH more important to me that the code works than it is
ultra fast, but there are clearly optimisations which could be performed
for access to unaligned data (maybe packed structures).

I am currently using gcc 2.7.2.2 with the configuration hacked (enhanced?)
to generate ELF/DWARF with -mcpu32 being added to gcc to pass -m68020
-mnobitfield to cc1 and -mcpu32 to gas (also -msoft-float causes
-mno-68881 to be passed to gas).

I would much prefer it if gcc supported a -mcpu32 (and maybe -mcpu32p), in
my opinion the optimisations which could be performed for the different
variants and NOT worth it. If you do support them, the resulting user base
for each config becomes much smaller and therefore the stability of gcc for
the end user reduces (this is why I choose to hack gcc 2.7.2.2 to do
-m68020 -mnobitfields - I trust the 68020 code generation because of its
large amount of use on old sun3 boxes).

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

I tend to think there will continue to be lots of new 68series chips,
but few significant (if any) variants to the core - therefore I lean
towards just specifiying the core not the actual chip.


Keep up the good work!

Cheers
Mark