ColdFire Project?

[jdiffend]

Piru wrote:
@Ragoon

The coldfire since core V4e is fully compatible with the 68040. The first generation (5102) was already fully compatible with the 68EC040. It is an enhanced version of the originals 68k (410 MIPS @ 260MHz for actual coldfire and 110 Mips @ 75 MHz for 68060).

They are not compatible.

Supervisor mode is totally different. User mode is different, and even with emulation library loaded the user mode has a small difference which cannot be trapped.

Piru is correct on this.  You need to rewrite the ROM to be able to take advantage of even a 4e Core Coldfire.

FWIW, I don't think the author of the Coldfire project had the proper background to complete such a complex design but that's just my opinion.

The biggest problem is that to really use the coldfire you need the OS source code so you can make as much if it coldfire native as possible.  The OS would also take up more space since more instructions are needed to do the same thing.

*IF* you rewrite the exec, timer device and some other stuff that's needed just to get the computer started then you can think about using the illegal instruction trap to emulate missing instructions.  BTW, someone took the commented disassembly of the exec I made and got it running on a V2 developer board but I haven't spoken with him in a LONG time so I'm not sure what ever became of it.

The addressing modes that can't be emulated were slow and I'm guessing were rarely used (certainly not by most compilers) but the math instructions that are legal but function differently are bound to create some problems.  Since identical behavior isn't always required some software would work and some wouldn't.

People that claim a Coldfire wouldn't be faster than an 060 either haven't looked at the benchmark info from Motorola or they are just ignoring it.  Extensive code analysis of millions of lines of code showed *at most* a 30% performance drop emulating existing 68K code on older Coldfire chips (V2 core).  I also believe that was 68000 code, not 060 code which has fewer incompatibilities.  Even if their estimates are optimistic the 4e has added many more instructions and addressing modes over the V2 so it should run 68k code much faster than the V2.  Software should be over twice as fast on the 260MHz 4e than on the 75MHz 060.  Anything that could be recompiled to native coldfire code would run over 3 times as fast and that's if they don't introduce faster clock speeds.  They have mentioned faster clock speeds in the past so I'd expect to see 400+MHz parts within a few years.

[jdiffend]

little wrote:

But you'd have to recompile, which isn't an option for the vast amount of legacy software.

But if the (AR)OS is coldfire native then you could emulate legacy software, look how apple emulated 68k System 9 inside PPC OS X, this will be even better because coldfire is a progression of the 68k architecture, not a complete rewrite like the PPC. So maybe the older games or games that used a lot of tricks might not run or run slowly, bugs in the emulation can be removed with time and you would have a modern OS with modern (at least open source) applications and maybe even some games. Of course we need someone to build such a machine, with a PowerVR chipset for graphics if posible to deliver modern graphics. At least I think that it would be cheaper to build a complete machine anyone can buy than to make an upgrade card aimed to a shrinking market.

Well, there could be several kinds of emulation.  

1. Most instructions are run natively and most unsupported instructions or addressing modes are trapped and emulated by an illegal instruction trap, then execution continues normally until the next one.  This would be very fast but probably have 10%-20% slowdown from coldfire safe code and it won't run everything.  The code to do this already exists.

2. 100% emulation of the program but OS calls are executed natively by the emulator.  Faster than full emulation but slower than the first or last method.  The code could probably be extracted from an existing Amiga emulator.


3. 100% emulation with JIT generation of equivalent instruction sequences.  It would run any 68k code but would require a lot of work.  OS calls would be native and the JIT wouldn't need to examine them.

[jdiffend]

Plaz wrote:

There are already 400mhz v5 coldfire CPUs inside HP printers, oddly enough there is no information about it in the freescale site

Freescale will make custom coldfires to suit your needs. Maybe HP walked in with a bag of money and said... "we need one that does this", and freescale built them one to HP's specs. Too bad amigaland doesn't have the same kind of resources. We're stuck with normal wares off the shelf. ........ Heeeeyyyyy, what if DiscreetFX.......... nah.

Plaz

I knew the V5 had been scheduled to be done by now but wasn't aware it was out yet.  HP will probably have first dibs on chips for a while.
If I remember right, the V5 was supposed to be fully superscaler so it should be faster than the 4e at the same clock speed.

It's hard to compete with a company that orders 10000 or more chips at a shot.

