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

[JimDrew]

ORI.L #d16, does not allow trapping of CMP2.B and CHK2.B
ANDI.L #d16, does not allow trapping of CMP2.W and CHK2.W
SUBI.L #d16, does not allow trapping of CMP2.L and CHK2.L
ADDI.L #d16,  no conflicts
EORI.L #d16, does not allow trapping of CAS.B
CMPI.L #d16, does not allow trapping of CAS.W and CAS2.W

While most of these instructions (with these operation sizes anyway) are likely to be rare even on the MacOS (and all should be deprecated IMO), I don't know if they are used on the MacOS so they could pose a problem. I wish Jim Drew had found his list of MacOS instruction frequencies he said he made years ago.

I looked through even my Syquest cartridge backups and I could not find that info.  

I can tell you that the MacOS uses ALL of the above instructions.

I will chat with Derek (emulators, inc.)  I might have given the instruction frequency info to him when I sold FUSION-PC to his company.

[Plaz]

Last I read was that some instructions were incompatible on the Coldfire that could not be trapped so the code basically has to be run under (JIT) emulation.

Back in the day I worked on one of the coldfire projects specifically on code compatibility issues.

The exact problem is that there are matching instructions which are completely legal on both coldfile and 68K... BUT they execute different functions. Since these codes are legal, there is no way to trap them in supervisor mode. The 68K code is accepted by the coldfire, but doesn't do what's expected by the OS. (crash)

To catch these few trouble codes (2 if I recall) some other method is needed. Pre-processor one possibility. In the end, any of the solutions greatly increased the complexity and cost of a coldfile Amiga card.

The Atari cold file was successful mainly because their OS didn't use these 2 matching op codes, so they didn't have to worry about them.

Plaz

[matthey]

Matt you to agressive here.
Can you just calm down?

I am calm. Do you see one exclamation point, upper case text or bold text from me? You accused me of twisting the truth and I am not supposed to defend myself? I ask questions to uncover the truth and I receive more questions in return. I worked to create an open enhanced 68k ISA and instead you use some of my ideas and analysis to make a secretive ISA. You try to make me look like an outsider who is not capable of understanding the complexity of your ISA yet I have much of it documented better than you. You ignore the suggestions and conclusions of the majority beneath you but make no apologies when you end up using what they suggested after you arrogantly run them off. Some people want a saviour so bad that they are willing to put up with anything but I am wary of the fruits of a false Messiah.

Your problem is that you misunderstand stuff and or misinterpret stuff.
There was nothing incorrect about the old forum post.

Lets look at the fact first before we start to panic ok?

There is no panic but only a desire for the truth which has not been revealed because my questions have not been answered. Your own information spreads confusion unless you use consistent sytax and terminology, give enough information to be clear and update your information when you make changes. The information you have given about your new ISA on your forum is unclear and mostly useless.

The forum post did show several instructions.
In fact only the instruction behavior and name was discussed there.
The encoding was never discussed in this posting.

This means the instruction where shown in NAME only not in ENCODING.
Is this correct - Matt?

That is correct but unlikely as there are not very many good ways to add OPI.L #d16.W, encodings for such a small gain. Also, why keep this info about your ISA secret instead of answering the question about MacOS compatibility?

I looked through even my Syquest cartridge backups and I could not find that info.  

I can tell you that the MacOS uses ALL of the above instructions.

I will chat with Derek (emulators, inc.)  I might have given the instruction frequency info to him when I sold FUSION-PC to his company.

Thanks for looking anyway Jim. I lose stuff I know I still have somewhere. I know the MacOS uses a wider variety of 68k instructions but those instruction frequencies would be interesting. CMP2 was quite rare on the Amiga with WHDLoad reporting patches of only 2 games or demos. CAS and CAS2 (and TAS) were not compatible with Amiga chip set DMA and were documented as illegal on the Amiga so they shouldn't have been used (but a few games used TAS at least). I was for reusing these rare encodings *if* there was a large enough benefit but after analyzing data and considering the importance of compatibility to a retro 68k market, my conclusion was that it is not worthwhile (not that my opinion or vote ever counted).

Back in the day I worked on one of the coldfire projects specifically on code compatibility issues.

