Coldfire AGAIN

[bloodline]

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 :-)

[Karlos]

So what it the real effect?
A few, very limited number of tools might become buggy.
But 99% of the AMIGA application will run correctly on Coldfire.

This is how it really looks like.

That some people state that the Coldfire is not possible to
run 68k code is certainly a 100% overstatement.

I don't think anybody is saying the Coldfire can't run 68K code, I think they are saying AmigaOS and applications may not work readily on coldfire. In addition to the behavioural differences mentioned, how many byte and word size logic/arithmetic operations are there in typical amiga 68K object code that are not directly supported on coldfire (existing only as long version)? It may be the case that there will be more trap and emulation overhead than you think.

Remember, some applications using 64-bit integer multiplication on 020/030/040 ran like treacle on the first 060 cards that relied on trap-emulate (anybody remember Breathless) ?

I'm not saying that you can't run a coldfire based Amiga system but I really do think the difficulties are more than you seem to admit. There are a lot of things to consider beyond basic instruction implementation counts.

So far we've only looked at the user mode. Coldfire supervisor mode is a bit different and if I recall clearly, it doesn't have a separate supervisor stack pointer. This might not sound a big deal but it does have very real implications.

Any code that writes local data below the current stack depth (eg using negative offsets from a7), whilst working perfectly on a 680x0 Amiga, risks having that data trashed by an interrupt on a coldfire system. This might sound unlikely, but in fact code that has been optimised not to use stack frames within function may well assume it can safely use address modes such as -4(a7) etc to hold local variables (if it doesn't need to immediately call another function) rather than decrementing a7 first and using positive offsets for them, thus typically saving instructions to modify a7.

Can you say with certainty that the 100% of A500 applications you refer to as being compatible aren't doing anything like this?

[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

[bloodline]

HenryCase wrote:

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

You wish! :-)

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...

[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?

[bloodline]

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.

-Edit- And the 68k has variable length instructions... The parasite doesn't have a hope in hell's chance of ever correctly identifying the Code.

[biggun]

Karlos wrote:

So far we've only looked at the user mode. Coldfire supervisor mode is a bit different and if I recall clearly, it doesn't have a separate supervisor stack pointer. This might not sound a big deal but it does have very real implications.

[...]

Can you say with certainty that the 100% of A500 applications you refer to as being compatible aren't doing anything like this?

This is no problem.

You are referring to the very first Coldfire versions.
The V4 and V5 Coldfire have two  a separate supervisor stack pointer.

[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

[Karlos]

biggun wrote:

This is no problem.

You are referring to the very first Coldfire versions.
The V4 and V5 Coldfire have two  a separate supervisor stack pointer.

That's good. What other incompatibilities do they address?

[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."

[bloodline]

HenryCase wrote:

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

Hmmm... this is going to turn into CPU 101... 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).

Since the CPU made the the request, it knows what will be delivered on the bus. Anything watching the bus won't know what is being transmitted.

[biggun]

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.

-Edit- And the 68k has variable length instructions... The parasite doesn't have a hope in hell's chance of ever correctly identifying the Code.

The 68k "flags" instruction fetched on the debug pins. (Harvard Architecture).
So yes, you can from the outside distinguishe data from code fetched.

Saying that the idea of the paraside is not worth doing, as its much to complicate for the possible benefit.

If you really want to do a lot of work then you would rather alter the Coldfire core directly.
BTW, why did your claim that you are not allowed to change the Coldfire if you buy it?


I think the real story is that you would not want to change it - as its too much work.

The Coldfire is quite fast and powerful as it is.

[Karlos]

@HenryCase

Drag(-)on, ey? Elbox don't seem to be in a rush to release it...

[bloodline]

biggun wrote:

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.

-Edit- And the 68k has variable length instructions... The parasite doesn't have a hope in hell's chance of ever correctly identifying the Code.

The 68k "flags" instruction fetched on the debug pins. (Harvard Architecture).
So yes, you can from the outside distinguishe data from code fetched.

Does the Coldfire have MM capabilities of that scale?

Saying that the idea of the paraside is not worth doing.

BTW, why did your claim that you are not allowed to change the Coldfire if you buy it?

You know full well that when you licence a core you don't buy the right to modify it. That was the reason why the Amiga Team chose the PA-RISC, because HP did allow the licensee of the Core to modify it.

I think the real story is that you would not want to change it - as its too much work.

I stated that in my original post on the subject.

The Coldfire is quite fast and powerful as it is.

We have yet to see proof of this!

[bloodline]

Ok... here is a CF emulator... lets see what it can do...

http://www.slicer.ca/coldfire/

[mongo]

biggun wrote:

The 68k "flags" instruction fetched on the debug pins. (Harvard Architecture).

ColdFire doesn't.