Re: CPU32 (was: cpu32 multilib patch)

[Joel Sherrill <joel at OARcorp dot com>]

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