> I'm ready to start implementing 060 support in my NetBSD-current kernel. I
> would like all interested/involved parties to comment on the following:

I wasn't aware that there are any 060 boards, you have one?  I'll
assume so and comment on the rest of your things..  If you don't
then this is silly.  Writing code for a CPU that you don't have to
test on is counter-productive.

> 1) The state of locore.s and amiga_init.c is somewhat messy. I'm not calling
>    it bad or anything, just messy. I would like to make a real clean-up of
>    those two files, perhaps splitting them into 020, 030, 040, 060, 881, 851
>    specific files. This will allow clearer code and, in the case of the
>    assembler files, cpu specific commands to be written as mnemonics rather
>    than .word statements.

There is no way that I am going to split amiga_init.c into 6 files.
Thats just ridiculous.  I don't find amiga_init.c all that messy
as a matter of fact it has been cleaned up on more than one occasion.
If the 060 is different enough from the 040 then we will just add
another if statment.  If the if statment proves to messy then
another function[s] can be written and will reside in amiga_init.c

I think perhaps you maybe overwhelmed by the complexity of what is
going on in amiga_init and you are attempting to simplify it by splitting
the file.  Thats not going to make it any less complex.  Its a good
idea to invoke picture mode when dealing with this file.

> 2) The 060 support package from Motorola can't "coexist" with the fpsp for
>    the 040. This has to be dealt with! My suggestion is that stubs are added
>    to locore.s and a cpu-specific init function setup these stubs to point
>    to cpu-specific functions. This will actually gain an ounce of speed.
>    (I admit it won't be noticable) The stubs will also help in places like
>    cache control and maybe even vm/pmap handling.

I am not sure that your statement about "coexistence" is true.  I
can't think of any reason they wouldn't.  Perhaps you could elaborate
on what the conflict is.

> 3) The 060 has to have it's page-descriptors in non-cacheable ram as it won't
>    use the cache memory during table searches. This has to be dealt with too.
>    The p-d may lie in cacheable memory IF it is write-through, not copy-back.

I assume you haven't looked at the pmap then.  The 040 code already cache-
inhibits page descriptor pages.

> 
> 4) What is the state of gas/gcc/g++? Does it support the 060 at all or do I
>    have to add 060 support there too?

Define "support".  The 060 is reportedly fully compatible with the
040 in user mode.  Gcc doesn't deal with anything but user mode.
Of course some enhancments can be made with gcc to avoid the slower
060 opcodes (slower also == emulated)  But thats not important as
that won't be used to create binary sets.  As far as gas, I don't
support the idea of splitting locore.s so you'll need to use .word's
for anything thats different (I suspect very little is in any case).

You seem to think there is a large difference between the 040 and the
060.  I wasn't aware that there was, but I hvaen't paid to much attention
either.  Perhaps you could specifically point out the areas of difference
then, I think, we could all make more informed comments.

Chris.