The exact problem is that there are matching instructions which are completely legal on both coldfile and 68K... BUT they execute different functions. Since these codes are legal, there is no way to trap them in supervisor mode. The 68K code is accepted by the coldfire, but doesn't do what's expected by the OS. (crash)

To catch these few trouble codes (2 if I recall) some other method is needed. Pre-processor one possibility. In the end, any of the solutions greatly increased the complexity and cost of a coldfile Amiga card.

The main user mode integer problems are:

1) The CF stack is longword aligned where the 68k stack is word aligned.
2) DIVSL/DIVUL incompatibility (68k returns quo+rem while CF returns quo and has REMS/REMU for rem)
3) MULU/MULS incompatibility (68k sets CCR[V] for overflow but CF does not)

Motorola could have sold a lot more CF processors if they had been smart and allowed all 68k instructions to be trapped, set the CC the same for all instructions and allowed a setting for the stack to be either word or longword aligned. They couldn't even do a good job of cutting the 68k to anemic performance .

[xboxOwn]

I am calm. Do you see one exclamation point, upper case text or bold text from me? You accused me of twisting the truth and I am not supposed to defend myself? I ask questions to uncover the truth and I receive more questions in return. I worked to create an open enhanced 68k ISA and instead you use some of my ideas and analysis to make a secretive ISA. You try to make me look like an outsider who is not capable of understanding the complexity of your ISA yet I have much of it documented better than you. You ignore the suggestions and conclusions of the majority beneath you but make no apologies when you end up using what they suggested after you arrogantly run them off. Some people want a saviour so bad that they are willing to put up with anything but I am wary of the fruits of a false Messiah.................

So what you are saying is: biggun is a scamming us? I am no longer waiting for the vampire and ordering ACA1233 instead because matthey is giving me bad ideas about biggun's project.

[Plaz]

Motorola could have sold a lot more CF processors if they had been smart and allowed all 68k instructions to be trapped

Thanks for the list. I specifically remember #2 and 3. With those "unsolvable" I never progressed far enough to see #1. .

Motorola's decisions confound me too. Seems it wouldn't have taken much to build a better bridge to legacy 68K hardware especially since there was so much of it all over the world.

@Thread

Interesting and contentious, but so far civil. I hope it continues that more progress is made.

Plaz

[matthey]

So what you are saying is: biggun is a scamming us? I am no longer waiting for the vampire and ordering ACA1233 instead because matthey is giving me bad ideas about biggun's project.

No, I am not saying that! I fully believe the Phoenix/Apollo project is real and has performance potential several times greater than a 68060 in an affordable FPGA. There is no scam. There is only Gunnar's lofty ambitions of which this is not the first time it has been a problem (research the Natami project). He needs an attitude adjustment is all. Majsta creates the Vampire accelerators and has been nothing but a good example of openness, cooperation and persistence against adversity. His accelerators offer tremendous value at the low end. The ACA accelerators are a more mature product but don't have the performance potential.

Thanks for the list. I specifically remember #2 and 3. With those "unsolvable" I never progressed far enough to see #1.

#2 is a real and common enough problem that every DIVSL.L and DIVUL.L has to be patched (it's probably easier to replace with a BSR to replacement code). #3 is actually pretty rare to use the CCR[V] from a multiplication but it is difficult to detect. #1 is a common problem also as every byte and word sized push and pop to and from the stack has to be fixed.

Motorola's decisions confound me too. Seems it wouldn't have taken much to build a better bridge to legacy 68K hardware especially since there was so much of it all over the world.

It was almost like Motorola/Freescale didn't want 68k compatibility for ColdFire. The 68k users were supposed to upgrade to PPC. Low end 68k users were looked at suspiciously for "wanting" 68k compatibility but the CF was advertised as being 68k like and easy to use. It made no sense and Motorola/Freescale ended up killing off many loyal 68k customers. The poor performance and minimal features of early CF processors didn't help either.

[biggun]

You accused me of twisting the truth

Matt I did never say that lie on purpose.
I said that you say is tell people not the truth, that you tell people simply wrong stuff.

In this case all you knew was the name of the instruction.
You did not know the encoding.
You have to admit this.

Nevertheless you warned that the encoding will break compatibility.
Matt what you did was not correct.

