Well, I guess it's me getting confused with the new syntax. What I meant was, when you write
  JSR d16(Ax)
you merely create a pointer to this location. There is no read involved here. Only when using an instruction like
  JSR [d16(Ax)]
the value found at address 'd16 + Ax' will be read and used as the jump target (as in 'CALL [esi + offset]' on the x86). So there is only one read, not two. This read has to be done anyway when fetching the following instruction 'JMP abs.l.' It's a combination of the mentioned two instructions and very useful as it is so often done in a program. IOW:
  JSR -offset(Ax)
  JMP abs.l
turns into
  JSR [-offset + 2(Ax)]
(+2 because you would have to skip the 'JMP' instruction for compatibility)
You would not gain any bytes here, since both instructions are 4 bytes long, however there *might* be an advantage because you skip one jump. I'm afraid, I have no idea whether JMP instructions on the 68050 cause any problems with the pipeline. They often do on other processors. If not so, then, of course, a special instruction like this would be redundant.

Nixus Minimax wrote:

The disadvantage is that you lock everything for the time between two read time slots. In case each read operation triggers a burst read, this can be a significant amount of time.

Regarding such addressing modes you are perfectly right, of course.

Mainly yes. There is just one addressing mode I miss occasionally which is
    MOVE.s  <ea>, d32(Ax) (or vice versa)
IOW a displacement of 32 bit instead of 16 bit (for bigger objects or accessing global data via a global pointer). Otherwise just like you I haven't found any usage for further addressing modes. In fact, when I designed the ISA for a virtual processor (just for fun), I reduced the standard addressing modes to just 4: reg, (reg), (reg)+, and offset(reg) (#imm ==> (pc)+ and -(reg) only with move and movem as a target). As mentioned before, I prefer writing OO code. Hence the addressing mode I use most of the time is simply offset(Rx). I don't use absolute addressing at all (don't see why), and code like
    EOR -(Ax), d8(pc, Dx)
is totally out of question. (You can see, I'm not in favour of a VAX design as Gunnar once proposed.)
However I always left JSR [off(Rx)] in as it is used so often in OOP.

If it's easy enough to replicate the integer units, I think it would be interesting to see some test results that show the diminishing returns of additional integer units.

3) How many average instructions per cycle and MHz in simulation or expected?       The core is too unfinnished yet to publish any numbers, but the peaknumbers are excellent.

Alright, my expectation of excellent is 4-5 instructions/cycle peak and 2.5 average :D.

4) What instructions are in the core (missing 68k, CF, custom)?       The main core will support everything. The rest of the cores will be reduced. This is the same motorola did with the Mc68060. remember P1/P2? Some instructions will pipeline, others will not.

You mean pOEP and sOEP? Yes, I remember. I hope more common instructions are included in all the integer cores. The 68060 sOEP is missing some common instructions like swap, exg, bit and bitfield instructions, pea and muls/mulu. Many instructions are fine being pOEP only like outdated and supervisor instructions.

6) What is needed to be able to insert the core into the current Natami's fpga?       Gunnar is testing on the cycloneIV already. Not only in the simulator.

Is he testing on the CycloneIV in his Natami?

Rune Stensland wrote:

If you search for Gunnars old posts on the forum you can see some of the ideas we discussed some years ago. Some of these features has been included, and some have been left out. 020++ adressing modes that are rarely used Should we support them?

Memory indirect preindexed and postindexed addressing modes are slow on all 68k processors including the 68060 (relatively) which is why they aren't used much. The superscaler 68060 is able to do them without trapping. Locking the memory bus from other instructions is probably not much different than movem instructions but not optimal in a superscaler environment. They can avoid change use stalls, save registers and offer better code density if they are at least as fast as the simpler instructions that replace them. If they cause more problems and complexity in a superscaler environment than they are worth, then trap them. Don't judge them based on how little they are used where they are slow (like the bitfield instructions). The timings that Gunnar gave in the old threads were promising if they can be used in all integer units. It's certainly alright to trap them for now to get the soft core on the road.

Matt Hey wrote:

It's certainly alright to trap them for now to get the soft core on the road.

Yep, this is certainly of highest priority as always. :)

