Why we are using -mcpu=5475 for the FireBee anyway?

[mikrosk]

I'm wondering whether there was some intention behind this. This FireBee uses the MCF5474 and the only difference to the MCF5475 is the Cryptography/Encryption Accelerator (which is most likely not used by gcc at all).

The -mcpu description explicitly mentions 5474 as one of its options so I'm wondering why we are using 5475.

@vinriviere perhaps you can remember your intention here? I remember you had been using -mcfv4e before that which got deprecated in favour of -mcpu=547x so I would understand 547x (as this is also a legal -mcpu option) but why 5475 ? I even found your original message: https://mikro.naprvyraz.sk/mint/200905/msg00117.html but I don't know how you deduced that it should be replaced by 5475.

P.S. Yeah I'm aware this perhaps makes zero difference, I'm just curious.

[vinriviere]

I remember that I built the official m68k-elf GCC, and noticed that the ColdFire V4e multilib directory was named m5475. So I did in m68k-atari-mint-gcc. This is the explanation for the multilib directory.

However, the GCC option to trigger ColdFire V4e compilation is unrelated. I may remember that, in some early FreeMINT Makefiles, the name of the option was deduced from the name of the multilib directory. I may be wrong, this is really long ago. In EmuTOS, there are 2 supported ColdFire Evaluation Boards: the M5484LITE (with a 5484) and the M5475EVB (with a 5475). I chose to compile with -mcpu=5475 there by default, because it was the best-looking default as it uses the same name as the multilib directory. Later, just to be more beautiful in the make log, and because I was glad about the flexibility allowed by the EmuTOS Makefile, I forced the firebee target compilation with mcpu=5474. Of course, this didn't change a single byte, but it looked more accurate when compiling.

Regarding to FreeMiNT, which is supposed to be machine-agnostic, and runnable on any ColdFire V4e machine, keeping -mcpu=5475 wasn't a bad choice. This is just a way to turn on ColdFire V4e compilation. On the other hand, one could argue that the only Atari-like machine is the FireBee, which uses a 5474. I don't have any strong feeling about that. Any V4e CPU option can do the job.

[vinriviere]

More precisely, I own 2 ColdFire machines:

• an M5484LITE evaluation board, using a ColdFire 5484 (V4e core)
• a FireBee, using a ColdFire 5474 (V4e core)

Both use the same CPU, a ColdFire V4e core. Remember that ColdFire is actually a microcontroller. Different references mean different embedded components, beyond the CPU.

As those machines share the same ColdFire V4e core, it was obvious to use a single multilib for both.

Extract of man gcc:

       -mcpu=cpu
           Generate code for a specific M680x0 or ColdFire processor.  The M680x0 cpus are: 68000, 68010, 68020, 68030, 68040, 68060,  68302,  68332  and  cpu32.   The
           ColdFire cpus are given by the table below, which also classifies the CPUs into families:

           Family : -mcpu arguments
...
           5475 : 5470 5471 5472 5473 5474 5475 547x 5480 5481 5482 5483 5484 5485

Here the family is called 5475, and include both 5484 and 5474. They share the V4e core.

Another consideration. Recent standard GCC 13 m68k-elf toolchain I built in July 2023:

$ ls -l /opt/cross-m68kelf/lib/gcc/m68k-elf/13.2.0/
total 604
-rw-r--r-- 1 vincent vincent   2220 Jul 29 01:01 crtbegin.o
-rw-r--r-- 1 vincent vincent   1240 Jul 29 01:01 crtend.o
drwxr-xr-x 1 vincent vincent      0 Jul 29 01:01 include
drwxr-xr-x 1 vincent vincent      0 Jul 29 00:19 include-fixed
drwxr-xr-x 1 vincent vincent      0 Jul 29 01:01 install-tools
-rw-r--r-- 1 vincent vincent 525118 Jul 29 01:01 libgcc.a
-rw-r--r-- 1 vincent vincent  72494 Jul 29 01:01 libgcov.a
drwxr-xr-x 1 vincent vincent      0 Jul 29 01:01 m51qe
drwxr-xr-x 1 vincent vincent      0 Jul 29 01:01 m5206
drwxr-xr-x 1 vincent vincent      0 Jul 29 01:01 m5206e
drwxr-xr-x 1 vincent vincent      0 Jul 29 01:01 m5208
drwxr-xr-x 1 vincent vincent      0 Jul 29 01:01 m5307
drwxr-xr-x 1 vincent vincent      0 Jul 29 01:01 m5329
drwxr-xr-x 1 vincent vincent      0 Jul 29 01:01 m5407
drwxr-xr-x 1 vincent vincent      0 Jul 29 01:01 m54455
drwxr-xr-x 1 vincent vincent      0 Jul 29 01:01 m5475
drwxr-xr-x 1 vincent vincent      0 Jul 29 01:01 m68000
drwxr-xr-x 1 vincent vincent      0 Jul 29 01:01 m68040
drwxr-xr-x 1 vincent vincent      0 Jul 29 01:01 m68060
drwxr-xr-x 1 vincent vincent      0 Jul 29 01:01 mcpu32
drwxr-xr-x 1 vincent vincent      0 Jul 29 01:01 mfidoa
drwxr-xr-x 1 vincent vincent      0 Jul 29 01:01 softfp

We can see that here, the representative of the V4e family is the m5475 multilib.

Equivalence is defined here: https://github.com/freemint/m68k-atari-mint-gcc/blob/0e0cacb8c8f25f6a7fc35063b72a2403f21137c4/gcc/config/m68k/t-mlibs#L86-L99

So inside GCC sources, 5475 is the representative of the whole V4e family. I just used that reference to target both my 5484 and 5474 CPUs. And to trigger that multilib, when -mcfv4e was deprecated, I simply used -mcpu=5475. Of course I could have chosen any other reference of the same family, it would produce the very same binaries.

This is why FreeMiNT and all other software use -mcpu=5475 to build ColdFire binaries, suitable for any ColdFire V4e variant. Only exception is EmuTOS binary for the FireBee which is built using -mcpu=5474. But that's pure fantasy from mine: as EmuTOS is built specifically for the FireBee, I was happy to use its specific CPU option. It's pretty when looking at the build log. Even if I know very well that 5475 would give the very same result.

That's the whole story. No mystery.

[mikrosk]

I think this detailed explanation deserves a "resolved" status. ;) Thanks!