What's missing from the 68060?

[coldacid]

I keep hearing tell that the 68060 is missing certain operations that were present on earlier members of the m68k family, but never any specifics about it. I've heard plenty about the '10 and onwards making MOVE from SR privileged, but that's about the extent of "lost" or otherwise changed ops that I've seen for the whole family.


Could someone explain what's actually missing, or at least point me in the right direction? Thanks.

[StingRay]

Check the 68060 User Manual (appendix C).

[coldacid]

Okay, so if I'm understanding this correctly, it's not that the ops (and related opcodes) have been removed in every case, but that a bunch of ops are thrown to software instead. There's nothing that would prevent, say, a 68065 with all those ops implemented in silicon again, if for example someone wanted to produce such a chip (either real or emulated).

[coldacid]

And now I have a list of ops that are strictly nonexistent on the '60 while implemented on older 68k processors, for which I still want to determine why.

• CALLM
• cpBcc
• cpDBcc
• cpGEN
• cpRESTORE
• cpSAVE
• cpScc
• cpTRAPcc
• MOVEP
• PFLUSHA
• PLOAD
• PMOVE
• PTEST
• RTM

Of these, only MOVEP has been around since the original 68000, continuing through the '40 but not in the '60. CALLM and RTM were only in the '20, and PFLUSHA, PLOAD, and PMOVE were only in the '30 (as well as in the 68851 MMU). PTEST was on the '30 and also the '40. There's a whole bunch of '851-exclusive ops as well. All the cp* ops were in the '20 and '30, but not the '40 or '60.

The journey continues...

[Toni Wilen]

cpXXX are gone because 68040 and 68060 does not have external co-processor interface. Only 68020 and 68030 had it. But it does not make much difference because they return exception if selected co-processor ID does not exist. 68040+ simply always return exception (if ID is not built-in FPU or model does not have FPU)

PLOAD etc are gone because 68040/68060 introduced new (much less complex) MMU instructions. 68040 PTEST (Actually PTESTR or PTESTW) is different opcode than 68030/68851 PTEST.

I am not sure about CALLM and RTM but they appear to be really weird instructions that required weird hardware support. Probably never actually used..

[AmigaHope]

On the FPU end pretty much all the complex transcendental operations have been removed (e.g. trig functions). This change was made on the 040. The 040/060 FPU is a much simpler beast, which was needed in order to fit it on the same die as the integer CPU. On the other hand it's so much faster thanks to this that it doesn't hurt to lose them, since you can do those operations in software.

[coldacid]

Toni: Thanks for the details. Have to agree about CALLM/RETM, I doubt they were ever used in anything other than special hardware rather than general purpose computers.

AmigaHope: I never really focused on the FPU-only instructions in this, other than noting that some were moved to software essentially via interrupt. But I could see a modern smorgasbord FPGA '065 could include anything FPU-only in the chip, along with moving the software-reimplemented ops back into the chip.

[meynaf]

The most important miss on '060 is IMO the 64-bit MUL & DIV operations. These ARE useful. They really shouldn't have removed them.

[coldacid]

meynaf: If I was doing an FPGA reimplementation of the '060's instruction set, those would DEFINITELY be moved back on-chip. (I mean, all the stuff that was pushed off to software implementation would be put back in the chip firmware, but those would be top priority.)

[meynaf]

Originally Posted by coldacid

meynaf: If I was doing an FPGA reimplementation of the '060's instruction set, those would DEFINITELY be moved back on-chip. (I mean, all the stuff that was pushed off to software implementation would be put back in the chip firmware, but those would be top priority.)

Too bad you're not actually doing it

I would probably not ask for CMP2,CHK2,CAS2 to be put back to silicon but i would for MOVEP because of compatibility issues.

[Thomas Richter]

Originally Posted by coldacid

And now I have a list of ops that are strictly nonexistent on the '60 while implemented on older 68k processors, for which I still want to determine why.

The list is not complete, and there are two types of non-implemented instructions. Those that are not supported at all, and those for which the 68060 runs into a software trap which is then emulated in software. Also, your list is not complete.


CALLM and RTM do not make sense on the 68060. They require a 65881 (the MMU that came with the 68020). These two instructions allow a fine-grained priviledge control over multiple modules or layers of an operating system where a CALLM into another module is only possible if its priviledge is lower than the current priviledge, as otherwise an exception is generated and the Os needs to check whether the calling process is allowed to gain such priviledges. It is a finer grained control than that of the pure user/supervisor model has to offer, but it requires the MMU to indicate which pages belong to which ring.


cpXXX instructions are not individual instructions, but groups of instructions that are specific to a particular coprocessor. The corresponding versions for the FPU exist on the 68060 of course. Thus, FBNE (floating point branch if not equal) is a form of the cpBcc instruction, and that exists, of course. The 68030 had similar forms for its internal MMU, though those had been replaced by a different instruction set. The mmu.library keeps care of this different abstraction.


MOVEP is an instruction that is not implemented, but emulated by the 68060.library and used to read bytes from a 16-bit port. It is particularly bound to the 16-bit wide processor interface of the 68000, and as such makes less sense on the 68060 which has a 32-bit bus. It already made less sense for the 68020 and 68030 which had a scalable bus, but was implemented there. Unfortunately, some Amiga firmware such as for the ALF SCSI hardware uses MOVEP, and thus causes trouble on the 68060 unless there is some firmware that exists prior the 68060.library to emulate it. P5 boards come with some early integer emulation functions.


PFLUSHA is an MMU instruction that also exists on the 68060, but has a different encoding on the 68030. The encoding is shared with the 68040. The instruction itself exists, so it should not be part of the list.


