Coldfire AGAIN

[HenryCase]

biggun wrote:
Depending on your application the Coldfire can get away running 90% of the instructions natively.

Which is why Coldfire is the best upgrade for 68k architecture, and if it works, would be a good choice for the Natami.

biggun wrote:
You can buy the "source" of the Coldfire for an affordable sum. This means that you can "bake" your own Coldfire including AGA/SuperAGA in one Chip.

If you can "bake" your own Coldfire, would it be possible to fix the few misbehaving instructions to make a fully 68k-compatible custom Coldfire CPU? I'm assuming the fact that one CPU uses a 16-bit architecture vs a 32-bit architecture in the other CPU doesn't matter as the vast majority of instructions already work perfectly.

[HenryCase]

bloodline wrote:
You buy a licence to use the core, not modify it.

Shame.

bloodline wrote:
You would need the development documents too... and there are reasons why the instructions work differently, it's to get the speed up!!!

Surely a hardware implemented function would be faster than an emulated one?

bloodline wrote:

I'm assuming the fact that one CPU uses a 16-bit architecture vs a 32-bit architecture in the other CPU doesn't matter as the vast majority of instructions already work perfectly.

Err... the coldfire is 32bit, just like the 68k...  :-?

[/quote]

I thought the 68k family of CPUs was 16-bit, classic Amigas were always referred to as 16-bit computers, right?

[HenryCase]

bloodline wrote:

HenryCase wrote:

bloodline wrote:
You buy a licence to use the core, not modify it.

Shame.

I have been thinking about this, and in reality it makes little difference if the Coldfire core has to remain untouched. If you're building a custom Coldfire SoC, you can design logic around the core that fixes certain instructions (instructions can reach custom logic before core logic). Since this logic will run at the full core speed the performance hit is negligible.

So why can't we have a fully 68k compatible Coldfire again?  :-D

[HenryCase]

bloodline wrote:

HenryCase wrote:

bloodline wrote:

HenryCase wrote:

bloodline wrote:
You buy a licence to use the core, not modify it.

Shame.

I have been thinking about this, and in reality it makes little difference if the Coldfire core has to remain untouched. If you're building a custom Coldfire SoC, you can design logic around the core that fixes certain instructions (instructions can reach custom logic before core logic).Since this logic will run at the full core speed the performance hit is negligible.

So why can't we have a fully 68k compatible Coldfire again?  :-D

Really you would be wasting silicon here... you are suggesting a JIT in Hardware... Keep the JIT in software :-)

Hardly wasting silicon. What you'd be doing (in effect) is adding to the a table of 68k opcodes that the Coldfire already contains. So with the mul.l instruction, for instance, every time the mul.l code comes in (0x0007 in hex?) you perform actions that provide an identical result in a 68k CPU. That wouldn't take up a lot of chip space would it.

You just don't want to admit I'm on to something. :-P

[HenryCase]

bloodline wrote:
How does this hardware know what is Code and what is Data? It can sit there as a parasite on the Data Bus, but it won't know what it's looking at...

Surely in 68k ASM the first "half" of code is the instruction and the second "half" of the code is the data? As the code would be of fixed length (16-bit? 32-bit?) the 'parasite' would know exactly where to look for an instruction, right?

[HenryCase]

bloodline wrote:

HenryCase wrote:

bloodline wrote:
How does this hardware know what is Code and what is Data? It can sit there as a parasite on the Data Bus, but it won't know what it's looking at...

Surely in 68k ASM the first "half" of code is the instruction and the second "half" of the code is the data? As the code would be of fixed length (16-bit? 32-bit?) the 'parasite' would know exactly where to look for an instruction, right?

Nope. Not the instruction format... the actual information traversing the Data bus, could be Code or Data... Only the CPU knows what the information actually is.

How does the CPU know what the information is? By knowing and following the instruction format, surely! :-D

[HenryCase]

biggun wrote:
You are referring to the very first Coldfire versions.
The V4 and V5 Coldfire have two  a separate supervisor stack pointer.[/b]

@thread
You may want to look here:

http://www.elbox.com/faq_dragon.html
"Q: Why do you make a card with ColdFire processors only now? Motorola has been producing ColdFire processors for a long time...
A: Recently, Motorola has developed and produced several series of the ColdFire processors but none of them were compatible enough with 68k processors to be able to run AmigaOS3.x. This changed with appearance of the MCF54xx processors family. These are the first ColdFire processors based on the V4e core."

[HenryCase]

bloodline wrote:
Hmmm... this is going to turn into CPU 101...

I'm willing to learn. You never know, through my ignorance a good idea may emerge.

bloodline wrote:
The CPU makes requests to the Memory, sometimes those requests will be for an instruction, sometimes those requests will be for Data (as requested by an instruction).

Does the outgoing instruction know what it is requesting, or is it simply calling on a set memory space? Also, does memory get divided up into program space and data space or is it all jumbled up?

[HenryCase]

bloodline wrote:


There is no outgoing instruction.

I worded that badly, I should have used 'outgoing signal' instead. What I'm trying to get at is does the CPU give clues about what it is trying to fetch?

If not outgoing signals then are there CPU pins you can monitor to get information on what the CPU wants to do with the information it gets next?

bloodline wrote:
Memory on the Amiga is jumbled up, Code and Data are all over the place... on a x86 it has an MMU that marks memory pages as Code or Data... but then  you would still have the problem of variable length instructions.

Is the variable length instructions issue not something we can work around? Let's say the 'parasite' is looking for the instruction 0x000189. Whenever this code comes up the 'parasite' looks at the code following it. If it follows the format it is expecting then it tries to use it, if not then it lets the CPU try to handle it.

[HenryCase]

@bloodline

Well I'm convinced enough that the 'parasite' idea isn't worth pursuing now, little more difficult than I had hoped. Thanks for your help bloodline.

@all

Coldfire still shows promise IMO. Maybe we could do a bit of research into 68k-Coldfire compatibility. This should be a good place to start looking:
http://tinyurl.com/3exnxn

Oli hd please contribute to this discussion, your input will be very valuable here.

[HenryCase]

bloodline wrote:
But for the tiny sums of money (and low production runs) we are talking about, there is no way Freescale would allow any modification to the core.

Why would money/low production runs come into it? If the redesign work was done by a 3rd party, and the cost of manufacture was the same, where would Freescale be losing out?

[HenryCase]

bloodline wrote:

HenryCase wrote:

bloodline wrote:
But for the tiny sums of money (and low production runs) we are talking about, there is no way Freescale would allow any modification to the core.

Why would money/low production runs come into it? If the redesign work was done by a 3rd party, and the cost of manufacture was the same, where would Freescale be losing out?

That has nothing to do with it, it's about access to the technology. The less you pay the you are allowed to do with the IP.

OIC. Fair enough.

[HenryCase]

AeroMan wrote:
I'm not an expert in Coldfire. Do you think it would be feasible to have in the future more than one CPU in the same board, in a cluster-like fashion?

The Natami board is supposed to have a CPU expansion slot.
http://www.natami.net/specification.htm
"CPU expansion slot
Allows upgrade to another CPU (Coldfire/PowerPC/Cell)
SLOT layout will be fully documented to allow 3rd party upgrade designs."

[HenryCase]

Einstein wrote:
the cursed Winblows (and Linsux) does not permit the sweet buggy apps destroy the data of the others (and consequently mine) and kill the OSs, what a shame.

When was the last time this happened to you, and what version of AmigaOS were you using at the time?

[HenryCase]

@JetRacer

The different versions of AmigaOS aren't equally stable, so my question still stands.