[jdiffend]

Piru wrote:

Some say they are probably burning much of their cycles running a JIT compiler to handle those instruction differences I mentioned between CF and 68K.

Possibly. However, accoding to jdiffend it should be at least twice as fast as 060@75, by just using the stock emulation library (no JIT). That just doesn't add up... :-)

Lie, bigger lie, benchmark by the manufacturer...

Those benchmarks were for the CPU running native code for the interrupt handlers with 68k applications.

People say it's running at 020 speeds... hmmmm... and it's in a machine with an 020.  Makes you wonder doesn't it?  Was the Coldfire even doing the work?

Perhaps they are running 100% emulation which would be the slowest.  They probably couldn't get enough compatibility to run the OS with the stock emulation library.  Which is why I said you need the OS source so you can rewrite it.

I worked on a project based on the 64180 where illegal instructions were used to replace instruction sequences that were commonly generated by a C compiler and the slowdown was about 20% on it so I don't doubt the manufacturer's estimates.  However, if the exec also has to use the lib it will be slower... I think the slowdown was 50%.  That's why I said the OS had to be Coldfire native code.  

Even if some of the OS has been converted to native code, if certain parts aren't you might start stacking interrupts or have other unpredictable interaction between hardware and software.

Remember, any instruction that is native to the Coldfire runs at 266MHz.  That's actually most of the 68k instruction set and addressing modes.  Then you have, oh... say a penalty of 20+ instructions when you hit one that isn't.  But remember... the 4e is partially superscaler so it gets around 1 instruction / clock cycle or better.  Even if it takes 20 clocks to emulate 1 instruction it's still going to avarage out to faster than an 020.

I noticed Oli posted that the V5 core was ready for release in 2002.  I'd guess HP offered big bucks to have an exclusive on it for several years.

[jdiffend]

Donar wrote:

To make clean coldfire builds, you'll need to edit legacy 68K code to replace these missing and misinterpeted instructions. Luckily the list of edits will probably be small.

From C++ Source you only need to set Coldfire as target for the compiler - it will avoid "bad" instructions then.

If you have Assembler source you have to run it through "PortASM" (tool provided by freescale) or pick the bad ones out by hand and replace them.

Another option, if you don't have the source, would be to disassemble an executable pick out the "baddies" and assemble it to an executable or provide a patch file for the original executable. That probably is the least desired thing.

That's at least how i understood it.

It was my understanding that port asm didn't perform any optimization so it increases code size significantly.  And I'm not sure if it was ever updated for the 4e core... I haven't looked at it in years though.

[jdiffend]

little wrote:

Possibly. However, accoding to jdiffend it should be at least twice as fast as 060@75

I am no expert, but this probably has to do with the coldfire having to use the s-l-o-w chip ram inside the a1200, that is another reason to put the coldfire inside a completely new aros machine.

If the Coldfire has to use 25MHz RAM it's going to run at 25MHz whenever it accesses it.  ROM access will be slow as well (where most of the OS is).  If the Coldfire board has fast RAM on it, it should run at full speed there.
You'd have to move the ROM to RAM to get any kind of speed out of the thing.

Really, the Amiga was never designed with that fast of a CPU in mind.  To completely take advantage of that fast of a CPU you almost have to redo the entire architecture.  At the very least you'd have to run the buss at several times the speed and give the chipset access to 1 out of how ever many cycles to make it run at stock speed when in compatibility mode.

[jdiffend]

little wrote:

1. Most instructions are run natively

I think this is the best method for any application

Yes but illegal instructions are trapped and emulated.  Not everything can be trapped and it's slower than Coldfire safe code.

2. 100% emulation of the program with native OS calls

I do not undestand what advantage this method has over #1 or #3 :-?

Not all differences between the Coldfire and 68K can be accounted for with #1.  Some addressing modes can't be emulated because the illegal instruction interrupt doesn't occur in a place where you can go back and decode the instruction properly.  And some math instructions have different behavior in regards to setting flags but they are perfectly legal so they can't be trapped.
100% emulation avoids those problems but it's slow.

3. 100% emulation with JIT

IMO this would be the best method for running games, creave a virtual amiga in the workbench, like winuae but integrated into the OS.

Everyone probably agrees... but it's complex and takes time to write.

[jdiffend]

mumule wrote:

