> 	Chris D. has already said that mc68000 is not acceptable, m68k is
> 	the Moto general symbol. I would partially agree. mc68000 is NOT a

So, and I said m68k is bound to cause confusion in existing assembly sources.
Let him argue for his, let me argue for my religion.

> 	First, make is given the knowledge of what hardware and port it
> 	is on via internal variables. I think it IS more appropriate to
> 	handle this via the internal make variables than having some
> 	poorly named symbols, i.e. one's without __, hard coded in to
> 	a compiler.

If you're an ANSI purist not wanting any non-__ names defined by the compiler,
go for -ansi or -pedantic, and you won't get them.

> 	__m68k__, __amiga__, __amigados__ and __NetBSD__

Turn on -ansi, replace __m68k__ by __mc68000__, and you're there.

> 	the 020, 030, 040 or 060 then you damn well better be kernel
> 	related source or a sound thwap on the back of the hand is in order!
> 	The kernel has other mechnisms for the rev of CPU so a specific
> 	compiler define should be needed.

I agree here, partially. It would probably be handy to have some define for
the '40, so you can inhibit use of <math-68881.h> by default, if your code
is running on (your) '40 machine. The '40 will probably be faster if it links
with fpu emulation code, rather than using kernel fpu emulation.

> 	In the end, due to this being a religeous issue, we will end up
> 	with the worst possible combination of things and multiple
> 	NetBSD Amiga ports for the differing religeous views. B^(.

Hm, I don't see it that messy. I already said I expect to see around 99% of
all BSD-related programs to be completely cpu/machine-independant, so as long
as people stick to __NetBSD__, there's no problem at all.

-Markus
-- 
CHUUG/EUnet Switzerland				Markus Wild
Zweierstrasse 35	Tel: +41 1 291 45 80	mw@eunet.ch
CH-8004 Zuerich		Fax: +41 1 291 46 42	S=mw;P=EUnet;A=EUnet;C=CH

------------------------------------------------------------------------------