[xboxOwn]

No, I am not saying that! I fully believe the Phoenix/Apollo project is real and has performance potential several times greater than a 68060 in an affordable FPGA. There is no scam. There is only Gunnar's lofty ambitions of which this is not the first time it has been a problem (research the Natami project). He needs an attitude adjustment is all. Majsta creates the Vampire accelerators and has been nothing but a good example of openness, cooperation and persistence against adversity. His accelerators offer tremendous value at the low end. The ACA accelerators are a more mature product but don't have the performance potential.



#2 is a real and common enough problem that every DIVSL.L and DIVUL.L has to be patched (it's probably easier to replace with a BSR to replacement code). #3 is actually pretty rare to use the CCR[V] from a multiplication but it is difficult to detect. #1 is a common problem also as every byte and word sized push and pop to and from the stack has to be fixed.



It was almost like Motorola/Freescale didn't want 68k compatibility for ColdFire. The 68k users were supposed to upgrade to PPC. Low end 68k users were looked at suspiciously for "wanting" 68k compatibility but the CF was advertised as being 68k like and easy to use. It made no sense and Motorola/Freescale ended up killing off many loyal 68k customers. The poor performance and minimal features of early CF processors didn't help either.

But the way you are hostile and pointing out all his faults and defects and pointing out all his errors and in a way you implied he does not know what he is doing you give them negative light. Personally I want to buy vampire 500 badly, but if you continue in this road you might destroy what potentially a live rescue boat for classic Amiga.

I mean when I read your sentence I sense toxic energy.

[biggun]

Lets clear this up:

The Core and ISA definition is available for developers today.
It is NOT available today for download by the public
The reason is that the core is not officially released yet and that the core could still change and improve before release date.
Everyone should be able to understand the benefit of this reasoning.

As good news:
The Core is continously improved:
Yesterday the core was upgraded and can now execute 3 instructions each cycle

Also good news:
The core team with hardware designers had a long discussion and came to the mutual understanding and agreement that all CPU cards from now on will have a minimum FPGA size.
This means all cards for all platform will have a minimum sizes.
This size is big enough to fit the full Apollo core plus the 68k FPU.

This means all cards for all AMIGA systems e.g. A600/A500/A1200/... will support the same instruction set and the same features and have the same capabilities.
Software developers can write/compile for Apollo as target and this will run on all cards.
All features including FPU will supported both in budget and in high end cards.

[xboxOwn]

Lets clear this up:

The Core and ISA definition is available for developers today.
It is NOT available today for download by the public
The reason is that the core is not officially released yet and that the core could still change and improve before release date.
Everyone should be able to understand the benefit of this reasoning.

As good news:
The Core is continously improved:
Yesterday the core was upgraded and can now execute 3 instructions each cycle

Also good news:
The core team with hardware designers had a long discussion and came to the mutual understanding and agreement that all CPU cards from now on will have a minimum FPGA size.
This means all cards for all platform will have a minimum sizes.
This size is big enough to fit the full Apollo core plus the 68k FPU.

This means all cards for all AMIGA systems e.g. A600/A500/A1200/... will support the same instruction set and the same features and have the same capabilities.
Software developers can write/compile for Apollo as target and this will run on all cards.
All features including FPU will supported both in budget and in high end cards.

Love it!

One question. What is the difference between budget and high end cards?

[guest11527]

The Core is continously improved...

To be honest, I'm personally not too hot about ISA extensions at all. The major problem is here that it segments the platform while not offering a reasonable return. Just consider instructions like EORI.L #...,? What are the intended use cases, and which software would profit from that? Which compilers would support it, which assemblers would? Does it enable any "killer features"?

Let me tell you a bit from my personal experience: In my world (ISO business, WG1), we first make a requirements analysis before we attempt a new "work item". That is: What exactly do you attempt to do, and which requirements does it need to satisfy?

In essence, the ISA modifications up to here do not buy you much, but instead requires potential new software (for the Amiga? oh well...) to potentially distinguish between a legacy Motorola core and the Phoenix core. How will we do that? Another bit in ExecBase->AttnFlags? How many revisions of the core will there be? We might be running out of bits shortly, and it may get more and more inconvenient to update software.