4. Put the cpu into an FPGA, and debug it. At the end of the day it is easier to do a CPU right, then debug all application code ...

And you are stuck running at under 40MHz because it's not an ASIC.  

[jdiffend]

Piru wrote:
@Hans_

Wasn't there a tool to convert 68k assembly to coldfire assembly? If there is one, it should be possible to create coldfire binaries for the whole OS using a suitable disassembler and this tool.

Not easily.

You'd need to manually disassemble everything in a way it can be recompiled. This is highly demanding work which requires tons of assembly knowledge and time. It cannot be automated.

Actually, the disassembler I used to make the commented 2.? exec disassembly generated code that could be reassembled.

A program could be written to take that, make the patches with the existing tool and then optimize the code to remove stuff that isn't needed.  
It would need to use register tracking similar to a modern optimizing C++ compiler AND would need to trace flag usage.  
It would take a LONG time to build such a beast from scratch.  I've spent some time in the guts of a few C compilers and it's not easy work... then add some stuff those don't have to do and it's a huge undertaking.  All for a computer that has been off the market for over a decade.

[jdiffend]

potis21 wrote:
why not ask freescale just to... scale a 68040 into new integration technology and just implement more L1 and L2 ?

Wouldn't it be just the most compatible solution?

smaller photomaster is the way to go.

New technologies woud allow the raw 400 MHz out of the processor just by scaling the design and reducing operating voltage and will have a totally analog performance ratio.

Amiga Community - "hey freescale, could you recreate the 68040 in a modern die process so we can run it at higher speeds?  And add some more cache while you are at it."

Freescale - "The die needs a rework to switch to a smaller die process since things don't just directly translate as is and it would need to be modified anyway to change the cache.  None of the original designers are still with us and it would require orders for several hundred thousand to make it economically feasible.  It would also take several man years of work.  How many did you want?"

Amiga Community - "A couple hundred... maybe even a thousand!"

Freescale - "Have you looked at the coldfire?"



Just switching the die process does not guarantee 400MHz.  All other CPUs have undergone significant design changes to the architecture to accommodate faster speeds.  And often products are delayed for months to adapt to a new die process because not everything works the same.
Remember, they abandoned the 68K line BECAUSE it wasn't scalable.

Oh, and that's before you have to interface the beast to the Amiga.  Just plugging it into an existing 040 board gains you nothing.

[jdiffend]

Piru wrote:
Exec is quite trivial, it only has couple of arrays in it (which has relative offsets in them).

LOL, trivial he says.  

It gets much hairier with complex code that has baserel references, or even worse references with varying base. Those are pretty much impossible to resolve without actually executing the code.

Another problem is that you can't always be sure what is code and what is data. Automation will not get that right every time.

So while it might work for some random samples, it might easily produce sourcecode that while building ok, actually produces broken code, in worst cases in a way that it doesn't crash, but rather just generate bogus results.

There is no way to workaround this via automated software. Human interaction and guidance is required.

Well, I wouldn't ever say "no workaround" as an absolute but from some of the stuff I've disassembled... it definitely requires some human involvement.  Resource(?) was a pretty good tool but I think it could have had more automation than it did.

As Amiga becomes more and more worthless we could buy up the company and have the source code.   :-D

[jdiffend]

mumule wrote:

jdiffend wrote:

mumule wrote:

4. Put the cpu into an FPGA, and debug it. At the end of the day it is easier to do a CPU right, then debug all application code ...

And you are stuck running at under 40MHz because it's not an ASIC.  

Not really. for next year already you should hit 100-200 MHz.
There are enough 32bit cpus in FPGAs which can prove that.

All the affordable FPGAs seem to be able to manage with 8 bit cpu core's is 25MHz.  I've heard of one doing 40MHz but I'm sure it's on a faster FPGA too.  The fastest FPGAs are very expensive and *might* make those speeds possible but the FPGA alone would cost much more than most people would be willing to spend.

Not only that but just because there are cores that do it doesn't mean it was easy getting one to do it.  One of the biggest problems in achieving those speeds with a CPU core is you just about have to have a pipelined architecture with cache, burst mode RAM access... all sorts of stuff.  It's not just a simple core like most of the ones you can download.

Now, if you could afford to have a custom ASIC made... there is a Z80 core that has been made to run over 400MHz so it's definitely possible with an ASIC.  And that *is* a core you download.