comp arch wrote:

Could I ask you, please, whether the instruction 'MOVEQ' will be fused with other instructions as well? I'm especially thinking of the combination         MOVEQ  #0, d0         RTS

 
  I believe Samuel's answer is correct (no fusion possible) but the rts should be much faster on the N68k with the addition of a link stack. The rts is 7 cycles on the 68060 but should be about 2 cycles on the N68k with a link stack. The link stack is talked about in the fusion thread above.
 

they would encourage backwards incompatibility by their sole availability. this i would prefer to avoid as long as it is not really bringing an unbelievable boost.
im sick of all these cpu dependant versions of software on amiga.

BTW.: What about the LineA opcodes? Will they cause an exception? AFAIK some old programs depend on it. (IIRC adventures by Magnetic Scrolls. There was also a flight simulator that crashed for this reason, but I'm not sure. It's so long ago...)

Matt Hey wrote:

The ColdFire instruction additions to the N68k will NOT cause compatibility problems. The 68k of the N68k will work 100% the same as any other 68020+ CPU. ColdFire compatibility can't be 100% on the N68k though.

According to my manual e.g. the ColdFire instruction MOVE to Accumulator (MOVE.L Ry, ACC) has the instruction format
  1010 0001 00 mmmmmm
and will thus cause a conflict with the LineA handling. (Unless, of course you trap these ACC instructions via LineA to emulate them...) Sorry I have to ask ('cause I really don't know): is ColdFire compatibility essential or somehow needed?

Matt Hey wrote:

Don't use CALLM or RTM on an Amiga.

Don't worry, I won't. :) Never used them, and I doubt anyone did.

Matt Hey wrote:

They were slow and a mistake anyway.

At last, I found someone who actually knows what they were doing. :)

Matt Hey wrote:

The rts is 7 cycles on the 68060 but should be about 2 cycles on the N68k with a link stack.

2 cycles only? That's real fast and would help a lot.
In a previous post I asked about the typical combination of
  JSR library_offset(A6) ; A6 = pointer to jump list
  ...

<jump list>
==> JMP label .L

label:    ; some library routine here
  RTS

Could I ask you, how does the 68050 handle such an indirect subroutine call? Is there any influence on the pipeline or are branches with a fix address free of charge?
Oh, and please let me know if I ask too many questions... (I know I do)

The 68k with CF and additional changes adds modern features that were not popular back in the day but are common and expected today. They make programming easier and compiler support easier. CF support in compilers can easily be enabled and most existing CF software can be used. The code density is improved to what I expect to be one of the best available for any modern CPU and a good selling point for low end systems. The speed is improved and smaller caches and memory are needed. Individually, the advantages are small but, as a whole, the advantages are obvious IMHO. I would like to see a standard ISA that is supported by Natami and fpga Arcade to minimize the number of variations and encourage their use. We must plan for a positive future. It's the same reason the Natami is developed with modern advances and adds chunky screen modes and 3D to the Amiga. It's what the Amiga should have been if development had gone on. It's the Amiga and Natami spirit :).

comp arch wrote:

According to my manual e.g. the ColdFire instruction MOVE to Accumulator (MOVE.L Ry, ACC) has the instruction format   1010 0001 00 mmmmmm   and will thus cause a conflict with the LineA handling. (Unless, of course you trap these ACC instructions via LineA to emulate them...) Sorry I have to ask ('cause I really don't know): is ColdFire compatibility essential or somehow needed?

The CF MAC instructions will not be supported. The CF instructions planned for support are bitrev, byterev, ff1, mov3q, mvs, mvz and sats. rems/remu would interfere with divsl/divsu so they can't be used without changing the encoding. There shouldn't be any line A encodings which will be left open if possible for Macintosh 68k emulation. All 68k instructions will be done 68k style including stack use. Some CF instructions will likely have more usable addressing modes than the CF supports. CF additions are not necessary but there shouldn't be any 68k compatibility problems and there are many benefits.

comp arch wrote:

In a previous post I asked about the typical combination of   JSR library_offset(A6) ; A6 = pointer to jump list   ...     <jump list>   ==> JMP label .L     label:    ; some library routine here   RTS     Could I ask you, how does the 68050 handle such an indirect subroutine call? Is there any influence on the pipeline or are branches with a fix address free of charge?

This was discussed in a thread but there was not a definitive answer in the best way to handle library function tables. They will probably be a few cycles faster than a 68060 but not several times faster like rts. It may be possible to detect and fold out (eliminate=0 cycles) the jmp instruction sometimes. The jmp would probably have to be in cache (caches are much bigger) and the library base may have to be in a6 several instructions before the jsr. You certainly want to load the a6 library base as early as possible so change:

  moveq #0,d0
  move.l execbase,a6
  jsr (-$24,a6)

