Re: CPU32 (was: cpu32 multilib patch)

Re: CPU32 (was: cpu32 multilib patch)

[Joel Sherrill]

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

Re: CPU32 (was: cpu32 multilib patch)

[Robin Kirkham]

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

Re: CPU32 (was: cpu32 multilib patch)

[Joel Sherrill]

On Tue, 7 Oct 1997, Robin Kirkham wrote:

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

OK.  Then in the interest of getting something done, let's ignore the
possibility that they might be different.  Ignoring this now does not
close the door on revisiting this once the cpu32 is out of the way.

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

No way to know at this point.

If the decision is made to go with all CPU model flags, then what Motorola
does with the core is not that critical.  Each model either does or does
not have FP.  -mcpu32 should imply no FP but CPU32 inside the machine e
description may not have to imply no FP.  Just a thought. (If it makes any
sense at all.)

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

I think this is right.  The __X__ constants must be right.

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

Whether it is critical or not can be a future issue.  Let's focus on
adding the model flags and multilib options in terms of what we have today
and getting them right.  Later we can distinguish betwen 68000 and the
ec000 is that is necessary/possible. 

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

Could be.  My point was that -mcpu32 is still important.  There will
always be a new model on the horizon.  There may be custom variants for
large customers which might never be explicitly supported by any compiler
but -mcpu32 would work.

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

Yes.  For now, the code generation issue should just focus on the -mMODEL
flags being right for as many models as possible.  This might require some
to be added to binutils as well.

I think we definitely need a cpu32 multilib version.  Personally, I can
not think of a technical reason to justify any others at this time.

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

Yep -- the cpu32 needs a multilib I should read ahead before I respond. 
:)

Ditto on the ec000.  Getting the model flags and multilib build right will
address a lot of problems.

Besides the coldfire core is probably the next issue looming on the
horizon for the m68k configuration.  :)

--joel

CPU32 (was: cpu32 multilib patch)

[Robin Kirkham]

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