Coldfire - Binary Compatible

[Crumb]

@bloodline

If I am not mistaken, raw performance of intel ARM cpus is half the performance of PPC cpus (even embedded ones).

If I was desgning such a board for classic I would probably choose a low-power PPC chip (as it's very cheap, offers PCI, memory controller, usb and other stuff and could bring the possibility of running MOS/OS4). Or maybe an x86 low-power single-core chip (but this could turn much more complex and expensive).

I guess that interfacing a modern x86 chip to an Amiga classic bus would be quite complex: 0.5 to 1 Ghz memory buses, you would need to build some kind of "northbridge" to communicate the amiga hardware with it... and I think it would be much more easy with an embedded PPC chip (memory bus is slower so board layout is easier), these include nice controllers built in for SATA, PCI, ...

With a 68k->PPC JIT a modern embedded PPC chip running at 1Ghz would probably offer better performance running 68k code than a 68->x86 JIT on a single core low power x86 cpu.

IMHO an accelerator's cpu shouldn't require much more than 18watts.

[pyrre]

@ Piru

None. Whatever the CPU does internally to actually execute the instructions is irrelevant.

correct me if i am wrong. But...
RISC/CISC means the way the OS puts instructions to the CPU, on how to execute operations.

RISC, does'nt that mean the OS uses "redused" instructions to execute a (series of) commands in the CPU, while in CISC the OS uses "complex" instructions to execute a (series of) commands in the CPU....?  

From the link you gave:

When Intel first introduced this technique, they referred to it as a "RISC Core", but soon dropped that term. This is similar to traditional microcode, but differs mainly in the fact that the translation from the external instruction set to the micro-ops occurs asynchronously, so the ALU and pipeline are not lockstepped to the instruction set's instruction boundaries.

That means the Intel x86 cpus are CISC, in the way that the OS sends complex instructions. But the instructions is translatet to "RISC" before execution inside the CPU...

However the coldfire is a true RISC based CPU, in the way it gets RISC instructions from the os...

I am curious. I just don't get what makes the coldfire "incompatible" to run Amiga OS....
And what would it take to make a coldfire work in amiga enviroment...?

[bloodline]

Crumb wrote:
@bloodline

If I am not mistaken, raw performance of intel ARM cpus is half the performance of PPC cpus (even embedded ones).

Don't sprout this 20 year old rhetoric... the performance of a modern architecture is now very dependant upon implementation. The ARM Cortext A8 offers the same MIPS/MHz ratio as the 3 core IBM Xenon, and uses less power.

The big difference between the PPC and the ARM... is the number of companies supplying compatible parts and the amount money being poured into development... i.e. the ARM has vastly more on both counts.

If I was desgning such a board for classic I would probably choose a low-power PPC chip (as it's very cheap, offers PCI, memory controller, usb and other stuff and could bring the possibility of running MOS/OS4). Or maybe an x86 low-power single-core chip (but this could turn much more complex and expensive).

There are plenty of lower power, simple x86 variants that one could use... produced by a range of companies... and in vastly more configurations and with much more support hardware.

I guess that interfacing a modern x86 chip to an Amiga classic bus would be quite complex: 0.5 to 1 Ghz memory buses, you would need to build some kind of "northbridge" to communicate the amiga hardware with it... and I think it would be much more easy with an embedded PPC chip (memory bus is slower so board layout is easier), these include nice controllers built in for SATA, PCI, ...

One would need a "Northbridge" with a PPC too... the PPC offers nothing from a hardware point of view over the x86 in terms of 68k compatiblity... though the PPC does offer Big Endian data format, but that is a software issue... and the ARM offers that also.

With a 68k->PPC JIT a modern embedded PPC chip running at 1Ghz would probably offer better performance running 68k code than a 68->x86 JIT on a single core low power x86 cpu.

No way!!! And certainly not for a decent price.

IMHO an accelerator's cpu shouldn't require much more than 18watts.

Check out the ARM Cortex A8... have a look at the power consumption at 1100Mhz (~2000 MIPS) :-)

[Piru]

@pyrre

That means the Intel x86 cpus are CISC, in the way that the OS sends complex instructions. But the instructions is translatet to "RISC" before execution inside the CPU

Yes. However, new x86 also have native RISC instructions and registers.

However the coldfire is a true RISC based CPU, in the way it gets RISC instructions from the os...

No, it uses CISC instructions, but internally is RISC, just like these new x86 CPUs (just less advanced obviously). Freescale calls it "variable-length RISC architecture". Basically they've ripped out anything too complex, but still support as much of the m68k as possible. Rest must be emulated.

I just don't get what makes the coldfire "incompatible" to run Amiga OS

If you want full compatibility it gets very slow since you need to do full emulation. I discussed the problem >4 years ago here: http://www.iki.fi/sintonen/coldfire-v4-m68k.txt

Even with the latest Coldfire CPUs there are differences in the way some instructions work. These instructions cannot be intercepted via some exception, the results are just different compared to real m68k. Also there are some differences in supervisor mode, too, which pretty much means you're forced to emulate supervisor to get good compatibility. The compatibility figures quoted by Freescale are for user mode code.

[bloodline]

pyrre wrote:
@ Piru

None. Whatever the CPU does internally to actually execute the instructions is irrelevant.

correct me if i am wrong. But...

Ok, I will.

RISC/CISC means the way the OS puts instructions to the CPU, on how to execute operations.

RISC was a design concept, realising that most of a CPU's time was spent executing only a subset of the available instruction set... so designers would be best place to make a small set of simple instructions that executed fast, rather than complex instructions that executed slowly. This trend was compounded by the increasing use of high level languages that used compilers rather than hand crafted ASM.

They also reduced the number of addressing modes to avoid memory access which was getting slower and slower. Thus RISC is better refered as Load-Store.

RISC, does'nt that mean the OS uses "redused" instructions to execute a (series of) commands in the CPU, while in CISC the OS uses "complex" instructions to execute a (series of) commands in the CPU....?  

Err... no.

From the link you gave:

When Intel first introduced this technique, they referred to it as a "RISC Core", but soon dropped that term. This is similar to traditional microcode, but differs mainly in the fact that the translation from the external instruction set to the micro-ops occurs asynchronously, so the ALU and pipeline are not lockstepped to the instruction set's instruction boundaries.

That means the Intel x86 cpus are CISC, in the way that the OS sends complex instructions. But the instructions is translatet to "RISC" before execution inside the CPU...

Due to the Age of the x86 design, it just happened to be a bit RISC like, and quite simple. The 68k on the other hand was the very hight of CISC design.

However the coldfire is a true RISC based CPU, in the way it gets RISC instructions from the os...

The Coldfire is basicly a Load-Store version of the 68k... ie it is missing lots of addressing modes (and a few instructions).

I am curious. I just don't get what makes the coldfire "incompatible" to run Amiga OS....
And what would it take to make a coldfire work in amiga enviroment...?

Ok, it can't address memory in the same way as the 68k... and it is missing some instructions... but all of these can be trapped and emulated... though slowly.

The BIG show stopper is the instructions that are "called" the same as on the 68k, but don't "do" the same thing.

For example, when a 68k program tries to multiply on a Coldfire... it might not get the result it expects!

-Edit- From Piru's post, if the superviosr mode is different (which I didn't know)... then there is pretty much no way you could run AmigaOS on it!

