Re: CVS commit: src/sys/arch/x68k/stand/boot_ustar

[Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>]

mrg@ wrote:
> Martin Husemann writes:
> > On Tue, Apr 15, 2014 at 04:51:29PM +1000, matthew green wrote:
> > > hmmm this option is now called -march=68000.

I don't think this is correct.

> > > i don't think any
> > > x68k are 68000 are they?  all 020/030/040?  perhaps using
> > > -mcpu=m68020 here might be best?  i would test some and see if
> > > size or speed matters any.

In this case, it looks 68000 was intended to be supported.
(see below)

> > It doesn't really matter for .S files, as long as the code does not mutate
> > due to ifdefs - or am I missing something?

Probably as(1) might do some optimization or instruction replacement
per the specified processor (addressing, branch ranges etc). 

> i think it matters because as(1) might reject stuff otherwise,
> but i would imagine that the defaults for m68k are ok defaults
> for x68k port, so maybe this option going away is fine.

Here is my guess:

- NetBSD/x68k supports only X680x0 machines with MC68030 and higher
  processors.

- Normal X68000 machines (i.e. all X680x0 except X68030) have MC68000,
  so 030 accelerators are required for the X68000 models, i.e.
  XVI, SUPER, EXPERT, PRO, and ACE.

  (BTW the normal X68030 has MC68EC030 so users also have to replace
   its CPU to with MC68030 to use NetBSD/x68k)

- On the other hand, probably early x68k developers considered
  that some stupid users could try to boot NetBSD/x68k on X68000
  without 030 and bootloaders should have some sanity checks.

- All primary bootloaders except the boot_ustar have 020 checks:
  http://nxr.netbsd.org/xref/src/sys/arch/x68k/stand/boot_ufs/boot.S?r=1.10#65
  but the boot_ustar (for boot floppy) doesn't due to size restriction,
  so -mc68000 was intentionally specified for it:
  http://mail-index.netbsd.org/source-changes/2001/10/01/0037.html

- However, the secondary boot doesn't have proper 68000 check (yet?):
  http://nxr.netbsd.org/xref/src/sys/arch/x68k/stand/boot/srt0.S?r=1.2#60

Nowadays all (aged) X680x0 geeks know it won't work on normal X68000,
so probably it's safe to remove it.
(I'm not sure if -mc68000 actually emits different code though)


Note a possible change in gcc 4.8 that causes this trouble is:
http://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/m68k/m68k.c?annotate=173256#l482

I guess that gcc 4.5 passes only explicitly specified -m680x0
(which seems equivalent to -march=m680x0) options
(i.e. as(1) will use its default -mcpu), but gcc 4.8 always passes
both -march and -mcpu per the specified -m options to gcc(1)
("m68k_cpu_entry" is always set?) so passing only -Wa,-m[c]680x0
on gcc 4.8 makes as(1) complain arch vs cpu mismatch.

That's the reason why passing both -march=m68030 and -mcpu=m68030
solves build failure on mvme68k 060 kernels with both gcc 4.5 and 4.8.

In this boot_ustar case, passing only -Wa,-mcpu=m68000 fails with gcc 4.5,
and passing only -Wa,-march=m68000 (or -Wa,-m68030) fails with gcc 4.8.

---
Izumi Tsutsui