I strongly believe that the 68020 indeed was an attempt to make instruction patterns commonly produced by compilers become individual processor instructions. The 020 was developed at the beginning of the 80s, a time in which even things like "string compare" would be turned into a processor instruction. To me it seems very likely that Motorola looked at what new instructions people building compilers would want. I believe that around the same time all the object-oriented stuff became big which probably meant much more pointer handling on the machine-level. The quote you cite is very interesting because it illustrates how RISC totally changed the direction of development within a few years. Eventually the hardware engineers stopped listening too attentively to the software guys... :)

RISC may well have been a reaction to the folly that was the 020 from a circuit designers point of view. Until RISC came around, progress in processors was often equaled to offering more processor instructions. BTW, with the stalling clock rates of recent years there seems to be a new trend to adding instructions which help certain code, e.g. encryption.

Yeah, nice new features! :-)

 

CF instructions are left out. But they can be added. 020+ indirect adressing modes might be moved out to emulation/trapped.

 
im fine with that so far, this would only introduce incompatibility to existing hardware.

I did a search on google and din't find it, so i think it hhas been published in the team secton only. Sorry about that

CLICK HERE

You can look at Thomas rudimentary docs here:
CLICK HERE

This may be a related idea to your last comment Comp Arch:

Intel, in order to add 3 operand encoding and predication has added them by adding addressing modes, prefixes and otherwise added bits to the instruction set.  This has the distinct disadvantage that software needs to be recompiled to take advantage of the new features.

The NatAmi processor core is planned to do some magic in the decoder called "opcode fusion".  This means that if a branch has an offset the same as the next instruction it will automatically be promoted from a branch to a predicated instruction fetch.  Also, if a two-instruction sequence moves from one register to another and then modifies it with a math function, the decoder will automatically convert it to the equivalent 3 operand opcode so that the original two instructions can be executed in one clock instead of two.

As you mentioned about doing a maid core, there has been much discussion on here about that.  At one time it was named "Robin" core but the plans of the custom instruction set have been dropped because it would take too much time to deal with two instruction sets.

I hope this satisfies at least some of the curiosity.  ;-)

Samuel D Crow wrote:

The NatAmi processor core is planned to do some magic in the decoder called "opcode fusion".  This means that if a branch has an offset the same as the next instruction it will automatically be promoted from a branch to a predicated instruction fetch.  Also, if a two-instruction sequence moves from one register to another and then modifies it with a math function, the decoder will automatically convert it to the equivalent 3 operand opcode so that the original two instructions can be executed in one clock instead of two.

Also thanks for the fast response! Yes, indeed, this "opcode fusion" is something the NatAmi team can really be proud of. (As a totally uninteresting and irrelevant aside note: the somewhere above mentioned Amiga programmer and author of the Apple2000 emulator, Kevin Kralian, used such a method to speed up execution of the 6502 opcodes. :) )  Is there already a list of all opcodes that can be fused? Or is there still room left for additions? 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
as I use this all the time at the end of a function to signal "no error occurred". Would be nice if that was fused together.

Samuel D Crow wrote:

As you mentioned about doing a maid core, there has been much discussion on here about that.  At one time it was named "Robin" core but the plans of the custom instruction set have been dropped because it would take too much time to deal with two instruction sets.

I agree. Get the 68050 running first. And then a second 680x0 would be the right way to go IMHO. Not only could it be used as a co-processor but also as another core to run a different program in parallel, despite the fact that the current AROS (or whatever OS) does not support second cores yet. But who knows, this may change in the future.

Samuel D Crow wrote:

I hope this satisfies at least some of the curiosity.  ;-)

Well, for a brief moment... Remember Oliver Twist? 'Please, sir, I want some more...' :)

As nice as it would be, it would not be using 3 operand encoding nor predication so it cannot be fused.  The moveq operation writes to the D0 register while the RTS instruction writes to the A7 (stack pointer) and PC registers.  You cannot write to two registers at the same time.  The only reason that a move d0, d3;  add xxx, d3 can be fused is that the destination register is the same for both opcodes.  It's not a question of finding commonly used sequences of opcodes, it's a question of mapping existing ALU functionality into the existing instruction set so it can be used without recompiling.