to:

  move.l execbase,a6
  moveq #0,d0
  jsr (-$24,a6)

Loading address registers that can be used as pointers first is generally best for 68k family processors as it can avoid or reduce change use delays in some cases. There may be a branch cache added at some point to the N68k which should help as the target is usually the same from each jsr. Gunnar seemed like he did not want to add a branch cache for some reason though. The branch cache on the 68060 works great. A branch cache on the N68k with function table recognition might be able to fold out the jsr (except stack use) and jmp. Don't expect any time soon but I have been pleasantly surprised lately with the superscaler announcement ;).

I love the 060 branch cache as much as anyone.

But the interesting thing about the branch cache on the 060 is that by having it enabled, you limit the maximum Mhz of the 060 by a few Mhz.

This is according to Rune's hardcore clocking experiments.

   RegToReg:  2662 (6)%
   MemToReg:  4414 (11)%
   RegToMem:  2505 (6)%
   Branch/Lea #:  6877 (17)%
   One reg:    848 (2%)
   MemToMem:  1364 (3)%
   No reg:      1151 (2%)
   

What are the other 53%?

:)

I really wasn't sure whether there could be something more that wasn't listed, so I preferred to ask.

Marcel Verdaasdonk wrote:

I am not sure what rune tested but yes Branch cache limits the maximum clock rate.   This is because these caches are synchrone with the CPU.

Hmm. Interesting. I would think the branch cache would be as fast as the CPU caches and able to always keep up. Any delay should be hidden in the pipeline. The 68060 has 0 cycle branches taken on branch cache hits and that's with virtual address lookups. It makes even more sense on the N68k where there is no virtual addresses and the branch cache should not need to be flushed during task switching. All modern CPU's have much higher clock rates and virtual addresses with branch caches but maybe they have longer pipelines to hide the branch cache accesses? I would think that the minimum pipeline length to provide 0 cycle loop branches and 0 cycle predicted branches would be optimum. What is more important than reducing branch overhead in a modern CPU? If code doesn't use many branches then send it to a modern GPU ;).

I would guess that there is a deliberate design limitation. If you read from I or Dcache, you always have to consider the case that the requested data aren't in the cache. Thus, you implement the possibility of a pipeline stall. Now if you overclock, it won't really matter whether the (cached) data is available within a cycle or whether it is two. The interface is flexible and designed to interface to different memory subsystems.

The branch cache, on the other hand, is part of the pipeline logic. You won't clock the logic higher than what you find in your tests to be the highest possible clock rate. If you clock just a tiny bit too high, you would get a pipeline stall for each branch. This would hurt the processing speed much more than you could ever gain from the extra clock rate. Thus, there is no reason to make this data path between the branch cache and the pipeline flexible. You would never clock the whole thing any higher than what can be done in the clock period. I expect that the higher clockrate with disabled branch cache shows a lower overall performance. The critical path has to be somewhere. I don't think it is too surprising to find it in the branch prediction which is very important for speed. Also, you wouldn't necessarily notice critical paths in some ALU units such as MUL or DIV which may depend on the data.

I wonder if booting with not that much more MHZ is worth disabling the functions you named

Can anyone tell us the current speed of the new cpu core?

You are right, Matt.  There are several instances other than 3-operand and predication opportunities for opcode fusion.

While it would be nice to have a list, it would be nicer still to know which ones are actually implemented in the core at this time as well.  Fortunately, Gunnar and Deep Sub Micron are hard at work implementing the core so we'll have to wait until they are done to have a definitive list.

The following encodings are known for sure to be fusable:

3-operand
    move.l d0, d3
    add.l xxx, d3

becomes
    d3= d0 + xxx

predication
    bne.b label
    add.l  d0, d1
label:

becomes
    addeq.l d0,d1

sign extension
    seq d0
    extb.l d0

becomes
    seq.l d0

These are the bare minimum.  There may be others.  The sign extension may use some Coldfire-style codepaths so they might not be implemented yet.

Probably not until it's ready.  Keep in mind that its clock-speed may be adversely affected by some of the opcodes that are not yet implemented.  The current clock speed is the greatest common denominator of the existing opcodes.

Combinations (code fusions) like scc+extb.l may need the equivalent of a new instruction internally (or use a longer more generic version of scc internally). While it's better to share code/logic if possible, this is common, important to be fast to avoid branches and the result can be forwarded to another OEP (integer unit) as it turns into a long instruction.