[pyrre]

@ Piru

ok. in other words, if the amiga community were to get a "new" and fast 68K cpu someone would need to create a completely new CPU based on the original 68K core designs...
Or you would just end up like the PPC boards with a 68K companion and a coldfire... And really not gain any significantly speed increase, unless using PPC/coldfire native programs and applications...

What would it then take to get the architecture of the 060 to go 100 mHZ and beyond... (in a "what if" situation, disregarding prices...) or even break the giga HZ barrier?
And perhaps e new motherboard featuring modern designs...
(integrated 16bit audio, network, usb, pci +++)

[bloodline]

pyrre wrote:
@ Piru

ok. in other words, if the amiga community were to get a "new" and fast 68K cpu someone would need to create a completely new CPU based on the original 68K core designs...
Or you would just end up like the PPC boards with a 68K companion and a coldfire... And really not gain any significantly speed increase, unless using PPC/coldfire native programs and applications...

What would it then take to get the architecture of the 060 to go 100 mHZ and beyond... (in a "what if" situation, disregarding prices...) or even break the giga HZ barrier?
And perhaps e new motherboard featuring modern designs...
(integrated 16bit audio, network, usb, pci +++)

I hoestly don't think you could push the 68k design that far... perhaps you could depreciate certain modes and instructions that are slow and complex... mark them as no longer available (but still trap and emulate/execute them)... then spend dev money to streamline the subset of instructions that are easier to pipeline/schedule/decode/whatever... as similar process has been going on in the x86 world for 20 years... and it cost billions of dollars... no one would spend that much on the very dead 68k... it's easier just to run a JIT on a modern CPU.

[darksun9210]

(just to clarify, as i am an idiot)

so in simple terms, the best option would be a miniture System On a Chip board, or something like those VIA C7's running a JIT 680x0 emulator, a bit of glue logic to plug into the CPU slot of whatever machine it's going into?

then you'd also have your northbridge ethernet,pci,ddr ram,sata as a side effect...

not that it is in anyway as simple as that sounds.... :lol:

[bloodline]

