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