>> 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.
On the contrary, the 060 lacks some floating-point instructions and has to
have some addressing-modes done in software, further 64-bit mul/div doesn't
exist as instructions either and has to be emulated. I don't know how
many of these that the kernel does have in it, but I'd rather have a working
040 system with shaky 060 support WHEN MY CARD COMES (I haven't got it yet)
so that I can atleast bootstrap the system.

>> 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.
You're right there. When I wrote my first mail, I hadn't looked into locore.s
and amiga_init.c in depth. I had made a browse, well, more than a browse 
actually, and on first sight, It's a mess. Now I can almost find myself at
home in them. :-)

>> 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.
The 040 and 060 generates diffrent exception-frames, and the 060 has to
emulate more functions + some unimplemented addressing modes (I think it's
immediate source and fmovem with multiple registers or some such). I haven't
looked deeply into this either. The fpsp.s for the 060 is ONE 730Kb file and
that take a while to browse through... It may be that the fpsp that exists
in the current tree can be modified to support the 060 too. That would
be preferable.

>> 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.
No I hadn't. And that's great since nothing has to be done then. (I hope)

>> 
>> 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).
With support I ment: "Does gas have the 060 mnemonics? Does gcc/g++ avoid the
unimplemented functions in the 060?" What else could I mean? In the 060sp
there is a ilsp (unimplemented instructions library). Perhaps one could use
that + a slightly modified gas. This is not a serious suggestion, just a 
thought.

> 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.
OK, Here follows from the M68060UM/AD:
* The 060 is 100% USER MODE compatible with the 040, WHEN utilized with the
  M68060SP.
* The 060 only has one supervisor stack, the 040 has two.
* The 060 has a new Processor Configuration Register for movec (No problem)
* Quote from 11.1.2.1.3: "MC68060 Software Package (M68060SP) The M68060SP
  replaces the installation of the MC68040 floating-point software package
  (M68040FPSP). Software that was used to install the M68040FPSP must be
  removed and then replaced with software that installs the M68060SP. Be
  aware that the M68060SP and the 68040FPSP share many vector table entries
  and that the M68040FPSP does not work properly with the MC68060.

  The M68060SP must be installed before any of the new unimplemented
  instructions and unimplemented effective addresses are encountered."
  Reservation for typos.
* The 060 must have it's branch-cache cleared prior to use
* The TCR register has new bits in the 060. (No problem, set them to 0)
* The 060 must have it's page descriptors in non-cachable memory
* The Access Error exception generates diffrent exception-frames, and the
  handling of the exception is very diffrent from the 040s.
* PTEST is not implemented in the 060
* MOVEC of MMUSR in not implemented in the 060
* New instruction PLPA added to compensate for the above.
* Branch-cache must be flushed at context-switching.
* Cache-mode encoding is diffrent in the TTRs.
* Unimplemented instructions:
  DIVU.L  <ea>,Dr:Dq
  DIVS.L  <ea>,Dr>Dq
  MULU.L  <ea>,Dr:Dq
  MULS.L  <ea>,Dr>Dq
  MOVEP   Dx,(d16,Ay)
  MOVEP   (d16,Ay),Dx
  CHK2    <ea>,Rn
  CMP2    <ea>,Rn
  CAS2    Dc1:Dc2,Du1:du2,(Rn1):(Rn2)
  CAS     Dc,Du,<ea>
* Unimplemented floating-point instructions:
  FACOS, FASIN, FATAN, FATANH, FCOS, FCOSH, FETOX, FETOXM1, FGETEXP, FGETMAN
  FLOG10, FLOGN, FLOGNP1, FMOVECR, FSIN, FSINCOS, FSINH, FTAN, FTANH, FTENTOX
  FTWOTOX, FLOG2
  FMOD, FSCALE, FREM
  FTRAPcc, FScc, FDBcc
  FMOVEM.X (dynamic register list)
  F<op>.X  #immediate,FPn
  FMOVEM.L #immediate of 2 or 3 control regs
  F<op>.P  #immediate,FPn
* The 040FPSP uses only _mem_{read,write}. The 060SP uses
  _imem_read_{word,long} and _dmem_{read,write}_{byte,word,long}
* Some (stupid) instructions are not recomended. (Using operands below the
  supervisor stack -(ssp) and such)

That should cover the most. The info was retrived from chapter 11 and appendix
C.

/Daniel Widenfalk
t94dwi@student.tdb.uu.se