darksun9210 wrote:
(just to clarify, as i am an idiot)

so in simple terms, the best option would be a miniture System On a Chip board, or something like those VIA C7's running a JIT 680x0 emulator, a bit of glue logic to plug into the CPU slot of whatever machine it's going into?

Yes exactly... but what you would have is basically a Pico-ITX PC sitting in the Trapdoor of the A1200... for no real reason... since you wouldn't want to use the AGA chipset or the old paula audio... plus you'd want to use a USB mouse and a nice new S-ATA HD... so perhaps all that glue logic between the PC and the Amiga would be simply to use the old Amiga keyboard...

then you'd also have your northbridge ethernet,pci,ddr ram,sata as a side effect...

Yeah, that would be easy with a PC Chipset :-)

not that it is in anyway as simple as that sounds.... :lol:

It's quite simple... it's just pointless to accelerate an old Amiga now....

[Hans_]

hbarcellos wrote:
In my rumble opinion, FPGA is emulation. You code something generic to act like the real thing.
Makes no difference to me to take a x86 laptop with amithlon and TVOUT or a fpga "One chip Amiga".

FPGA is NOT emulation. An emulator gets one machine to imitate another. An FPGA, on the other hand is a big set of gates that can be configured into different circuits. It is not a CPU. You can "program" an FPGA's configuration with different circuits, meaning that you could implement a CPU on it, or some other logic machine. Just because it's not gate-for-gate identical to the original, doesn't make it an emulation. AMD's CPUs aren't gate-for-gate identical to Intel's, but no-one would call them "emulators of the x86 CPU" (which doesn't even make sense).

Minimig and other projects like it, implement an Amiga compatible chipset on an FPGA. You could take the same design and turn it into an ASIC, or even, make a fully-custom chip based on the design.

Hans

[Hans_]

What I think may be confusing people is that the coldfire architecture is close enough to the 68k architecture that a compiler could generate a binary that runs on both. Gunnar von Boehn (a.k.a. BigGun) has already demonstrated this, IIRC. However, that doesn't mean that you can run any old 68k code on coldfire. You won't be able to take the Amiga ROMS and expect it to just run.

Hans

[bloodline]

Hans_ wrote:

hbarcellos wrote:
In my rumble opinion, FPGA is emulation. You code something generic to act like the real thing.
Makes no difference to me to take a x86 laptop with amithlon and TVOUT or a fpga "One chip Amiga".

FPGA is NOT emulation. An emulator gets one machine to imitate another. An FPGA, on the other hand is a big set of gates that can be configured into different circuits. It is not a CPU. You can "program" an FPGA's configuration with different circuits, meaning that you could implement a CPU on it, or some other logic machine. Just because it's not gate-for-gate identical to the original, doesn't make it an emulation. AMD's CPUs aren't gate-for-gate identical to Intel's, but no-one would call them "emulators of the x86 CPU" (which doesn't even make sense).

Well... you are saying that a chip that can be programmed to imitate another chip is different to a peice of software that allows a chip to imitate another chip... while the approach is different they are conceptually the same thing.

Only one approach is cheap and easy to fix bugs... the other requires special hardware and bug fixing is a more involved process...

Minimig and other projects like it, implement an Amiga compatible chipset on an FPGA. You could take the same design and turn it into an ASIC, or even, make a fully-custom chip based on the design.

ok... :-?

[bloodline]

Hans_ wrote:
What I think may be confusing people is that the coldfire architecture is close enough to the 68k architecture that a compiler could generate a binary that runs on both. Gunnar von Boehn (a.k.a. BigGun) has already demonstrated this, IIRC.

So coldfire code that doesn't use the different instructions... will run on the 68k... that's really useful.

68k ASM source code will compile to work on the coldfire... hmmm... great!

However, that doesn't mean that you can run any old 68k code on coldfire.

No... I'll bet that the majority of Amiga code will fail on the coldfire.

You won't be able to take the Amiga ROMS and expect it to just run.

Of course... Coldfire supervisor mode is totally different... so any OS/Driver/lowlevel thingie will fail...

[Crumb]

Don't sprout this 20 year old rhetoric... the performance of a modern architecture is now very dependant upon implementation. The ARM Cortext A8 offers the same MIPS/MHz ratio as the 3 core IBM Xenon, and uses less power.

Well, ARM performance usually sucks compared to normal cpus, just like VIA C7 sucks compared to AMD and Intel cpus. I don't care much about tweaked benchmarks.

The big difference between the PPC and the ARM... is the number of companies supplying compatible parts and the amount money being poured into development... i.e. the ARM has vastly more on both counts.

PPCs are cheap, specially SOC models. Just because Apple charged you a lot of money it doesn't mean PPC is expensive. Just look at the Price of Efikas.

A quick look at wikipedia will show you companies that have licensed PowerPC:

    * Altera - FPGA manufactor
    * Apple ('A' in original AIM alliance), switched to Intel starting early 2006
    * Applied Micro Circuits Corporation (AMCC)
    * Avago Technologies
    * BAE Systems for RAD750 processor, used in spacecraft and planetary landers.
    * Bandai for its Apple Pippin
    * Cisco Systems for routers.
    * Culturecom for V-Dragon CPU.
    * Exponential Technology X704
    * HCL
    * LSI Logic
    * Microsoft, for the Xbox 360 processor, Xenon.
    * Motorola (now Freescale Semiconductor), as part of the original AIM alliance.
    * Nintendo for the GameCube and Wii processors.
    * P.A. Semi.
    * Rapport for Kilocore 1025 core CPU.
    * Samsung.
    * STMicroelectronics for the MPC55xx series.
    * Sony and Toshiba, for the Cell processor (inside the Playstation 3 and other devices).
    * Xilinx - FPGA manufactor, Embedded PowerPC in the Virtex-II Pro and Virtex-4 FPGAs.

There are plenty of lower power, simple x86 variants that one could use... produced by a range of companies... and in vastly more configurations and with much more support hardware.

And these usually suck running 68k JITs because are little endian and lack big L2 cache. These also suck compared to normal x86 chips.

One would need a "Northbridge" with a PPC too... the PPC offers nothing from a hardware point of view over the x86 in terms of 68k compatiblity...

I don't know if you didn't read what I wrote or you didn't want to understand it...

PPC offers a good performance/consumption ratio, a very good price (just look at the price of Efikas). Your claims about low consumption embedded PPCs being expensive are simply ridiculous. Even desktop cpus like 970FX had decent price.

Just for your information... making a board and a "northbridge" that supports buses of 1Ghz is more complex and expensive than making a board that uses an embedded PPC.

68k->PPC JITs are faster than x86 ones. Just compare the speed of a CRAP board like BlizzardPPC, using 60ns SIMMs, no L2 cache etc and the speed of a much more powerful x86 with twice bus clock and faster memory bus.

though the PPC does offer Big Endian data format, but that is a software issue... and the ARM offers that also.

Just software? Come on! If I was doing an A1200 accelerator that would be the most important thing. It would be retarded to create an (expensive) accelerator for A1200 that didn't have good compatibility and performance. Ever wondered why phase5 included a real 060 chip on their CSPPC boards?

If you really don't care about classic software it would be quite stupid to create an incompatible accelerator for such an ancient board.

BTW, not all ARMs are bi-endian

No way!!! And certainly not for a decent price.

An embedded PPC would run 68k JITs way better than any x86 equivalent chip, it would be faster and it would have a similar price.

Then I guess that Efika owners bought their efikas for 99$ and Genesi lost 600$ with each board. Yeah, sure.

Check out the ARM Cortex A8... have a look at the power consumption at 1100Mhz (~2000 MIPS)

Phone me when 68k->ARM JITs are available and when MorphOS and AmigaOS4 runs on ARM.

[Louis Dias]

bloodline wrote:

Piru wrote:
@bloodline

As far as I can tell he didn't, he wants separate, native binaries:

The resultant binary could then be run natively.

Yes you are quite right, he did imply that.

I really can't understand the obsession many on this site have for the coldfire... If I was starting a project, I choose either an ARM or a x86... depending upon the application.

Yes that's what I meant.
Sort of like a JIT, but not actually executing code, just analyzing it's execution, marking offsets and translating into CF compatible version.  If one 68K instruction has to be emulated by 4 CF instructions, then all jump/branch offsets have to be moved up 3 bytes/words thereafter.

The "obsession" with 68K/CF is that if Commodore were to make an A5000, it would be running a Coldfire cpu.  People are looking for a true upgrade path along the "classic" hardware lines.

Have you seen the NatAmi board with the AGA+ chipset?

[SamuraiCrow]

lou_dias wrote:

Yes that's what I meant.
Sort of like a JIT, but not actually executing code, just analyzing it's execution, marking offsets and translating into CF compatible version.  If one 68K instruction has to be emulated by 4 CF instructions, then all jump/branch offsets have to be moved up 3 bytes/words thereafter.

The "obsession" with 68K/CF is that if Commodore were to make an A5000, it would be running a Coldfire cpu.  People are looking for a true upgrade path along the "classic" hardware lines.

Have you seen the NatAmi board with the AGA+ chipset?

If we have to write something that translantes native binaries into another instruction set, then why not use the LLVM Bitcode format?  It has been suggested several times on AROS-Exec.org since it would work on the x86, x86_64, and PowerPC chips as well as others (assuming you don't need the JIT compiler for anything).