Coldfire AGAIN

[biggun]

Karlos wrote:

I seem to recall, but I may be wrong, the problem is that certain opcodes actually behave differently to the same operations on m68k. That is to say, they are implemented but operate slightly differently to the 680x0.

Can you give a real example, or is this a hear say rumor mill?

[Karlos]

biggun wrote:

Karlos wrote:

I seem to recall, but I may be wrong, the problem is that certain opcodes actually behave differently to the same operations on m68k. That is to say, they are implemented but operate slightly differently to the 680x0.

Can you give a real example, or is this a hear say rumor mill?

Well, for one, I seem to recall that MULS and MULU fail to set the overflow bit of the condition code register.

If your 68k code looks at the CCR to see if an overflow occurred after a multiplication and perform some specific action, it isn't going to behave the same on both CPU's under all circumstances.

There were a few other nuances like this, but I'd need to check and don't have time.

[Methuselas]

Personally, I'd rather see a core duo accelerator with a ram boost and a JIT emulator, a la Amithlon. With the custom chip code removed, that sh!t flies. *THEN* we could also do away with the AROS 68K and just use the X86 code, with minimal updates (I assume here - I'm a graphic designer. I'm not a coder).

Wouldn't it be more prudent to build a new accelerator card that *WASN'T* a 68k, but something more modern? Seriously. All joking aside, our Miggy's aren't getting any younger and there's no way in hell most of us could afford a "new" amiga anyways. I like the Clone A and I really like the NatAmi, but I want something faster than a 68k. I understand that these engineers are working in their own time, doing something they love and want to do, but I can't afford the prices of all this new hardware for a hobby machine. That's why instead of buying a MiniMig, I just got (a free, no less) A500 that does all my retro needs, so far.

That's just me, though.

Someday, I'm going to win the lotto and when I do, it's on.  :lol:

[Oli_hd]

Well, for one, I seem to recall that MULS and MULU fail to set the overflow bit of the condition code register.

Correct but the 68Klib provided free by freescale can emulate these instructions, you simply have to add an instruction before it to trigger the CPU's invalid instruction trap and then the emulator will give you a fully 68K compatiable MULS and MULU. (the other instructions are the DIV ones I think)
This wouldnt need to be done at compile time, a program could be wrote to insert the trap code into a binary file at the correct places.

/me goes back to watching all the Coldfire threads

[Karlos]

Oli_hd wrote:

Well, for one, I seem to recall that MULS and MULU fail to set the overflow bit of the condition code register.

Correct but the 68Klib provided free by freescale can emulate these instructions, you simply have to add an instruction before it to trigger the CPU's invalid instruction trap and then the emulator will give you a fully 68K compatiable MULS and MULU. (the other instructions are the DIV ones I think)
This wouldnt need to be done at compile time, a program could be wrote to insert the trap code into a binary file at the correct places.

/me goes back to watching all the Coldfire threads

Doesn't that change the length of the instruction stream? If so, presumably you then need to update all the branches too?

[bloodline]

Oli_hd wrote:

Well, for one, I seem to recall that MULS and MULU fail to set the overflow bit of the condition code register.

Correct but the 68Klib provided free by freescale can emulate these instructions, you simply have to add an instruction before it to trigger the CPU's invalid instruction trap and then the emulator will give you a fully 68K compatiable MULS and MULU. (the other instructions are the DIV ones I think)
This wouldnt need to be done at compile time, a program could be wrote to insert the trap code into a binary file at the correct places.

And recalculate the offsets...? what about checksums... I think this idea is really difficult!

/me goes back to watching all the Coldfire threads

You have the most experience with the CF on this board you should say more!!

[Rob]

@Methuselas

Thomas intends to make information on the CPU slot available to third parties, so they can create their own accelerator cards.

[Karlos]

bloodline wrote:

You have the most experience with the CF on this board you should say more!!

Quite.

[biggun]

Karlos wrote:

Well, for one, I seem to recall that MULS and MULU fail to set the overflow bit of the condition code register.

To be precise here:
The 68000 instruction MULS.W did NEVER set the overflow bit on 68K.
This instruction is working 100% the same on the Coldfire.


The instruction that you are referring to is the muls.L and this instruction was 68020 only!
Programs compiled for 68000 could never include this instruction.
So if you have an A500 program this isssue can never show up.

BTW if muls.L does set the overflow then the calculate is 100% wrong anyway and their is NO way of recovering from it!
The only way to correct this it is using a the 64bit MUL instruction or proper multiplication routine.

The proper usage for this instruction is only to use it when you values will not overflow. And in this case the Coldfire version will work 100% the same.

Please remember, that the issue that you are referring too does not exist for A500 programs.

[bloodline]

biggun wrote:

