Coldfire AGAIN

[bloodline]

I really don't get the obsession with the Coldfire! if you want a small core to use for emulating a 68k... either design one yourself, I made a big post about this in a previous thread... or licence an ARM or MIPS, both of which are smaller, better supported and preferable to the hacked up mess of a CPU that the Coldfire is...

In fact I would go as far to say the MIPS is the better choice, since it has more registers than the 68k, which is a really good idea....

[bloodline]

Here is a good thread to read:

http://www.embeddedrelated.com/usenet/embedded/show/74090-1.php

Nice little quote:

Coldfire looks not so exciting, since it's based on the CISC m68k, though
I gather it's got a cleaned-up instruction set. The AVR32 looks really
cool, like it is designed to be a do-everything architecture... good code
density, DSP capabilities, SIMD capabilities, MMU, Java, wow. It looks
like Atmel is aiming to really shake up the 32-bit embedded market.

> Few these days will care about assembler level code, so choose the best
> uC for the task you have.
>
> Debug support, and tools, will start to matter in many design starts.

Yeah, the thing that's appealing about MIPS and ARM to me is that they are
extremely well-supported by Linux and the GCC toolchain. Also, MIPS is
even cooler cause there are free Verilog implementations to play around
with!

In summery, it would seem the MIPS core is ideal for our task... Verilog cores are free, it's well supported, its design is suited to Register based tasks like emulation... it's small...

[bloodline]

biggun wrote:

bloodline wrote:
I really don't get the obsession with the Coldfire! if you want a small core to use for emulating a 68k... either design one yourself, I made a big post about this in a previous thread... or licence an ARM or MIPS, both of which are smaller, better supported and preferable to the hacked up mess of a CPU that the Coldfire is...

In fact I would go as far to say the MIPS is the better choice, since it has more registers than the 68k, which is a really good idea....

Come on Bloodline,
you could create a higher quality post than this, can't you?

Apparently not... :-(

hacked up mess of a CPU that the Coldfire

WTF? The Coldfire is a very logic, clean design.

The Coldfire is an interesting design, for sure! But if we are talking about a small efficient CPU core for an ASIC/FPGA that is to be used for Emulating a 68k... then the Coldfire offers us nothing.... Unlike the other cores I suggested.

Design one yourself

Very thoughtless proposal.
How many people do you know that can design a fully fledged CPU like the Coldfire, and can do this cheaper than then core is at Freescale?

There are websites full of peoples CPU experiments, on FPGAs... If we want a CPU that is specifically for emulating a 68k, then we could probably design a much better one than the coldfire.

MIPS is the better choice

On what experience do you base your claim?

Only on what I've read... I am a big fan of the MIPS design, I love it's simplicity.

Gave you ever developed for mips?

That's true, I have never developed for MIPS... but I wrote a VM (as a DSP plugin engine) that ended up looking very much like a MIPS, which is what led me to read up about the architecture... and I like the design choices made.

[bloodline]

biggun wrote:

The Coldfire is an interesting design, for sure! But if we are talking about a small efficient CPU core for an ASIC/FPGA that is to be used for Emulating a 68k...
then the Coldfire offers us nothing....

You are aware that you can run 68k code in Coldfire, are you?

I've never had the chance to develop for a Coldfire so I can't say for sure just how 68k compatible it is. I have read the developer documents though.

Yes the Coldfire does not implement ALL 68k instructions natively but it implement many 68k instructions natively.

Many... but the 68k offers something like 1500 possible opcode/operand combinations... The Coldfire seems to lack a significant number instructions (not a problem, as they can be trapped, but a speed penalty none the less), it's missing a lot of addressing modes a big problem with a CISC design like the 68k (still they can be trapped etc...)... now the two big show stoppers for me are the instructions that are functionally different, this would require a proper emulator to correct... and the final thing that puts me off the cold fire... the supervisor mode is totally different, the only way around that is to build a new AmigaOS... or preferably use AROS, if we can get some more 68k devs on board.

Until I get a chance to play with one I can't be convinced from the documentation that the Coldfire is good for our use.

The other day I ran an old AMIGA packer with the Coldfire library and funnily enough there were only 4-5 instructions in the whole binary which were not Coldfire native.

4 or 5? With something like a CPU we can't be vague... programs either work or don't... there is no half measures.

Maybe this was a lucky example but it shows that you do not need to emulate every instruction.
Depending on your application the Coldfire can get away running 90% of the instructions natively.

But HOW do you know which instructions you need to emulate without a full Emulator?

[bloodline]

HenryCase wrote:

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.

Sure... but only if we had our 68k source code... With the functionally different instructions and totally different supervisor mode... you may as well use a CPU that has nothing to do with the 68k... but is better supported...

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?

You buy a licence to use the core, not modify it. You would need the development documents too... and there are reasons why the instructions work differently, it's to get the speed up!!!

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

[bloodline]

HenryCase wrote:

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?

The Coldfire engineers removed all the bits of the 68k that slowed the design down... if you put them back in, you slow the design down.

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

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

Just the external data bus of the 68000... nothing to do with the architecture of the CPU.

[bloodline]

minator wrote:
You need a binary scanner of some form, it scans the binary before you run it and adds in routines to replace the unsupported instructions.

Be a lot easier then writing a full emulator or JIT engine for a different CPU.

Such a solution might run faster than a full emulator... though what you are suggesting is just a JIT, that sometimes spits out the instructions unchanged...

[bloodline]

Karlos wrote:

though what you are suggesting is just a JIT, that sometimes spits out the instructions unchanged.

*cough* Dynamo-style JIT *cough* ;-)

