Welcome, Guest. Please login or register.

Author Topic: ColdFire Project?  (Read 7380 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline downix

  • Hero Member
  • *****
  • Join Date: Jan 2003
  • Posts: 1587
    • Show only replies by downix
    • http://www.applemonthly.com
Re: CofFire Project?
« Reply #14 on: September 27, 2007, 01:58:40 AM »
Well, could a recompilation system do it?  Using AROS you could make an OS which would, rather than JIT emulation, re-compile the apps.  The coldfire is similar enough that it could work.
Try blazedmongers new Free Universal Computer kit, available with the GUI toolkit Your Own Universe, the popular IT edition, Extremely Reliable System for embedded work, Enhanced Database development and Wide Area Development system for telecommuting.
 

Offline Plaz

Re: CofFire Project?
« Reply #15 on: September 27, 2007, 02:09:09 AM »
Quote
Well, could a recompilation system do it? Using AROS you could make an OS which would, rather than JIT emulation, re-compile the apps. The coldfire is similar enough that it could work.


The trouble is those wayward instuctions also may exist in the OS not just the apps. So just like pokemon, you got to catch them all. :-P

Some say JIT is the only way and why bother, but I think a prescann-replace solution could work. It would be similar to the way vmware handles code on non-100% compatibly x86 families.

Plaz
 

Offline downix

  • Hero Member
  • *****
  • Join Date: Jan 2003
  • Posts: 1587
    • Show only replies by downix
    • http://www.applemonthly.com
Re: CofFire Project?
« Reply #16 on: September 27, 2007, 02:12:37 AM »
Quote

Plaz wrote:
Quote
Well, could a recompilation system do it? Using AROS you could make an OS which would, rather than JIT emulation, re-compile the apps. The coldfire is similar enough that it could work.


The trouble is those wayward instuctions also may exist in the OS not just the apps. So just like pokemon, you got to catch them all. :-P

Some say JIT is the only way and why bother, but I think a prescann-replace solution could work. It would be similar to the way vmware handles code on non-100% compatibly x86 families.

Plaz

How would an OS compiled for the Coldfire not run on the Coldfire?  Note, I said AROS, not AmigaOS, so you could compile it for the right cpu faily.
Try blazedmongers new Free Universal Computer kit, available with the GUI toolkit Your Own Universe, the popular IT edition, Extremely Reliable System for embedded work, Enhanced Database development and Wide Area Development system for telecommuting.
 

Offline Plaz

Re: CofFire Project?
« Reply #17 on: September 27, 2007, 02:36:14 AM »
Quote
How would an OS compiled for the Coldfire not run on the Coldfire? Note, I said AROS, not AmigaOS, so you could compile it for the right cpu faily.


Oh, I misunderstood. Yes that would be different. You just have to edit the 68K source code before compiling replacing the offending code with coldfire acceptable code. There are instruction on the web about which instructions you need to replace and how in order to compile 68K code for coldfire.

Plaz
 

Offline jdiffend

  • Sr. Member
  • ****
  • Join Date: Apr 2002
  • Posts: 302
    • Show only replies by jdiffend
Re: CofFire Project?
« Reply #18 on: September 27, 2007, 02:42:20 AM »
Quote

Piru wrote:
@Ragoon
Quote
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.
 

Offline little

  • Full Member
  • ***
  • Join Date: Sep 2007
  • Posts: 223
    • Show only replies by little
Re: CofFire Project?
« Reply #19 on: September 27, 2007, 02:56:49 AM »
Quote
I'd expect to see 400+MHz parts within a few years.

400 Mhz is here! There are already 400mhz v5 coldfire CPUs inside HP printers, oddly enough there is no information about it in the freescale site so I suppose motorola is working closely with HP and have not updated the site since they are selling their entire production to HP (remember new chips are always produced in smaller quantities while they "debug" the production line).
 

Offline Plaz

Re: CofFire Project?
« Reply #20 on: September 27, 2007, 03:06:03 AM »
Quote
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
 

Offline little

  • Full Member
  • ***
  • Join Date: Sep 2007
  • Posts: 223
    • Show only replies by little
Re: CofFire Project?
« Reply #21 on: September 27, 2007, 03:55:06 AM »
Quote
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.
 

Offline tomazkid

  • Full Member
  • ***
  • Join Date: Sep 2004
  • Posts: 123
    • Show only replies by tomazkid
Re: CofFire Project?
« Reply #22 on: September 27, 2007, 03:55:07 AM »
What about the Dragon then?
 

Offline jdiffend

  • Sr. Member
  • ****
  • Join Date: Apr 2002
  • Posts: 302
    • Show only replies by jdiffend
Re: CofFire Project?
« Reply #23 on: September 27, 2007, 07:00:33 AM »
Quote

little wrote:
Quote
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.
 

Offline jdiffend

  • Sr. Member
  • ****
  • Join Date: Apr 2002
  • Posts: 302
    • Show only replies by jdiffend
Re: CofFire Project?
« Reply #24 on: September 27, 2007, 07:04:20 AM »
Quote

Plaz wrote:
Quote
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.
 

Offline Piru

  • \' union select name,pwd--
  • Hero Member
  • *****
  • Join Date: Aug 2002
  • Posts: 6946
    • Show only replies by Piru
    • http://www.iki.fi/sintonen/
Re: CofFire Project?
« Reply #25 on: September 27, 2007, 08:15:22 AM »
@jdiffend
Quote
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.

So how come Elbox Dragon is 040 speeds then?
 

Offline Donar

  • Full Member
  • ***
  • Join Date: Aug 2006
  • Posts: 168
    • Show only replies by Donar
Re: CofFire Project?
« Reply #26 on: September 27, 2007, 08:23:21 AM »
Quote
What about the Dragon then?


Oh i wrote some e-mails to Elbox, one answer said they were polishing drivers, the next they were readying production.
And that was umm, half a year ago.

I fear they showed a Dragon from which only the PCI part was working probably using the 020 of the host A1200. Everybody mentioned that it was slow e.g. on loading Icons.

Quote
I said AROS, not AmigaOS, so you could compile it for the right cpu faily.

Any body here who want's to bring the AROS 68k port out of unmaintained, where it sits for long now?
AROS Kickstart ROM Replacement Phase I



Quote

You just have to edit the AROS 68K source code before compiling replacing the offending code with coldfire acceptable code.

I think the AROS code is in c or c++ so a simple recompile to Coldfire or 68k/Coldfire mixed code should do the trick without editing the source. That only would be needed if the source is in assembler.
<- Amiga 1260 / CD ->
Looking for:
A1200/CF CFV4/@200,256MB,eAGA,SATA,120GB,AROS :D
 

Offline Plaz

Re: CofFire Project?
« Reply #27 on: September 27, 2007, 01:19:11 PM »
Quote
I think the AROS code is in c or c++ so a simple recompile to Coldfire or 68k/Coldfire mixed code should do the trick without editing the source. That only would be needed if the source is in assembler.


Generally Coldfire and 68K code is equal. But some 68K instructions don't exist on coldfire. In other cases (and I'm mega simplifying here) InstructionA makes coldfire turn left, while the same instruction makes a 68020 turn right. 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.

Plaz

 

Offline Plaz

Re: CofFire Project?
« Reply #28 on: September 27, 2007, 01:23:10 PM »
Quote
So how come Elbox Dragon is 040 speeds then?


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.

Plaz
 

Offline Piru

  • \' union select name,pwd--
  • Hero Member
  • *****
  • Join Date: Aug 2002
  • Posts: 6946
    • Show only replies by Piru
    • http://www.iki.fi/sintonen/
Re: CofFire Project?
« Reply #29 from previous page: September 27, 2007, 02:23:22 PM »
Quote
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...