Re: CPU32 (was: cpu32 multilib patch)

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

On Mon, 6 Oct 1997, Joel Sherrill wrote:
> On Mon, 6 Oct 1997, Robin Kirkham wrote:
> ...
> > 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.

True, although this is probably not relevent to egcs/gcc.


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

Motorola appears to make a distinction between a 68000 core and the EC000
core in its literature, and it says they are fully compatible with the MC68000.
gas also regards them as identical to the 68000.  I have no information on
instruction timings and so on, and I wouldn't want to hazard a guess.


> >    2. using -mcpu32 should not cause gcc to emit floating-point instructions
> So far none of the embedded 683xx's have FP, right?

I believe so, and I doubt they will. If one does, however, I imagine it would 
not have a CPU32 or EC000 core, but something else again. 


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

Yes, that's what I meant. The latter (e.g., a 68302) would define __m68302__
and __m68000__ (and __m68k__) etc.

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

As I say, they seem to distinguish between the 68000 and ec000 cores. It would
be nice if someone could tell us why :-)


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

There is one (can't remember the number) that is optimised for printer
applications; maybe this is it. 


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

There are I think two issues--one is the egcs/gcc cpu32 code generation issue
and the aliases for the cpu32 and 68000/ec000 "users", and the other is which
multilibs to build.

If the first gets addressed, then I agree there should be one additional
library set, for the cpu32, since the library code will be different from
the others. There is no need for a ec000 core set, as it will be identical to
the 68000 one, at least until someone changes the gcc code-generator to do so
and I think the code-generator-tinkerers have more interesting things to do!

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