PMOVE loads MMU registers on the 68030 and 68851. It was replaced by the MOVEC instruction which loads generic "supervisor control registers". Thus, it exists in some form, but in a different encoding. Again, the 68060 shares the encoding with the 68040.


PTEST exists with a different encoding on the 68040 than the version on the 68030 and 68851, the 68060 does not have it, and it is not emulated. It is a MMU instruction. But one can easily implement something similar by a short subroutine. It reads a MMU descriptor. The mmu.library takes care of this and offers a function for it.


A couple of instructions that are not on your list:


MULU,MULS, DIVU,DIVS do not exist in the variants that either generate or require a 64 bit argument. The 68040, 68030 and 68020 offered these, the 68060 does not. Unlike the former processors, the 68060 is not (mostly) microcode-driven and implements many instructions on bare silicon level. 64 bit support would have required a more complex ALU which would have been rarely used, and thus this was moved out into a software emulation layer. The 68060.library takes care of emulating these instructions as the CPU itself triggers an unimplemented integer instruction trap.


CHK2 does not exist on the 68060. This is an integer instruction that checks whether its operand is between two bounds. It has rarely been used, and as such, is now emulated by the 68060.library. CMP2 falls into the same list.


CAS2 does not exist on the 68060 either. This is an atomic compare and swap instruction that is useful for multi-processor systems to ensure consistency of shared data structures. It is emulated by the 68060.lbrary. Again, it would have been too complex for bare silicon and was rarely used. On the Amiga, it requires a locked transfer which is not supported by the Amiga Zorro bus in first place, and therefore cannot be used safely on Amiga hardware anyhow. It falls into the same category as CAS and TAS. While both exist on the 68060, they cannot be safely used on the Amiga either. Bus locking is not supported in general.


Then, we have various FPU instructions that are not supported by the 68060, and most of them are not supported by the 68040 either. These are the transcendental functions and FBCC, but FPSQRT and FPINT and FPINTRZ are supported. If I recall correctly, the last one was not supported on the 68040, but is supported on the 68060. Again, the 68060.library jumps in as the processor generates a trap, so programs can safely use them. They require microcoding in general as their evaluation would be too complex for the silicon-level 68060 FPU. The 68882/81 implements them by the classical CORDIC algorith, the 68060.library by polynomial approximations.



Then, we have not only unimplemented instructions, but also unimplemented data types that are emulated in software, the 68060.library namely: Packed decimal (FMOVE.P) is too complex for the 68060 FPU, and the same goes for denormalized numbers, which also require help by the library.


Last but not least, let me mention that while MOVE16 is a instruction that is supported by the 68060 (and 68040), the Amiga bus system cannot be in general expected to support it, so it is typically not safe to use on an Amiga.

[SpeedGeek]

Originally Posted by Thomas Richter

Last but not least, let me mention that while MOVE16 is a instruction that is supported by the 68060 (and 68040), the Amiga bus system cannot be in general expected to support it, so it is typically not safe to use on an Amiga.

Well, thanks for taking the time to acquire a comprehensive and detailed knowledge of the 040/060 unimplemented instructions. Now, if you had only taken a fraction of this time to understand that the Amiga hardware bus design either does not support burst at all on 68000-68020 systems or only optionally supports burst on 68030+ systems (and only for part of the available address space on the bus) then I would not need to repeatedly reply to this topic (again)...

Now, since the 040 and 060 also optionally support burst they can and do function (with some hardware adaptations) on any classic Amiga 68K bus system.

Hence, MOVE16 has absolutely no compatibility problem with the Amiga 68K bus.

Thus, the principle concerns with MOVE16 "Safe Usage" are 1) The 16 byte source and destination alignment requirement and 2) The Motorola/Freescale documented Errata conditions. But this should be a comparatively simple problem to solve any for any Software developer making such extraordinary efforts as described above.

[coldacid]

Thomas: The list that I produced, as mentioned, are those strictly unavailable, i.e. not even trapped and implemented in software, and is based on Motorola's own '060 manual. I wasn't including the trapped-and-software-implemented ops because there are still opcodes and implementations for them, even if the latter aren't in silicon. This covers CAS2, CHK2, CMP2, the 64-bit related division and multiplication ops, and the mentioned FP ops (including packed decimal).

For PFLUSHA, the manual shows it as implemented only on the 68030 and the 68851. Did you mean PFLUSH, which is on the '030, '040, and '060, along with the 68851?

Thanks for the writeup, though.

[Thomas Richter]

Originally Posted by coldacid

For PFLUSHA, the manual shows it as implemented only on the 68030 and the 68851. Did you mean PFLUSH, which is on the '030, '040, and '060, along with the 68851?

PFLUSHA also exists on the 68040 and 68060, it is just an opmode of the PFLUSH instruction which has an encoding different from the 68851 encoding.

[roondar]

Huh, learn something new every day... I always thought the 68040/68060 didn't have the bitfield instructions.

[Tomislav]

About cpXXX, coprocessor "ID" and other line-F or F-line instructions that I found. Here are explanation of bits which are used in instruction for coprocessor "ID":

1111 iiiX XXXX XXXX  <here goes extension words for some instructions>
 X - instruction specific bits
 iii = bits 11 - 9 of instruction or coprocessor "ID"
 000 - 68851 PMMU and 68030 MMU
 001 - 68881, 68882 and 68040/68060 FPU
 010 - 68040/68060 MMU
 011 - 68040/68060 MOVE16
 100 - CPU32 specific instructions and also 68060 LPSTOP.W instruction (which is actually one of CPU32 instructions with same code)
 CPU32 are 683xx processors.