In reality, how many programs did use the new features the newer processors of the Motorola series introduced? Essentially, Motorola only had two ISAs: The original 68K one, and the extended 68020 ISA. Everything between was really minor, and the majority of Amiga software uses the 68K ISA. A small part requires 68020+, but there is almost nothing that is specifically 68060/68040 only. I would prefer if extensions would continue in this tradition.

Instead of adding a series of seemingly nice, but in reality almost useless low-level additions, it would be much more sensible to add higher level functionalities that enable new killer features the Amiga did not have originally, and from which multiple programs could benefit. Say, JPEG decoding or MP3 decoding. None of the new instructions make these tasks simpler, easier or faster - they are too low-level. What it would probably take would be a hardware engine for some of the components of these standards (Huffman decoder, DCT, digital filters... hence, multiply-add instructions, shift-and-mask instructions and so on).

[biggun]

Just consider instructions like EORI.L #...,? What are the intended use cases, and which software would profit from that? Which compilers would support it, which assemblers would? Does it enable any "killer features"?

EORI.L #im,EA
If you mean tthe original 32bit form then this an original 68000 Instruction.
All compilers support it since always.



EORI.L #i16bitm,EA
If you mean a 16bit variant of this then this instruction does not exists.
It is NOT a Phoenix Instruction.
We have no plans to support this.

Let me tell you a bit from my personal experience: In my world (ISO business, WG1), we first make a requirements analysis before we attempt a new "work item". That is: What exactly do you attempt to do, and which requirements does it need to satisfy?

Thomas, I agree. We do the same.
The problem here is that some misunformation was posted and this misinformation is causing confusion.

[biggun]

To be honest, I'm personally not too hot about ISA extensions at all. The major problem is here that it segments the platform while not offering a reasonable return.

We agree that segmenting the platform is bad.
And actually I think that there is already a unhealthy segmentation existing.

There are Amigas which support MOVE16 and people use this instruction.
There are Amigas which have FPU and Amigas without FPU, and code that uses the FPU.

We want to improve this.
Our new cards will all have 100% the same instruction set.
All cards are designed to support all instructions including MOVE16 and FPU.
I think that this will help to provide are common coding ground.
The cards also offer a lot more CPU power e.g 200 Mips for budget pricing.

I think that this will make coding easier in the future.

[Lurch]

@biggun Any news on the developer boards? Put forward my interest, is there a time frame that you are looking at?

200mips sounds amazing coming form 100mips on my 060@80MHz I can see the potential.

Looking forward to further updates :-)

[OlafS3]

No, I am not saying that! I fully believe the Phoenix/Apollo project is real and has performance potential several times greater than a 68060 in an affordable FPGA. There is no scam. There is only Gunnar's lofty ambitions of which this is not the first time it has been a problem (research the Natami project). He needs an attitude adjustment is all. Majsta creates the Vampire accelerators and has been nothing but a good example of openness, cooperation and persistence against adversity. His accelerators offer tremendous value at the low end. The ACA accelerators are a more mature product but don't have the performance potential.



#2 is a real and common enough problem that every DIVSL.L and DIVUL.L has to be patched (it's probably easier to replace with a BSR to replacement code). #3 is actually pretty rare to use the CCR[V] from a multiplication but it is difficult to detect. #1 is a common problem also as every byte and word sized push and pop to and from the stack has to be fixed.



It was almost like Motorola/Freescale didn't want 68k compatibility for ColdFire. The 68k users were supposed to upgrade to PPC. Low end 68k users were looked at suspiciously for "wanting" 68k compatibility but the CF was advertised as being 68k like and easy to use. It made no sense and Motorola/Freescale ended up killing off many loyal 68k customers. The poor performance and minimal features of early CF processors didn't help either.

Matt you start to slightly nerving now. With the next wave there will be a number of new testers (some active here in this forum) who will test and verify it using the newest core. This idelogic debates (by technicians) if more or less registers are better are far from real. You should do that debate by PM or email and not in the public because most people do not understand it and are only getting irritated except you want to harm the project. If that is your goal then go on like you do. BTW as I wrote on apollo forum most of it is to me rather theoretical.

[Lurch]

I don't mind the debates, some of it is interesting reading. What I don't like is the negativity.