Coldfire - Binary Compatible

[bloodline]

lou_dias wrote:
Why couldn't a 68K be virtualized and then fed the binary, then the virtual68k could make the determination and in the background, the app is repackaging the binary in a Coldfire-compatible way.  The resultant binary could then be run natively.

Replace the word Coldfire in the above sentence with x86, and you have an easier, cheaper and more powerful solution.

[bloodline]

AeroMan wrote:
Intel AAAAaaarrrgghhh......    :-D

Why use a Intel in the Amiga ? Buy a PC and use AROS, UAE or both. Cheap and easy.

I quite agree.

Conecting an Intel compatible to the Amiga will be way more expensive than a small PC.

Damn right!!!

If something should be used to do that, I believe it should be a PPC or a 68K compatible. (this is where the fun is at...)

Well, a 68K is fine... that's what the Amiga was designed around... Using a PPC is just as hard as using an x86...

[bloodline]

Piru wrote:
@lou_dias

Why couldn't a 68K be virtualized and then fed the binary, then the virtual68k could make the determination and in the background, the app is repackaging the binary in a Coldfire-compatible way. The resultant binary could then be run natively.

Because it is impossible to tell whether certain part of the binary is code or data.

If I understood correctly you're suggesting here that the program would be run and that the executed parts would be translated? This doesn't work: There is no way to get any given program to run all code paths.

The only way is to do the translation on the fly: JIT.

I thought he was suggesting a JIT... :-D

[bloodline]

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.

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

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

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

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

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

[bloodline]

-Edit- this post isn't meant to sound as aggressive in tone as it does... :-)

Crumb wrote:

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.

ARM performance sucks... Ok... you get any of the current PPC implementations to run UAE at in full A500 compatibility mode on a 1000mAh battery for 2 hours... That wasn't a problem for my old Xscale 3years ago.

My old EPIA 800MHz can run the latest WinUAE perfectly!!

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.

Because SOC systems are known for their performance :roll:

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

So what... companies buy the IP core from IBM/Freescale/Whoever... there are far more using ARM... I'm not trying to big up ARM here... it's jsut a fact... The PPC is a well proven/documented architecture with plenty of dev software. It's quite attractive... but I don't see as much of a future as the ARM.

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.

Really... I think you need to read up on the new 45nm chips from intel...

They run the UAE JIT fine!

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

It's possible I didn't understand, I'm very tired at the moment.

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.

The PPC offers a mature platform for a company that wants to put a CPU core on their ASIC... but I don't see much advantage for a company wanting to build an accelerator for an Amiga.

A x86 or ARM will be cheaper and more long term solution...

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.

No it isn't. Just buy a NB off the shelf, and build a PCI-Amiga CPU slot bridge... not the easiest task, but you'd have to do that for either x86 or 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.

That is a pointless paragraph... my £30 2.5Ghz Athlon64 can run a JIT sooooo much faster than my 240Mhz BlizzPPC... so what?  

If we are going to talk cost/performance... nothing even comes close to the x86... nothing can... the shear amount of development and scale of production, can't be matched.

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?

The biggest flaw with the PPC boards... they should never have had a 68k on them. I guess they needed to ensure good compatibility, and didn't have enough time/money to develop a 68k emualtor that would have allowed AmigaOS to run on the PPC and still be able to match the timings properly... it's not an easy task!

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.

Not true, especially if you add in the cost of the support hardware.

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

Of couse not... but for $150 I could buy a x86 system that would wipe the floor with the Efika in terms of performance... but the efika isn't designed for performance it has other priorities.

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.

Ok... that's true, I don't know of any 68k->ARM JIT! But I will call you as soon as I find one :-)

[bloodline]

Hans_ wrote:

bloodline wrote:

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

It's quite difficult to explain this clearly to people who don't know exactly what an FPGA is. People implementing circuits in an FPGA use some of the same tools that chip designers use to design fully custom chips (minus the IC transistor layout tools).

;-)

Yes, I'm well aware of FPGAs... I think they are great... but my point is that A PC is essentially functionally exactly the same as an Amiga.

It has a Keyboard and a Mouse, for input.... Video and Audio for output... and a diskdrive for storage. THe PC and the Amgia re functioanlly identical devices, they just work differently internally. But a piece of software, the emualtor, can make one device work from an (external point of view) identical internally...

If you see what I mean...

[bloodline]

Hans_ wrote:

bloodline wrote:
Yes, I'm well aware of FPGAs... I think they are great... but my point is that A PC is essentially functionally exactly the same as an Amiga.

It has a Keyboard and a Mouse, for input.... Video and Audio for output... and a diskdrive for storage. THe PC and the Amgia re functioanlly identical devices, they just work differently internally. But a piece of software, the emualtor, can make one device work from an (external point of view) identical internally...

If you see what I mean...

Sorry, I don't see what you mean. How does your point make an implementation of hardware in an FPGA an emulation? Whether it's an emulation or a clone depends on the internals not the external appearance.

Hans

Ok... We will use your Paula example, it is a good example.

Paula is a Chip, and FPGA is a chip.

They are both devices that send and receive electrical signals.

Paula responds to electrical signals in a set way, as defined by its internal design.

The FPGA can be programmed to respond to the electrical signals in an identical way.

Both chips now, from an external point of view are identical. Even though their internal implementation maybe different.