Karlos wrote:

Well, for one, I seem to recall that MULS and MULU fail to set the overflow bit of the condition code register.

To be precise here:
The 68000 instruction MULS.W did NEVER set the overflow bit on 68K.
This instruction is working 100% the same on the Coldfire.


The instruction that you are referring to is the muls.L and this instruction was 68020 only!

I have a lot of 020+ software... since I had my A1200 much longer than my A500, if I ever had the option I went for the 020+ version of a program.

Programs compiled for 68000 could never include this instruction.
So if you have an A500 program this isssue can never show up.

I cannot fault your logic here... but your design is supposed to be SuperAGA... If we were discussing the MiniMig then I think I would agree with you, that the coldfire might be a good solution.

BTW if muls.L does set the overflow then the calculate is 100% wrong anyway and their is NO way of recovering from it!
The only way to correct this it is using a the 64bit MUL instruction or proper multiplication routine.

The proper usage for this instruction is only to use it when you values will not overflow. And in this case the Coldfire version will work 100% the same.

Please remember, that the issue that you are referring too does not exist for A500 programs.

But the NetAmi is intended to supersede the A1200/A4000, not the A500...

[Karlos]

biggun wrote:

BTW muls.L would calculate wrong of you get the overflow and their is NO way of recovering from it besides using the 64bit MUL version or a proper multiplication routine.
In other words if your code can overflow you will never use this instruction in the first place.

I think you'll find it's used in most 68020+ compiler-generated code where the effects of overflow aren't really defined by the language standard.

In hand coded ASM, you would still use it for example if you are writing saturation-based fixed-point arithmetic routines for some visual or audio application. You'd optionally fill the result with your maximum fixed point value on overflow.

The issue that you are referring too does not exist for A500 programs.

Perhaps, but it is possibly not the only such difference. Anyway, I would have thought that 68020 would be the base level for any 'revived' m68k amiga platform (other than minimig)? After all, you need 68020 compatibility to be able to run OS3.5/3.9, right?

Isn't the NatAmi going for minimum of AGA compatibility? I'm unaware of any working plain 68000+AGA hardware combination.

[biggun]

Karlos wrote:

biggun wrote:

BTW muls.L would calculate wrong of you get the overflow and their is NO way of recovering from it besides using the 64bit MUL version or a proper multiplication routine.
In other words if your code can overflow you will never use this instruction in the first place.

I think you'll find it's used in most 68020+ compiler-generated code where the effects of overflow aren't really defined by the language standard.

But in this case the MUL.L of Coldfire will behave correct too.

Its clear that there can be some a certain number of cases where this behavior was expected and where the saturation will not hit.

The fact is that A500 application are not 100% unaffected of this.
And if you think about it you will agree that over 95% of all 68020 games / applications are certainly not using this affected sequence too.

So what is the effect: 100% of A500 games unaffected.
And if 1 out of 100, A1200 applications is affected, how terrible is this?


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.

[AmigaHeretic]

Methuselas wrote:
Personally, I'd rather see a core duo accelerator with a ram boost and a JIT emulator, a la Amithlon. With the custom chip code removed, that sh!t flies. *THEN* we could also do away with the AROS 68K and just use the X86 code, with minimal updates (I assume here - I'm a graphic designer. I'm not a coder).

Now just bare with me a minute!

Can't we just buy something off the shelf like this....


It takes a CORE 2 Duo processor.

Now what I'm talking about is the ONLY thing on this board that is change are the BIOS chips.  Basically the BIOS ROMS are modified to include an Amiga Emulation layer.  Sort of like Amithlon included in BIOS. Or UAE included in BIOS!

BAM!!  A new Amiga motherboard!  

That's all I want.  When I power it on, it comes to a Kickstart screen.

[bloodline]

AmigaHeretic wrote:

Methuselas wrote:
Personally, I'd rather see a core duo accelerator with a ram boost and a JIT emulator, a la Amithlon. With the custom chip code removed, that sh!t flies. *THEN* we could also do away with the AROS 68K and just use the X86 code, with minimal updates (I assume here - I'm a graphic designer. I'm not a coder).

Now just bare with me a minute!

Can't we just buy something off the shelf like this....


It takes a CORE 2 Duo processor.

Now what I'm talking about is the ONLY thing on this board that is change are the BIOS chips.  Basically the BIOS ROMS are modified to include an Amiga Emulation layer.  Sort of like Amithlon included in BIOS. Or UAE included in BIOS!

BAM!!  A new Amiga motherboard!  

That's all I want.  When I power it on, it comes to a Kickstart screen.

Sure, AROS with this:

http://openbios.info/Welcome_to_OpenBIOS
http://www.coreboot.org/Welcome_to_coreboot

:-D

[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

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