in case you are interested to test new fpga accelerators for a600/a500

[biggun]

The added value of the modified ISA is certainly not HIGH.

What is your definition of high?
Is trippling the FPU speed with new ISA high?

[biggun]

You're mixing two things here: Added speed (which is a forwards compatible extension) and extended ISA (which is not a forwards compatible extension). The added value of more speed is high. The added value of an extended ISA is low (who would use it anyhow, and if so, how?)

Thomas

you misunderstood my point

With old ISA the FPU is only as fast as 68060 @ 66 Mhz.
With NEW-enhanced-ISA the FPU can offer 68060@400 Mhz speed.

This means NEW ISA makes huge impact.
I can show you example code showing this.

[biggun]

@Matt Hey and Gunnar. Can you make the Coldfire compatible via a software library?

To which Coldfire you want to be compatible?
Which model - which Coldfire ISA?

For me to understand - Can you explain why you want this?

[biggun]

Gunnar, please. Are you telling me that the core runs at a faster speed because you added instructions? I beg your pardon...

I'm not sure what is not to understand about this.

For here just accept the truth - new ISA will double and tripple performance in certain areas.

I have the feeling the forum here is not the best place to explain.
Lets go to the whiteboard now..
If you have time just give me a call I'm happily explaining it then to you.
I'm sure on the phone all we be crystal clear for you in matter of minutes.

[biggun]

by making software developers shooting at a moving target,

Come on Thomas what wrong here.
Is today "the offical day of misunderstanding people" ?

His point was very clear to me.
And his point makes good sense.

For example:
The situation to get a CPU card today.
And next year install a "flash update" which adds a FPU.
And next year after  install " flash update" which adds some SSE instructions.

This is perfect for the users.
Imagine you could have turned your 68000  per flash update into an 68020 and then into a 68060.
Wouldn't this have been wonderful?


He never said that an update will remove anything.
This is really a silly thought IMHO.

[biggun]

Who knows which instruction set Joe User has loaded today? Do I really need to test all the instructions for availability?

hmm you seem to got it wrong again.
No one said that stuff get ever removed or replaced.
We talk here about the possibility to complete and improve while keeping all previous features.

We spoke here about shipping core today as Integer core.
Then in 6 month provide FPU upgrade.
The interger core does not "loose" anything then.
Then maybe 6 month later add "mmu" including both FPU and full Integer core.

So "the only way is up" - nothing gets removed here.

[biggun]

People all is good here.
Thor and my are old friends so to say.
There is nothing wrong to have a technical agree or disagrement sometimes.

Thomas point is that as soon you have a new CPU people might compile software tuned for it.
In the old days we had this problem.
People compiled some application for 68020.
Lets say for example AmIRC, which is not really a CPU eater.
It should run also on 68000.
But compiled for 020 so won't run on 68000.
I think this is the point of Thomas.
That maybe some applications for which a 68030 would be fast enough
will be compiled for Apollo and the executable will not on 68030 anymore.
I fully agree with Thomas that this would be stupid and unneeded.

I agree with Matt that a few percent improvement here and
a few percent improvement there will add up.
Some instruction like MVZ will give a percent more speed here and there,
and better Register usage will give some percents too.
Maybe we get 10-15% more speed this way.
10-15% more speed might not sound much,
but mind that the 10% would already the speed of a full 68030@50Mhz.

I think there will be cases where its all or nothing.
Like for example a h264 decoder. There are usecases
where we know that no old system it fast enough to use them in a sensible way.
Then compiling for Phoenix and getting 15% more speed makes sense.

[biggun]

I don't think anyone involved with the Phoenix/Apollo project has considered a software library for 100% ColdFire compatibility up to ISA_C (excluding MAC, EMAC and FPU) but it could be done if there was a specific purpose and enough demand. /QUOTE]

If you compare the Coldfire and the 68K general instruction set then
its obvious that Codlfire general Instruction set is much smaller and simpler.

- A good number of Instructions are missing.
- Some Instructions are crippled. E.g MOVEM
- The ALU operations do not support BYTE/WORD/LONG anymore but only LONG.
- The available EA modes are limited, this heavily weakens all Immidiate instructions.

The MAC instruction are specialist. They for example include a MOVE with another OPERATION.
The included move in the MAC is useful for Coldfire as it allows "hiding" memory access time.
For Phoenix this is not needed as Phoenix has streaming detection and can prefetch and will
by itself with normal code already hide memory latency.
Some MAC operation include special operation handling.This is usefull for DSP applications.
This is nice. The Phoenix includes conditional instruction rewrite.
This means the same benefits could already be generated with normal instructions in many casesby the Phoenix core.

So yes the MAC instructions are for some special purpose areas nice.
But Phoenix provides general CPU improvements as the conditional rewrite and memory streaming which add some of the MAC benefits to all general 68k programs already and this automatically.

If you compare CPU architectures then you see that the best Coldfire the Coldfire V4e,
can do 1 ALU operation per cycle - while Phoenix can do 3 operations per cycle.

[biggun]

My 68060 @50Mhz can already do 3 operations per cycle.

Code: [Select]

loop
     addq.l #4,d0
     addq.l #1,d1
     bne.b loop
That is 3 entire instructions executed every clock cycle.

This proves my 50Mhz 060 is a 150 MIPS machine.
A 100Mhz 060 is a 300 MIPS speed demon.