But the Amiga is a complete computer it's a device that receives human input and responds in a set way as defined by its internal design using outputs human compatible signals. The PC is the same.

The PC can be programmed so that it can respond to the human interaction (I include software as a very abstract form of human interaction here) identically using outputs human compatible signals.

As far as the human concerned external to the devices, they are identical.

So when we want an Amiga compatible solution to a problem, we can look at the lowest level of what can be called Amiga... that is a complete device made up from smaller chips, but a complete device none the less. So it is a sensible idea to take a similar device that can be programmed to work like the Amiga, rather than go one level down and do essentially the same thing at a chip level.

All I'm sugegsting is that you should look at a problem from the most practical level... not that FPGA's are bad... but the Emualtor and the FPGA are doing the same thing but at different levels of the problem.

Sorry to be so verbose.

[bloodline]

Crumb wrote:

My old EPIA 800MHz can run the latest WinUAE perfectly!!

And an Efika running MorphOS would run rings around it when running Amiga m68k code.

Maybe it would... I don't have an Efika to test... but my EPIA is 6 years old and only cost just over £100 back then... it runs rings around my 25Mhz 040... but has full compatibility with my A1200...

The PPC is a well proven/documented architecture with plenty of dev software. It's quite attractive... but I don't see as much of a future as the ARM.

The 3 biggest console producers have jumped to PPC boat so I don't agree.

They are not going to see these CPU's and we are seeing more and more reliance on extra hardware (Stream processors, SPU, etc...)

Really... I think you need to read up on the new 45nm chips from intel...

I doubt they offer the same performance per watt running emulated m68k code or running PPC code (OS4 and MorphOS are attractive to Amigans, don't you know?)

They really will outperform any PPC Performance per watt, as for PPC code... well I don't really care about that :-)

The PPC offers a mature platform for a company that wants to put a CPU core on their ASIC... but I don't see much advantage for a company wanting to build an accelerator for an Amiga.

Running AmigaOS3/OS4/MOS software perhaps?

We don't have the resources to develop our own ASICs... let alone the HiSpeed devices that we would need.

A x86 or ARM will be cheaper and more long term solution...

I doubt it.

I don't

That is a pointless paragraph... my £30 2.5Ghz Athlon64 can run a JIT sooooo much faster than my 240Mhz BlizzPPC... so what?

That is a pointless reply as you would never put a power hungry Athlon64 in an A1200 accelerator.

But you would put a PPC 970  - G5?

If we are going to talk cost/performance... nothing even comes close to the x86... nothing can... the shear amount of development and scale of production, can't be matched.

I was talking about Amiga accelerators (that need to be low-power and run m68k and PPC software) and you have started  talking about x86 vs PPC.

Oops... I didn't mean to drag this off topic... I just think the PPC or the Coldfire are not best suited to the task...

The biggest flaw with the PPC boards...

The biggest flaw would have been investing 800€ on an accelerator with no software. No one would have bought it.

True.

they should never have had a 68k on them. I guess they needed to ensure good compatibility, and didn't have enough time/money to develop a 68k emualtor that would have allowed AmigaOS to run on the PPC and still be able to match the timings properly... it's not an easy task!

Running the entire OS under emulation wouldn't have been fun

No, exactly... I appreciate that... it's just a shame, that is all.

Not true, especially if you add in the cost of the support hardware.

VIA cpus or AMD low power cpus aren't exactly brilliant running m68k or PPC software

Of couse not... but for $150 I could buy a x86 system that would wipe the floor with the Efika in terms of performance... but the efika isn't designed for performance it has other priorities.

But for that 150$ wouldn't be low power and run m68k and PPC software at decent speeds.

But how much Amiga PPC only software, do you have that you couldn't do without? really?

[bloodline]

Hans_ wrote:
@bloodline & hbarcellos

By that reasoning, an AMD CPU is an x86 emulator too. It's not identical to the original x86 chip, but it does the same thing. Multiple companies make different but compatible versions of the same thing all the time. That doesn't make them emulators.

But you can take that argument to a stupid level... A Transistor is just a valve emulator... a computer is just an abacus emulator...

We're fully agreed that a clone (be it in an FPGA or otherwise) is not the original. Where we differ is in the definition of emulation. I agree that the end goal is roughly the same. However, the approach is quite different. An emulator is one thing, an FPGA implementation is another.

The only thing we disagree upon is the means... since we both want the same ends...

I just don't see the difference between a "Field Programmable Gate Array" programmed to behave like a chip/set of chips, and a CPU running a program  to do the same :-)

In many circuits, one would now use a Micro-controller in place of a large amount of dedicated custom built hardware.

This is why I call UAE an emulator, and the Minimig, an A500 clone. Neither are a genuine A500. To make things a little more complicated, the PIC micro on the Minimig that's connected to an SD-card slot is an Amiga floppy drive emulator, since there is no floppy drive at all, and it's making a file on the SD-card look like an Amiga floppy drive to the Minimig chipset.

I should point out that I love the Minimig and am really happy that Dennis made it!!!

I hope to buy one! But It should not be forgotten that all we are ever trying to achieve is an end result... how you achieve that should be dictated by the cheapest/most efficient route.

BTW, has anyone thought of taking the floppy emulator on the Minimig and connecting it to their Amiga? That would mean no more searching for disks.

Hans

Good idea.