Dynamo (a JIT made by Hewlett Packard) demonstrates the amusing (and at first glance ludicrous) fact that a hotspot JIT can 'emulate' code running the same processor it itself is running on faster than the CPU can run code natively.

The reason this is possible is down to the fact that at runtime you know more state information than you ever did at compile time. Consequently, a lot of if/else/switch/case/for/while etc code ends up taking only one or two possible paths at runtime (compared to many more possible paths at compile time) and unused code paths can be optimised away by the JIT.

The main overhead of any JIT system is the on-the-fly recompilation stage that's kicked off when the system encounters new code. Translating code for one CPU to another can be quite expensive where their architectures are very different. However, when most of your "recompilation" involves simply copying (rather than translating) the original code, that overhead is mitigated substantially.

Using such a mechanism, I expect a current generation coldfire core could run 680x0 code extremely well and without any of the performance problems trapping individual unimplemented instructions cause.

If only there were 24 more hours in my day I'd look at it.

Dynamo is bit more than a JIT :-) since it's more like the front end of a CPU like the Athlon, done in software! Which is out of the scope of this project... especially while we don't know the implementation details of the Coldfire.

If we are to use the coldfire, the the JIT is the only way to go... even though I see this as a good opportunity to rid ourselves of the 68k (no matter how much I like it).

[bloodline]

biggun wrote:

But HOW do you know which instructions you need to emulate without a full Emulator?

Bloodline, you are funny :-)

I like to think so! :-)

You are not to shy to give advices on which CPU to use and rant about the Coldfire, but are you sure that you understood the Coldfire correctly?

I may well rant, but I have stated clearly that I've not actually used a coldfire, ever.

No offence, but the risk that in 68k program runs to problem on the Coldfire is very, very small.

Any risk is too much... but that's not the point, you don't have any detailed stats yet... and I don't intend to test it out myself. Until it's been tested we can't know.

There is however sufficient evidence that the Coldfire is unsuitable. Number one is that no coldfire boards exist for the Amiga, despite it being nearly a decade since the coldfire was released. Number two from what I've read, it doesn't seem so 68k object code compaible...

If you reread the Coldfire manual, you will realize that there nearly no 68000 instructions that are executed differently and could cause a problem.

A good starting point is:

http://www.microapl.co.uk/Porting/ColdFire/Download/pa68kcf.pdf


Cheers

Yes, I've read it :-)

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

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

[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

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

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

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