First of all, prediction a branch its not an ALU operation.
Do 3 ADDs would be three ALU operations.

And did actually measure the above?

[biggun]

@Gunnar

So you are saying you can do 3 ALU operations per clock?  If so, that is awesome!

Not me. Phoenix does 3 ALU operations per clock.

Give some examples.  

MOVE.L ($1245998,A0,D7*4),D2
ADDA.L #$00012345,A0
SWAP   D7
ANDI.W  #$88aa,(-8456,A7,D0*2)
OR.L     D7,D2
LEA       (18,A1,A5*,A6

6 instructions = executed in 2 cycle

[biggun]

:lol:
That is kRaZy! :crazy:  That would be like 14 kazillion PPC instructions!

Lol yes.
And the 68060 needs 8 clocks for the Instructions above which Phoenix can do in 2


often very cool is the below:


 BLT .thisway
 MOVE.L #$F00FF,D0
.thisway


What do you think how long do the 2 instruction take on Phoenix and on other systems?

[biggun]

So wait. Why exactly do we need a "move zero extended" instruction again?

If you want to blame someone, then blame Intel its their fault.  :-)
Intel did research studies in the 80th and found out that these instructions are very useful.

After all, "moveq #0,d0; move.b (a0),d0" could also be merged into a single "meta"-instruction, right?
Similarly, "move.w (a0),d0;ext.l d0" could also be merged into one instruction....

This is correct.
In theory a smart CPU could fuse this


move.b  (ea),Dn
extb.l     Dn


and


move.w  (ea),Dn
ext.l     Dn


Could be fused to be single cycle each

I agree with you that this is an option
This was also my argument that Phoenix could do this in single cycle already.....

[biggun]

I see now even less the need to extend the ISA.

Thomas
I understand the idea of in theory being able to run new applications on old hardware.

But to be honest I'm not sure how realistic this hope is.
Please read my points and explain your view on them.


As ou know the new cards are going to have a local RTG Graphic Video card included.
The CPU has very fast access to this memory.
We talk here about direct read /write access from CPU with several hundred MB/sec.
This means direct single pixel manipulation will be very very fast.
Compared to even the fastest AMIGA Zorro card we have here a speed up of 50 times  or 100 times.
Yes the local memory access will be 50 or 100 times faster than you Memory Access over Zorro.

As soon new applications use this an runing on old 68060 system with RTG card is hopeless
 as the speed difference between new and old system is over 10 times.

This means if you new game or application uses the new card.
Then the frate rate on old system would be so much slower - its will be come pointless.

I assume you see this too, right?

The new CPU is so much faster than we can now look at stuff like H264 playback which is totally senseless to try on old 68030.
So whether there is a new instruction used or not - does not make a difference the new video datatype will anyway not run on old slow 68030.
And also 68060 will be too slow in many cases.


Olaf did ask the a similar question. But you did not answer it yet.
He did ask you what happens if people use the SAGA chipset in their apps?

I agree with you Thomas that a "hello world" does not need any new instructions.
But a "killer app" which we all look forward too like modern webbrowser or good video player
these will anyway out-spec the old system - the whether the use new instructions or not makes no difference the old 68K CPU are simply to slow for them anyway.


Do you agree here or what is your point?

[biggun]

possible use of A-line (goodbye MacOS compatibility).

THIS IS NOT TRUE

Matt all encoding which are new are gated with a Apollo-Mode switch.
You know this fact, this was discussed over a year ago.
This means there is no impopatibility old MacOS code.  
You should know that ALL your posts about incompatibility are NOT TRUE.

Matt how do you call people which on prupose while knowing better write not the truth?

[biggun]

To Thomas,

Thomas I understand your point that new instructions can have
the side effect that new compiles will  not run on old CPUs.
This is clear and this is understood.

What I am not understand is how relevant this is in our case.

Lets look at some numbers
Phoenix today can reach over 300 Mips - this means Phoenix is like 20-30 times faster than todays ACA cards.
We see on the horizon the next gen FPGAs.
This means we can have a future roadmap where we know we can create cards with over 1000 Mips.

The performance difference between Phoenix and old 68030 cards is so ridicolous
that I think the wish to run future killer applications on both platforms is pointless.

[biggun]

Last post from my side here.


I appreciate technical discussion.
I appreciate any discussion about which enhancements make most sense, about what benefit 100% Coldfire compatibilty can give us.

What I can not stand is that when people try to strengthen their points by posting manipulative lies.

I have a real problem here with how Matt behaves.

Matt posted on some forum that the way we design the CPU/FPU internally would hindern us going for ASIC.
This is pure bull%&$#?@!%&$#?@!%&$#?@!%&$#?@!.
The fact is that Phoenix design proposal here matches 100% what INTEL, AMD and IBM are planning to do for their next CPU generation coming to market in 2 years.
This means our design is state of the art, absolutely modern.
And what we plan to do is perfect for going for ASIC.

Matt posted here 2 times that Phoenix would have problem running MAC-OS.
This is bull%&$#?@!%&$#?@!%&$#?@!%&$#?@!.
I do not understand why Matt on purpose post lies.


This thread started as very valueable post by somoen pointing out the option to get early Developer cards.
Unfortunately this threads quality got quickly worth by off topic post.
And some of these posts are pure lies.

I see no reason for us to continue to talk on this level.
I will not post here anymore.


If people think it makes sense to spread lies then continue without me.