Amiga.org
Amiga computer related discussion => Amiga Hardware Issues and discussion => Topic started by: hbarcellos on January 29, 2008, 08:56:04 PM
-
Look what I just found at wikipedia:
"Newer models of ColdFire are compatible enough with 68k processors that it is now possible to create binary compatible Amiga clones. The Debian project is currently working on making its m68k port compatible with the ColdFires[1], as there are ColdFire models that are much faster than the 68060. They can be clocked as high as 300MHz, compared with 60MHz for a 68060 (the fastest "real" m68k processor) without overclocking."
Anyway, why Freescale didn't kept binary compatibility?
and... If that's true, is possible to design some newer boards with 300mhz Coldfires?
Regards,
-
Sounds like BS to me.
-
It would've been nice for Motorola to have implemented a compatibility option where every changed opcode triggered an exception, so some piece of software could take care of emulation.
Unfortunately we're not in the right timeline for this to have happened... :cry:
-
I think the opcodes which are not the same are not commonly used in embedded systems which is where the coldfire is targetted.
They ARE binary compatible to a point, each of the affected opcodes can trigger an interrupt and run emulated routines.
-
Compatible enough as in not 100% compatible, so expect things to not work.
Wake me up when Coldfire is 100% compatible.
-
http://www.motorola.com/semiconductors
i think we need a coldfireMCF5407.library
-
Coldfire and 68K are about 99.8% code compatible. That's been the case from the start, Freescale didn't change it. There are two problems to solve with a coldfire card for Amiga.
#1 There are instructions in the 68k that are also legal on the coldfire... but they do a different type operation. It would be better if these instuctions were excluded on the coldfire all together. That way you could trap them with an illegal op exception and direct the code to a lib that would do a compatible operation in software instead. Many missing instructions are handled this way with current methods. The trouble comes in dealing with the "alien" instructions that do exist and can't be trapped. Some have suggested a JIT compiler method to intercept every binary code and process it. But that would require lots more code, probably more hardware and sap the speed of the coldfire down to an estimated 060/50 at best. It's a challenging problem that no one (that we know of) has solved yet.
#2 is the IO architecture. Only certain coldfire models support the necessary input/output options to interface well with the Amiga system. Hardware designs would have to be worked out to deal with the motherboard/buss interfaces.
There might be an Option #3.....
Use this instead.... http://www.innovasic.com/fido.htm
as suggested in this thread....
FIDO 1100 MPU (http://www.amiga.org/forums/showthread.php?t=34067)
If this CPU executes every included instuction like a 68k, then missing instructions can be handled in software.
Plaz
-
The Coldfire project (from Oliver, also around here in A.org) is stopped due the incompatibilities of the Coldfire versus a true 68k.
Also one note: 2.1 MIPS???? Check the source where you copy'n'paste before throw us that garbage!
-
Looking at the Fido thing, it's not 68k I/O compatible.
I wish that ematech guy would stop cutting and pasting all over the forums... a link would suffice.
-
Anyways, with Tobias's TG68 and FPGAs getting better and better, soon we will be able to run a virtual 68060 at 250MHz or more using simple programmable logic chips.
We can already run the 68000 at nearly 100MHz using cheap FPGAs.
-
How about a program that scans an Amiga binary, replacing the questionable opcodes with calls to a library?
-
@JimS
Data and code is not splitted in 68k code so that's probably not an easy task and that's the reason JITs exist.
-
Many (if not most) of these ideas have been discussed in the past threads. They're worth checking out, too.
-
hbarcellos wrote:
Look what I just found at wikipedia:
"Newer models of ColdFire are compatible enough with 68k processors that it is now possible to create binary compatible Amiga clones... --zip--
:horse:
-
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".
-
is stopped due the incompatibilities of the Coldfire versus a true 68k.
Not entirely true. According to his last emails, he's still messing with a design that would use a coldfire as a pluggable replacement for cpu cards that have a soceted 68030s. Even if succesful though, there would be code compatibility issues with some software.
Plaz
-
Then it will be big news!
But I'm afraid, without some hardware between the CF and the 030 socket to intercept bad code the board will stuck again.
-
eslapion wrote:
Anyways, with Tobias's TG68 and FPGAs getting better and better, soon we will be able to run a virtual 68060 at 250MHz or more using simple programmable logic chips.
Yeah right... NOT. Maybe in 10 years or so.
We can already run the 68000 at nearly 100MHz using cheap FPGAs.
They are hardly cheap, they still cost more (including an adapter PCB) than a real chip.
Due to the architecture, a 100MHz 68k would be lot slower than a 50MHz 060. Not to mention it doesn't have an MMU or FPU.
Add to that, Tobias's TG68, while a great achievment, is not 100% 68k compatible (yet).
-
I dont know what difference it would make, but reading the specs of the two prosessors reveal that the 68k is based on CISC instructions. And the coldfire is a 68k core but is designed as an RISC based CPU.
So... what difference does that make?
-
Hmm where is that Elbox Dragon 1200 ;)
-
@pyrre
68k is based on CISC instructions. And the coldfire is a 68k core but is designed as an RISC based CPU.
So... what difference does that make?
None. Whatever the CPU does internally to actually execute the instructions is irrelevant.
In similar way modern x86 CPUs are RISC, but execute x86 CISC code. See Wikipedia: x86, Current implementations (http://en.wikipedia.org/wiki/X86#Current_implementations)
-
@Painkiller
Hmm where is that Elbox Dragon 1200 ;)
Probably still trying to work out issues #1 and #2 in my post above. One rumor was that they had made good progress with compatibility, but speed suffered because of it.
It's possible to request a custom coldfire chip from freescale. Such a chip might help with I/O and speed issues. I've wondered if Elbox ever tried. But the production run would probably be too small and expensive to make it feesable.
Plaz
-
Plaz wrote:
@Painkiller
Hmm where is that Elbox Dragon 1200 ;)
Probably still trying to work out issues #1 and #2 in my post above. One rumor was that they had made good progress with compatibility, but speed suffered because of it.
It's possible to request a custom coldfire chip from freescale. Such a chip might help with I/O and speed issues. I've wondered if Elbox ever tried. But the production run would probably be too small and expensive to make it feesable.
Plaz
I saw the video of the dragon and it work perfect.And people complained that it was slow because they took various (o lot) seconds to display a web page with a dragon pic.The case is that i put my browser on a core duo 1,6 GHZ on that page and the pic was not displayed much more faster than the coldfire.So i thinks that the test used in the demo of the dragon was not a fortunate ones because they are slow operations even on multiGHZ systems
-
Could an FPGA be used as a "middleman" with coldfire to handle the compatibility issues? In other words the FPGA would hold the logic to make instructions compatible in both directions in case an instruction was incompatible.
My knowledge about FPGA's and integrated chips is superficial, so I apologize, if this is a stupid suggestion.
-
I saw the video of the dragon and it work perfect.And people complained that it was slow because they took various (o lot) seconds to display a web page with a dragon pic.The case is that i put my browser on a core duo 1,6 GHZ on that page and the pic was not displayed much more faster than the coldfire.So i thinks that the test used in the demo of the dragon was not a fortunate ones because they are slow operations even on multiGHZ systems
..I have that video on my PC HDD, but I don`t remember where I found it on the net.. actually Dragon Coldfire looked pretty fast, but the demonstration was not very lucky.. I wonder why they are not offering Dragon and what is with ElBox anyway.. :roll:
-
Protek wrote:
Could an FPGA be used as a "middleman" with coldfire to handle the compatibility issues? In other words the FPGA would hold the logic to make instructions compatible in both directions in case an instruction was incompatible.
Nope that is not possible, for the same reason already given as to why you cannot replace these instructions in the binary file.
You do not know what is data and what is instructions (made worse if anything is compressed).
-
MASACREWILL wrote:
I wonder why they are not offering Dragon and what is with ElBox anyway.. :roll:
I *think* it was a series of things:
1) The performance was not very good
2) The compatibility was not very good
3) They stopped making the exact coldfire chip that was on the Dragon.
-
alexh wrote:
I *think* it was a series of things:
Also, most importantly, I think time passed by and the economy went out of the project...
-
I'm pretty sure that when I looked up Coldfire tools that Freescale had a binary analyzer/converter that could take a 68K binary and make it CF-native.
Regardless, perhaps the first step should be recompiling 68k AROS to Coldfire.
-
@lou_dias
I'm pretty sure that when I looked up Coldfire tools that Freescale had a binary analyzer/converter that could take a 68K binary and make it CF-native.
It doesn't work for amiga binaries, and it never can.
The problem is that in any given amiga executable it is impossible to automagically determine which part is code and which data. It just can't be done.
-
The converter would have to RUN the code, and that just isnt possible. I doubt such a converter really exists.
-
alexh wrote:
You do not know what is data and what is instructions (made worse if anything is compressed).
Not entirely true (afair) - looking at the 68k's function control signals (intended for the MMU), the FPGA/glue chip could indeed judge whether code or data is fetched. Er, well, I've got no idea if a ColdFire has anything like FC signals...
However, this would effectively rule out any (code) caching since that would bypass any possibility to manipulate the code stream before it gets executed. Furthermore, it would slow down the memory access, which most of the time is a bottleneck anyway. No way anyone wants to go...
-
The converter would have to RUN the code, and that just isnt possible. I doubt such a converter really exists.
I recall see such a tool, buts it's limited. It reads your binary offline, replaces the offending instructions and then you have a new binary to run.
But for the reasons Piru mentions, it doesn't know when to stop. It may replace bits you don't want replaced. Also some code is very memory location dependant. If I see a 2 byte illegal instruction and I replace it with a 3 byte substitue, I've just offset the reset of the code for disasterous results probably.
The only way I can see that would work is to have the original C/C++ code and recompile it to coldfire. This is ok for apps written in a higher language, but the OS is too dependant on machine code, memory and chip addresses. First you need the original machine code, then you need to try and rewrite it in a why that makes both the native hardware and coldfire happy. No easy task.
Plaz
-
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.
Or someone could make a 68k->Coldfire compiler...or a 68k dis-assembler->CF instruction converter->Coldfire re-assembler->Colfire compiler.
-
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.
-
Intel ??? AAAAaaarrrgghhh...... :-D
Why use a Intel in the Amiga ? Buy a PC and use AROS, UAE or both. Cheap and easy.
Conecting an Intel compatible to the Amiga will be way more expensive than a small PC.
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...)
-
Sadly enough, and this is hard for me to say, the Intel processors are fast and dirt cheap. It's the same reason we have IDE now instead of SCSI. At the beginning they weren't worth buying for coasters relative to other processors but these days.... well lets just say things are different.
-
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...
-
@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.
-
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
As far as I can tell he didn't, he wants separate, native binaries:
The resultant binary could then be run natively.
JIT doesn't reconstruct the whole binary, just the executed parts (and depending on the implementation it might even choose to use interpretive emulation for some parts, rather than spending time to translate everything).
Due to the nature of the global, shared memory map of amigaos, it's quite impossible to store the translated code on disk, either (well you could store it, but it'd only be loadable to the exact same addresses as before, rendering the whole thing unusable).
-
bloodline wrote:
Well, a 68K is fine... that's what the Amiga was designed around... Using a PPC is just as hard as using an x86...
I've included PPC mainly because of OS4 and Morphos. I wasn't thinking about a full blown G5 or similar, but a embbedded chip like MPC5200 or AMCC's ones. They don't need heatsinks and have a local bus for memory mapped stuff that could be easier connected to an Amiga than the big chips would.
@nyteschayde:
Yes, I fully agree, they are cheap and easy to find, but this is nice for big companies. Home brewing an Intel board would be more expensive than buying a PC mobo.
In the other hand, microcontrollers like the ones above are really cheap also (maybe cheaper than x86s), and powerful enough to make us happy.
I have to admit Intel is faster, but a 700 mips PPC is good enough for me. Take a bigger one and you can get even more with all the advantages like built in Ethernet, USB, SPI (for SD cards..) and so on
(sorry... I'me already drooling :-D )
-
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.
-
The only solution to this problem - as has been said months ago - is building a patch database where the required patches for all applications are collected over time to be applied to the binaries when needed (a bit like WHDload). This might have been feasable with the user base in '94 and today's Internet, but it's impossible today.
-
@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.
-
@ 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...?
-
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) :-)
-
@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.
-
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!
-
@ 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 +++)
-
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.
-
(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:
-
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....
-
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
-
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
-
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... :-?
-
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...
-
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.
-
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?
-
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).
-
@Hans
I don't care much if 68k binaries could be written, because 90% of amiga software won't be rewritten.
BTW Biggun demonstrated *NOTHING* because there's no AmigaOS that runs on Coldfire. He just spreaded his theories about recompiling your binaries and making them slower on 68k just to be compatible with a handful of accelerators that run at 266Mhz and that are *slower* than a pitiful and cheap Efika/Pegasos (that at least has native PPC binaries and also can run 68k code at decent speeds).
IMHO a Coldfire would simply be a waste of time because it would not be 68k compatible. Recompiling would simply be stupid because 68k->PPC and 68k->x86 JITs are already faster than any Coldfire running native code (and since 1997-98 you have native PPC software). There are two OSes for PPC that run native PPC binaries.
What if current software is ported to Coldfire? Will it run faster than native PPC software running on Efika/pegasos/A1?-->NO
E.g.: would it be able to run Quake3 natively faster than Efika/Peg/A1?
Will it be faster running legacy 68k software? -> NO
-
@lou_dias
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.
Even if you saved the generated code on disk, you could no longer read it back (since everything would need to be located to exact same addresses as while saving).
It just doesn't work, sorry.
-
-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 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).
An FPGA has no predefined computer architecture; it is simply a huge array of logic gates with programmable interconnections. This is great, because it means that you can design and test computer circuits without having to manufacture a new chip every time you make a change.
It's the IC equivalent of having a huge prototyping board with all the discrete chips and wires required to implement any computer circuit you wish. If you wire up a circuit on a prototyping board that adds numbers together, you just built an adder; you didn't emulate it. Likewise, I could implement the same circuit on an FPGA. The only difference is that instead of manually plugging wires into a proto-board, I upload a bitfile to the FPGA that connects up the relevant wires between logic gates in the FPGA.
Let's take this one step further. Suppose now that I design a circuit that performs the same function as the Paula chip. It has the same registers, and performs the same task. I've just designed Paula compatible hardware.* I could now wire up logic gates on my proto-board (the original Amiga prototype was built out of discrete ICs), or create an FPGA bitfile and implement it on my FPGA. If I'm completely happy with it, I could call an ASIC company and pay them to transfer my Paula compatible circuit onto an ASIC, and have them manufactured in medium quantities. Equally possible would be for me to hand my design over to an IC designer and have that person design a fully-custom chip containing my Paula implementation.
Now let's look at an emulator. It's written in software for hardware with a predefined architecture. Via software instructions that are executed serially, you emulate the behaviour of all the hardware elements in a completely different machine. Unlike Dennis' Paula implementation on an FPGA, there are no actual Paula registers, and the machine has to execute several instructions to emulate what happens simultaneously in the real thing. You can't take this code and hand it to an ASIC or IC engineer and say "hey, build this circuit" because it's not a circuit at all, it's a set of instructions for a CPU that emulate the behaviour of a hardware circuit in software.
I hope that this clarifies it a bit. Just because an FPGA is reprogrammable doesn't mean that it's running software. You're implementing hardware circuits on it.
Hans
* note: it's Paula compatible, not an actual Paula chip, because it's not gate-for-gate equivalent.
-
Crumb wrote:
@Hans
I don't care much if 68k binaries could be written, because 90% of amiga software won't be rewritten.
Nor do I care.
BTW Biggun demonstrated *NOTHING* because there's no AmigaOS that runs on Coldfire. He just spreaded his theories about recompiling your binaries and making them slower on 68k just to be compatible with a handful of accelerators that run at 266Mhz and that are *slower* than a pitiful and cheap Efika/Pegasos (that at least has native PPC binaries and also can run 68k code at decent speeds).
I believe that Elbox has a working prototype Coldfire card (they demonstrated it somewhere IIRC), so I'd expect that it's actually been tried and tested. It's not a theory. Whether it's faster or slower than emulation on 1GHz+ machines is irrelevant really.
I'm personally not a big fan of using Coldfire as the next generation Amiga, but someone else might get a kick out of making it happen. The decision was made to go PowerPC over a decade ago. That might even change to x86 at some point.
None of this changes the fact that you could produce binaries that run on both 68K and Coldfire if you wanted to.
Hans
-
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...
-
@hans
None of this changes the fact that you could produce binaries that run on both 68K and Coldfire if you wanted to.
Yes, but you have to avoid using normal instructions like MUL and "emulate" it, slowing down the execution on both cpus
-
Bloodline... Finally someone expressed my feelings about FPGA in a perfect way. Thank you.
-
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
-
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.
-
Ok. in theory its not emulation, but...
It's always made through reverse engineering, to have the same behaviour of the original chip. But it's not made exactly the same. It's not the real thing.
As it's much more difficult to debug, the accuracy is probably much worst.
-
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.
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.
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?)
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?
A x86 or ARM will be cheaper and more long term solution...
I doubt it.
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.
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.
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.
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
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.
-
@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.
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.
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.
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
-
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?
-
@Hans_
I think that comparing a reimplementation with an emulator is like claiming that modern x86 chips are just emulators because they internally work as RISC cpus and simply have x86 interpreters.
-
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.
-
Besides my opinion about FPGAs, I also very excited about the MiniMig project. No one will create a special case for it? Like the OCM (One chip MSX)? Or maybe an A500 on a joystick?
And about the floppy emulator, that's amazing. When it will be ready!? :)
-
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...
Then imagine how fast would it run your OS if you had the chance of running your 68k apps together with native PPC apps.
They really will outperform any PPC Performance per watt, as for PPC code... well I don't really care about that
Most of amigans do. Just check out the interest in MOS/OS4. And it's much lower than it could be due to expensive hardware (or unavailable OSes).
But you would put a PPC 970 - G5?
On an Amiga Classic cpu? Probably never. I think that embedded models with built-in stuff are far more appropiate. Even if you fitted a low power 970Fx you still would need a big and expensive northbridge and memory controller. Embedded models include the memory/pci/sata/usb controller
No, exactly... I appreciate that... it's just a shame, that is all.
I think that CyberstormPPC/BlizzardPPC were more or less OK at the time. Don't get me wrong, a CyberstormG3/G4 would have been very nice with a JIT or maybe even an embedded emulator but it's a pity phase5 died before releasing it.
But how much Amiga PPC only software, do you have that you couldn't do without? really?
I could probably live without amigas too, but it would be much more boring.
BTW, graphics are much faster on Amithlon/MorphOS/OS4 than on UAE.
-
@Crumb
A bit off topic, sorry, but I've had a quick look around:
Compare the EPIA PX (http://www.via.com.tw/en/products/mainboards/motherboards.jsp?motherboard_id=472)
With the EFIKA 5200B (http://www.genesi-usa.com/efika.php)
I can't believe anyone would choose the Efika actually... Maybe I'm not looking at the right model... but really can't see the advantages... are you able to tell me?
I note you claim the C7 is bad for JIT execution due to small caches, but the Efika only has 32k L1 cache (ref (http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPC5200B)) and no L2
The C7 has 64K L1 and 127K L2... (ref (http://www.via.com.tw/en/products/processors/c7/specs.jsp))
The Efika tops out at 400Mhz... the C7 is scalable up to 2Ghz... Need I go on?
Other than running PPC code there is no advantage to the PPC here :roll:
-
I'm a big fan of ARM processors. I believe Acorn users should be really happy :-D
Who is making Cortex M8 chips ? Texas announced that some time ago, but I would like to know who is making these babies today.
I still think an embbedded PPC is the best solution for an Amiga accelerator. I see the PPC as a long term solution also, for processing-power hungry devices, and we have plenty of than, as the consoles mentioned before, and we need to include network stuff, EFI, set top boxes, etc...
ARM seems to be pointing to portable and embbeded stuff. To the low end market.
My guess (this is just my feelings about it) is that ARM will grow up to be the best power efficient solution, and to replace most of 8 bit microcontrolers, as the prices are already diving fast. PPC will be the high end target for everything that needs raw processing power. Sooner or later, G5s and Cells will go embbeded also, as technology advances, and we will have faster PPCs due to the supercomputer guys (check IBM, for example...)
x86s will stay on the desktop, simply because if you wish to use an embbedded PC, it is cheaper to buy a common mobo and use it, like ATMs and arcades do. There are also few companies pushing for embbeded x86s, and most still require northbridges and all the assorted stuff. They can't compete with powerfull ARMs and PPCs, and there are still other powerful chips like the BlackFin, SH, v850, MIPS and others
For the Coldfire, it doesn't match neither ARM, PPC or x86, and it is still incompatible with 68K. It's bus is a problem also, the best way to use it is to "translate" Amiga's bus to PCI.
To resume: PPC embbeded is nice, because it is cheap (US$17,86 for a 760MIPS MPC5200B, for example), we can get it without a heatsink, it will be easier to run OS4/Morphos, and to connect it's bus to the Amiga than any other uP.
x86 for sure is faster, but if that is the future, it will run AROS, rather than be conneccted to a real Amiga
It's just my opinion.. :-)
-
bloodline wrote:
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...
My point exactly.
The only thing we disagree upon is the means... since we both want the same ends...
But it's the means that decides whether it's an emulator or a clone, not the end result.
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 :-)
I guess we'll have to leave it at that then. Given that one is a software emulation of hardware, and the other is a hardware design that's compatible with the original, I see them as very different. Moreover, if I were to take the MiniMig Verilog files and use them to synthesize an ASIC, would you still consider it an emulator? I've worked with both microcontrollers and FPGAs; they're very different.
Hans
-
So we end at the very same boat.
The original question is: how to create a "new" accelerator for classics.
My best shot: reverse engineering the 68060 and put the results in a FPGA, but clocked at a monster speed.
Of course, this solution may be not very practical, because the cost of such FPGA (@least 400MHz, a dozen logic gates, BGA package and so on).
-
Perfect 68k compatibility on a ColdFire-machine won't happen, though question is if it's possible to make things compatible enough for a certain type of user. On the Atari platform, people are experimenting with running TOS and FreeMiNT on ColdFire evaluation boards.
Link: http://pagesperso-orange.fr/didierm/ct60/ctpci.htm
So far, success is limited to booting a (very) simple OS installation with a few applications running. He's using CF68KLib to get things running to a certain degree. The MyAES GUI runs natively on the ColdFire (not shown on the page though). Even though this setup is extremely limited, I'd like to view it as a proof of concept.
A ColdFire-based system would have to deal with the following scenarios:
1. Applications which work right away
2. Applications which doesn't work, but can be recompiled or patched
3. Applications which can't be patched and won't work
4. Games and stuff
The first case (1) is covered just by implementing CF68KLib in the system. Performance range from really fast to so-so depending on the use of unimplemented instructions. The second (2) case is dealt with by recompiling applications, manually patching stuff, or using PortASM (to a certain degree, at least).
The third case (3) is covered by a fallback approach. If everything else fails - you emulate the whole CPU for that particular process. I've personally done some experiments with this based on the CPU-emulator from CaSTaway, and while the raw processing performance is pretty bad (~8-16Mhz 68000 on a 100Mhz 68060), all OS functions etc. runs natively at full speed, giving the impression of a much faster machine. In some cases it was even difficult to spot the difference in performance between a "native" and "emulated" process. Also, in practice, an emulated process doesn't steal much CPU time from the rest of the system, since applications tend to spend most of their time waiting for input etc (and thus releases control to the OS, effecitvely pausing the emulation).
The last case (4) needs complete emulation of the whole system. CaSTaway runs at between 50-200% relative performance (8Mhz Atari ST) on a 100Mhz 68060. It doesn't offer perfect compatibility (well, and atm it usually hangs the system after a while), but again - it's a proof of concept. I know the Amiga is much trickier to emulate though.
I've ordered a ColdFire EVB myself and hope to get some "real" numbers later on.
I imagine a ColdFire clone could be successful for a certain type of user (like me - using coding GCC, ICQ, IRC, simple browsing, listening to MP3:s etc.), but users looking for games and demo compatibility should probably look at emulators instead.
-
rkauer wrote:
My best shot: reverse engineering the 68060 and put the results in a FPGA, but clocked at a monster speed.
Of course, this solution may be not very practical, because the cost of such FPGA (@least 400MHz, a dozen logic gates, BGA package and so on).
It's not practical because no single FPGA has the capacity for a 68060 or the ability to run at high speed with a design of that complexity.
The best solution for a new classic accelerator (or a faster MiniMig), is to find a source of reasonable priced rev6 060 chips. Either pulls from other equipment such as telecoms, or direct from freescale through sideband channels.
-
Do we really need a softcore-68060, why not try to do 68020 (+mmu) in fpga instead? should give enough benefits without the complexity?
-
Would hardly be an accelerator then would it
-
With enough demand, an fpga can be made into an asic.
I'd rather see a 100% compatible '030 though (in fpga).
-
Krusher wrote:
With enough demand, an fpga can be made into an asic.
You're joking right? $70k NRE minimum
-
I told you, with enough demand :lol:
-
freqmax wrote:
Do we really need a softcore-68060, why not try to do 68020 (+mmu) in fpga instead? should give enough benefits without the complexity?
This is going to sound crazy after my previous rant... but probably the best idea is to clone something more like a Coldfire compatible core on FPGA... but one where all incompatible (with the 68k) instructions/addressing modes are trapped and trigger exceptions. And one where the supervisor mode functions as the supervisor mode on the 68k.
I expect the Freescale engineers carefully selected which 68k features would scale well, and/or be easy to implement simply. Then all less scalable features could be emulated (a la 68060.library etc...), that would not be particularly quick for old software, but it would run (possibly faster than on a real 68k).
If we took TobiFlex's 68k and stripped it back, it could probably be done... and would reduce the complexity/size of the core!
-
It is possible to configure the CF68klib so that it sets up a Virtual 68k on the Coldfire (with e.g. 68060 as target), but then FPU and MMU will not work and it can not execute Coldfire Code anymore. Would it be possible to place the MMU and FPU in an FPGA'ed ChipSet?
-
Donar wrote:
It is possible to configure the CF68klib so that it sets up a Virtual 68k on the Coldfire (with e.g. 68060 as target), but then FPU and MMU will not work and it can not execute Coldfire Code anymore. Would it be possible to place the MMU and FPU in an FPGA'ed ChipSet?
I don't understand the question. The coldfire is not suitable to the amiga... I would hate the think how complex an FPU in an FPGA would be!
-
I don't understand the question. The coldfire is not suitable to the amiga...
The Coldfire can behave like an 680x0 without MMU and FPU, if you build the right CF68klib from MicroAPL which then sets up a Virtual Machine on the CF. At least that is what the CF68klib manual says.
Problem would be:
Getting the CF on the Amiga Bus.
I think you need an MMU for setting this kind of extension up.
No FPU support.
I would hate the think how complex an FPU in an FPGA would be!
Ok thanks, it was just an idea for a work around for some problems.
-
Donar wrote:
I don't understand the question. The coldfire is not suitable to the amiga...
The Coldfire can behave like an 680x0 without MMU and FPU, if you build the right CF68klib from MicroAPL which then sets up a Virtual Machine on the CF. At least that is what the CF68klib manual says.
Almost. Some instructions cannot be emulated, since they behave differently in the ColdFire. That's what the CF68klib manual says.
Problem would be:
Getting the CF on the Amiga Bus.
I think you need an MMU for setting this kind of extension up.
No FPU support.
You don't need an MMU to get the CF68klib up and running. It uses the illegal instruction vector to implement missing instructions.
-
x86s will stay on the desktop,
Laptop PC's dominance is assimilating some embedded type usage e.g. HD-DVD/Blu-Ray/TV portable players,
Btw, Toshiba's HD-A1 HD-DVD player uses Intel's Pentium IV.
simply because if you wish to use an embbedded PC, it is cheaper to buy a common mobo and use it, like ATMs and arcades do.
X86 (Lintel(e.g. LAMP*), Wintel(e.g. WAMP**)) also dominates the 1-way/2-way/4-way server market.
*Linux, Apache, MySQL, Php.
**Windows, Apache, MySQL, Php.
and we will have faster PPCs due to the supercomputer guys (check IBM, for example...)
The reason why BlueGene is *fast* is due to the number of cores involved.
Anyway, in Nov 2007 top 10 supercomputer list
http://www.top500.org/lists/2007/11#top10
1. IBM POWER based.
2. IBM POWER based.
3. Intel Xeon (Core 2) X64 based.
4. Intel Xeon (Core 2) X64 based.
5. Intel Xeon (Core 2) X64 based.
6. AMD Opteron(K8) X64 based.
7. AMD Opteron(K8) X64 based.
8. IBM POWER based.
9. AMD Opteron(K8) X64 based.
10. IBM POWER based.
As you can see, there’s a mix of X86(X64) and POWER based supercomputers.
Cells will go embbeded also,
Toshiba's CELL based SpurEngine doesn't have PPE core. The Toshiba's SpurEngine (as in the demo) uses Intel's Core 2 as it's host CPU instead of PPE.
It’s possible to built a CELL based system, with X86(X64)+SPUs+NV GPU (e.g. Toshiba'a 17" demo laptop) instead of PPE+SPUs+NV GPU(e.g. PS3).
-
Why do you people constantly get back to this discussion. Please read the other threads.
There is already a ColdFire solution and it's called the Dragon from Elbox. It's running and it has been demoed.
The fact we can't buy it is more than likely because they still have problems with it. Probably both on the performance front and compatibility front.
I don't see anyone making this working in their spare time. This is the realistic prediction. Everything else just borders on naive optimism.
The only solution is that Freescale lowers the price of the 68060 they still sell. Hell, lower the price, put it on a smaller die and clock it up!!! OK, thats also not going to happen. Were screwed.
-
Almost. Some instructions cannot be emulated, since they behave differently in the ColdFire. That's what the CF68klib manual says.
If i read page 10 onward of the manual correctly, which is about "Supervisor mode", that is only true for a CF68klib build for "User mode" :-P
You don't need an MMU to get the CF68klib up and running. It uses the illegal instruction vector to implement missing instructions.
I was told that you need the MMU for setting up an expansion card for the Amiga with eg 68060 or CF. That's why i was nosy about having an MMU in the ChipSet.
-
Donar wrote:
Almost. Some instructions cannot be emulated, since they behave differently in the ColdFire. That's what the CF68klib manual says.
If i read page 10 onward of the manual correctly, which is about "Supervisor mode", that is only true for a CF68klib build for "User mode" :-P
There are situations where the Coldfire returns a different result, from what the 68k would return in the same situation. These are not trapped with an illegal instruction vector, and thus cannot be emulated.
Supervisor mode is totally different.
You don't need an MMU to get the CF68klib up and running. It uses the illegal instruction vector to implement missing instructions.
I was told that you need the MMU for setting up an expansion card for the Amiga with eg 68060 or CF. That's why i was nosy about having an MMU in the ChipSet.
MMU and FPU are not required for Amiga.
-
As i do not know how to explain it properly i take this rather lenghty cut&paste. Sorry for the inconvenience...
User Mode Library
In this form CF68KLib will install its own handlers for the 'Illegal Instruction' and 'Address Error' exceptions which can occur when unimplemented 680x0 instructions are executed on ColdFire. These handlers will perform the same
function as the missing instruction and then return execution to the instruction which follows. The existence of CF68KLib is thus transparent to your application code except that it can incur a substantial performance penalty.
It is occasionally necessary to make minor modifications to your 680x0 program before it can be run under CF68KLib. This is because there are a very small number of 680x0 instructions which are also legal in ColdFire (and hence do not cause an exception) but which do not behave identically. As an example, the MULS instruction executes identically under ColdFire except that it does not set the Overflow flag in the condition codes register.
Ok this is what everybody is always talking about.
Supervisor Mode Library
The ColdFire supervisor model is very different to the 680x0. For example there is only one stack pointer instead of separate User and Supervisor stacks, and the format of an exception stack frame is different. This means that although instructions such as TRAP and RTE are implemented in the ColdFire architecture, a 680x0 binary such as an operating system would be unlikely to work correctly. For this type of problem you can use the Supervisor Mode form
of CF68KLib. In the Supervisor Mode form, the CF68KLib library takes over the handling of all ColdFire exceptions in order to implement a complete 680x0 virtual machine.
The presence of CF68KLib is transparent to your 680x0 code, which 'thinks' it is running on a real 680x0 processor, and you can run an entire 680x0 operating
system including interrupt-driven hardware inside the virtual machine. Because the Supervisor Mode form of CF68KLib has to take over the handling of all ColdFire exceptions it is generally not possible to use this form of the library alongside a native ColdFire operating system, although you can still execute application-level ColdFire code.
No problems with the different supervisor mode model, as the 68k one is emulated. And as it is not mentioned otherwise (as it is on the paragraph about user mode) it seems that also the differently implemented CF/68k instructions return the proper result!?
If you wonder where i pulled that from:
Click (http://www.microapl.co.uk/Porting/ColdFire/pacf_download.html#cf68klib)
-
@Donar
Yes exactly!
The MUL problem would kill a large amount of Amiga Code. Code which we can't modify, as CF68KLib suggests, because we don't have the source code.
Supervisor mode would be very slow...
The point is not that the Coldfire can't be used... the point is that the amount of work required would be the same for any CPU... and there are cheaper faster ones available!
-
If i read page 10 onward of the manual correctly, which is about "Supervisor mode", that is only true for a CF68klib build for "User mode" :-P
Donar, had you read the documentation properly you'll also know that not all instructions can be trapped and emulated. :-P :-P :-P :-P :-P
Read the ColdFire reference documentation and/or chapter 5 in the CF68KLib docs.
I was told that you need the MMU for setting up an expansion card for the Amiga with eg 68060 or CF. That's why i was nosy about having an MMU in the ChipSet.
Well, I don't know about that, but I do know that CF68klib in itself doesn't need an MMU to get up and running.
-
The A3000 with a 1.4 rom needs the '030 mmu, so yes it's used.
Kickstart V1.4 is actually a special version of Kickstart which loads the real Kickstart from a file called DEVS:Kickstart. Kickstart V2.04 was available as a ROM, or as a disk based version for use with A3000's which had Kickstart V1.4. A3000's fitted with Kickstart V1.4 cannot use 040 or 060 processors, regardless of what version of Kickstart is eventually booted, because it relies heavily on the integrated MMU in the 030 which varies to some degree from the MMU in 040 and 060 processors.
From the Big book of Amiga Hardware.
-
No problems with the different supervisor mode model, as the 68k one is emulated. And as it is not mentioned otherwise (as it is on the paragraph about user mode) it seems that also the differently implemented CF/68k instructions return the proper result!?
CF68KLib can only emulate instructions which are trapped by the ColdFire. If the instruction in question doesn't cause and illegal instruction, it won't be trapped, hence not emulated. User Mode or Supervisor Mode library doesn't matter.
Are you a coder, Donar?
-
Hammer wrote:
X86 (Lintel(e.g. LAMP*), Wintel(e.g. WAMP**)) also dominates the 1-way/2-way/4-way server market.
Agree. But as I've said, those machine are PCs anyway, not fully custom hardware with a x86 at its core
The reason why BlueGene is *fast* is due to the number of cores involved.
Maybe you misunderstood my point of view. I was not stating that all supercomputers use PPC. What I mean is that althrough Apple does not have PPC Macs anymore, the architecture will not die, because those supercomputer companies have interest in pushing its development further.
IBM is going to Power 6.
Blues Gene may be faster because it has more cores, but speed needs will grow, and using even more cores won't be feasible at some point. The cores will have to go faster, and they know that (this is the reason why nobody is using a box with zillions of Z80s :-D )
Home PCs market will keep pushing x86s faster also, but a quick solution would be use more cores. One could think in the reverse way and say x86 development could stop because we would have faster machines with more CPUs. (of course, this is nonsense...)
Cells will go embbeded also,
Again, I think you misunderstood me. What I mean is that CELLs will be in available microcontrollers soon, as PPCs are today. I bet your car has at least one PPC. Some years ago, PPCs were heavy weight processors. When I've started working with EFI modules, companies used 68HC11s or 8051s derivatives. Engines didn't changed that much in that amount of time, but ECUs now have those beasts calculating when to fire the spark and how much fuel to burn.
I don't believe the industry will stay comfortable with with today's processing capabilities, so I believe it is a matter of time before your microwave oven have a CELL, and this chip will cost then 5 bucks maybe.
If it makes you feel better, probably you may have a 5 bucks Pentium 4 some time in future also.
Shouldn't we be talking about Coldfires instead ??
-
User Mode or Supervisor Mode library doesn't matter.
I only find it strange that in the user mode paragraph it is mentioned explicitly that the differently implemented instructions will not work, and in the supervisor mode paragraph there is no word about it. It sounds like the library will set up an full 680x0 Emulator (without MMU/FPU) on the Coldfire but maybe i interprete in the text what i want to be true :lol:
Are you a coder, Donar?
No, but i think i can read... :-)
-
Donar wrote:
User Mode or Supervisor Mode library doesn't matter.
I only find it strange that in the user mode paragraph it is mentioned explicitly that the differently implemented instructions will not work, and in the supervisor mode paragraph there is no word about it. It sounds like the library will set up an full 680x0 Emulator (without MMU/FPU) on the Coldfire but maybe i interprete in the text what i want to be true :lol:
Ok, the Coldfire Supervisor mode is so incompatible with the 68k that it needs to run any 68k code in an emulator in the SuperState. This is a very slow thing to do, and negates the point of using the coldfire in the first place... Since to run Amiga code in the User mode it would also need the emulator... by now it really isn't worth using the coldfire.
Are you a coder, Donar?
No, but i think i can read... :-)
What the document is saying (probably not very clearly), is that coldfire User mode offers a high degree of 68k compatibility, and requires only minor source code modification in order to work. But the Supervisor mode is so different to the 68k, that all your supervisor mode code must run in an emulator... Amiga code would need to run in that emulator all the time, this makes the CPU useless.
-
I only find it strange that in the user mode paragraph it is mentioned explicitly that the differently implemented instructions will not work, and in the supervisor mode paragraph there is no word about it.
The user mode version only emulate the missing instructions. If you try to run your OS using this one, you'll get trouble not only due to the instructions that differ, but also due to the differences in the supervisor execution model. The supervisor mode version attempts to remedy the latter.
It sounds like the library will set up an full 680x0 Emulator (without MMU/FPU) on the Coldfire but maybe i interprete in the text what i want to be true :lol:
No, but i think i can read... :-)
Well, no offence intended, but read the remainder of the document. That's just a section in the introduction chapter.
Having said that, I don't think you're necessarily on the wrong track. For full compatibility, you'll have to emulate every single instruction. That will be slow on a ColdFire. On the other hand, some apps may run perfectly using CF68KLib - or - can be patched or recompiled to do so. And they't run fast.
-
Again, I think you misunderstood me. What I mean is that CELLs will be in available microcontrollers soon, as PPCs are today.
CELLs based products such as Toshiba's SpurEngine (10W to 20W part) doesn't have PPE (aka POWER Processing Element).
For a RISC ISA, POWER ISA is considered as complex-RISC.
In terms of yearly sales numbers, ARM and MIPS kills POWER/PowerPC.
I bet your car has at least one PPC.
I'll bet it doesn't have a PPC in its critical computing systems.
"Toyota Prius, is using MULTI® IDE and C/C++ compiler on a NEC V850 processor to develop the powertrain, drivetrain, power steering, anti-lock brakes, air bags, body control, and electric motor control system on the Prius."
http://www.ghs.com/customers/prius.html
Same NEC V850 also in used in Toyota Avalon.
More info on NEC V850
http://www.am.necel.com/news/newsdetail.html?page=ghv850vr
Btw, Ford Jaguar and Lincoln LS uses Freescale Power Architecture MPC509 microprocessor for it's critical computing systems. I haven’t brought any Fords…
Anyway...
Toshiba HD-A1 HD-DVD uses
CPU: Intel Pentium 4-M (@ 2.4GHz)
Toshiba HD-A2 HD-DVD uses
CPU: Intel Celeron-M (@ 900MHz CPU for HDi) / NEC EMMA3 (CPU for video/audio decoding)
Toshiba HD-A20 HD-DVD uses
CPU: Intel Celeron-M (@ 900MHz CPU for HDi) / NEC EMMA3 (CPU for video/audio processing)
3rd generation HD-A3 players uses NEC MIPS based prcoessor.
-
IMHO, if you need to emulate the 68k programming model in the first place, the only point left is speed. There's no point in starting with a comparatively slow ColdFire in the first place. The bus is hard to adapt as well, so no advantage gained there either.
From the speed POV, you're left with PPC and x86 - with x86 being highly available in all speed grades and form factors. Rather than designing a new accelerator board, it'd be much easier (well, somewhat) to redesign the chipset (when you're hooked to it) since this is already worked on. Put all this as an FPGA on a PCI(x) board, use an off-the-shelf x86 mobo and you're set.
Actually there isn't really too much point left in dragging the chipset behind either - if you drop that as well, you're left with the OS. Port it to the platform of your choice - et voilá - that's where AROS comes into play.
It all depends on what you really want to achieve:
- save your old hardware from dying (expensive)
- modernize your system while keeping old software (=> emulation)
- regain a good price/performance relation (=> OS porting)
Everything else is :horse:
-
Zac67 wrote:
It all depends on what you really want to achieve:
- save your old hardware from dying (expensive)
- modernize your system while keeping old software (=> emulation)
- regain a good price/performance relation (=> OS porting)
Everything else is :horse:
Beautiful summery.
-
Well, no offence intended, but read the remainder of the document.
I have read the whole document months ago.... Maybe we can make a deal? I'll shut my mouth now, and you try out how Coldfire behaves when you get your Coldfire EVB and tell us your findings in the next thread (that surely will appear). ;-)
It all depends on what you really want to achieve:
-Having new hardware that follows in the footsteps of the AMIGA architecture (see Natami project) but is fast enough to not bore the user to death, while waiting for a window to open (as AGA will do, when you use HighRes in 256 colours).
And no i do not want to play Crysis in 1680x1050 on it nor do i want to compress all my DVD's to MPEG 4 or watch BluRay on it. I have a fast PC and PS3 for such things.
-
Donar wrote:
It all depends on what you really want to achieve:
-Having new hardware that follows in the footsteps of the AMIGA architecture (see Natami project) but is fast enough to not bore the user to death, while waiting for a window to open (as AGA will do, when you use HighRes in 256 colours).
Hacking together out of date technologies into something that is a little bit compatible to the old Amiga line of computers is not following in the footsteps of AMiGA...
Taking the most advanced technology available to the consumer, putting it together in a new and innovative way and packaging it in a user-friendly way is following in the footsteps...
Unfortunately only Apple come close to that... and even they aren't really pushing the hardware envelope... but they are doing a good job.
And no i do not want to play Crysis in 1680x1050 on it nor do i want to compress all my DVD's to MPEG 4 or watch BluRay on it. I have a fast PC and PS3 for such things.
If we really were following in the footsteps of the Amiga, we would get all those things for free.
-
...footsteps of the AMIGA architecture...
Hacking together out of date technologies into something that is a little bit compatible to the old Amiga line of computers is not following in the footsteps of AMiGA...
Maybe it's not in the footsteps of the AMIGA if you think of the most advanced computer that is available on earth. But it would be in the footsteps of how things were done "differently" in the AMIGA.
Taking the most advanced technology available to the consumer, putting it together in a new and innovative way and packaging it in a user-friendly way is following in the footsteps...
I like the idea but as i do not think that somebody who shares your vision of a new AMIGA has the funds to realize it, its just not going to happen. Somebody could cludge together an FPGA'ed Chip set and some processor in his cellar. But there is no way anybody beats Intel, AMD and NVidia with his cellar invention. :-(
Unfortunately only Apple come close to that...
Why do you think so? Because Apple sells dual processor workstations with four cores to everyone who want's to have more than one hard disk in his computer? Ok i admit: OSX just works out of the box.
-
Donar wrote:
...footsteps of the AMIGA architecture...
Hacking together out of date technologies into something that is a little bit compatible to the old Amiga line of computers is not following in the footsteps of AMiGA...
Maybe it's not in the footsteps of the AMIGA if you think of the most advanced computer that is available on earth. But it would be in the footsteps of how things were done "differently" in the AMIGA.
But the Amiga did things differently... then everyone else did the same... what we have now is the legacy of the Amiga's different thinking.
We now need someone to think differently.
Taking the most advanced technology available to the consumer, putting it together in a new and innovative way and packaging it in a user-friendly way is following in the footsteps...
I like the idea but as i do not think that somebody who shares your vision of a new AMIGA has the funds to realize it, its just not going to happen. Somebody could cludge together an FPGA'ed Chip set and some processor in his cellar. But there is no way anybody beats Intel, AMD and NVidia with his cellar invention. :-(
Well, Audio has reached it's highest level... No one can think of any other ways of getting hardware to produce sound... Synths (subtractive and modelling) and Samplers. All you can do in increase fidelity (but at 24bit 96Khz who can tell beyond that, especially with speaker technology).
But there are projects to develop new ways of rendering graphics... With ATI and Nvidia stuck with current polygon system... others are looking to ray-tracing... maybe there are other ways... we need innovation here...
Unfortunately only Apple come close to that...
Why do you think so? Because Apple sells dual processor workstations with four cores to everyone who want's to have more than one hard disk in his computer? Ok i admit: OSX just works out of the box.
Apple now take the best technologies available, and package it in pretty user friendly boxes. That is what the Amiga was all about..
-
bloodline wrote:
Apple now take the best technologies available, and package it in pretty user friendly boxes. That is what the Amiga was all about..
But in the end a MacPro is just a dual processor Workstation with EFI instead of a BIOS, which you could also get from Boxxtech. I would have found it interesting if they had (for example) included a Cell or DSP that could assist the XEON's for special purposes.
-
Donar wrote:
bloodline wrote:
Apple now take the best technologies available, and package it in pretty user friendly boxes. That is what the Amiga was all about..
But in the end a MacPro is just a dual processor Workstation with EFI instead of a BIOS, which you could also get from Boxxtech. I would have found it interesting if they had (for example) included a Cell or DSP that could assist the XEON's for special purposes.
For what purpose...? A Cell or a DSP isn't going to offer anything over over a regular GPU and certainly nothing for the consumer price bracket...
-
bloodline wrote:
For what purpose...?
Videoencoding, Raytracing booster.
A Cell or a DSP isn't going to offer anything over over a regular GPU
I do not know how good it works on an Apple computer. But if you try to do computational work on the GPU under Win XP (e.g. Folding @ Home) your GUI will slow down, and you have to dedicate one CPU core for "feeding/checking" the GPU client which runs on the GFX card, or it will be real slow, additionally you can only use ATI/AMD cards as NVidia cards are (according to the development team at Stanford university) not able to do this kind of work. You also have to stay on certain catalyst versions - and even then most people have severe issues with it.
I really do not care if you take Cell or a Radeon as super fast subsystem (take something with a good GFlop/Watt/Price ratio), but please integrate it properly into the whole System and OS, so that it is usable without any issues.
...and certainly nothing for the consumer price bracket...
I do not want Apple to integrate the Cell into a MacMini besides the Core 2Duo, but maybe into the MacPro. A MacPro is not what i think about for the consumer price bracket also.
Edit: If any body want's to talk about Coldfire, just do it i did not mean to hijack the thread.
-
Hammer wrote:
CELLs based products such as Toshiba's SpurEngine (10W to 20W part) doesn't have PPE
This still doesn't mean that nobody will ever have interest in producing a chip with the PPE
I'll bet it doesn't have a PPC in its critical computing systems.
Delphi, Marelli and Bosch uses PPCs in engine control modules. This is quite critical to me.
The V850 is a great chip, and it was well chosen to power Toyota's cars. Some people are driving Renesas, some ST, and I even had a experience with TI some years ago (not a really good one. We went back to Motorola, but the chip was nice).
Nobody, as far as I know, is using x86, for a couple of reasons. Unless Toshiba decides to install wheels in their HD-DVDs
Now I just swear I won't go off topic again...
-
Donar wrote:
bloodline wrote:
Apple now take the best technologies available, and package it in pretty user friendly boxes. That is what the Amiga was all about..
But in the end a MacPro is just a dual processor Workstation with EFI instead of a BIOS, which you could also get from Boxxtech. I would have found it interesting if they had (for example) included a Cell or DSP that could assist the XEON's for special purposes.
Install Linux on it and install either NV's CUDA or ATI's CTM.
What's special about CELL?
-
AeroMan wrote:
Hammer wrote:
CELLs based products such as Toshiba's SpurEngine (10W to 20W part) doesn't have PPE
This still doesn't mean that nobody will ever have interest in producing a chip with the PPE
I'll bet it doesn't have a PPC in its critical computing systems.
Delphi, Marelli and Bosch uses PPCs in engine control modules. This is quite critical to me.
The V850 is a great chip, and it was well chosen to power Toyota's cars. Some people are driving Renesas, some ST, and I even had a experience with TI some years ago (not a really good one. We went back to Motorola, but the chip was nice).
Nobody, as far as I know, is using x86, for a couple of reasons. Unless Toshiba decides to install wheels in their HD-DVDs
One may say Toshiba has installed wheels in their HD-DVDs.
Refer to http://news.thomasnet.com/companystory/525623
Toshiba Selects ARM Cortex-M3 Processor for Automotive Applications.
As for X86 for control CPU... Refer to
Underwater Vehicle Control software (http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel5/10918/34367/01639923.pdf?isnumber=34367&prod=CNF&arnumber=1639923&arSt=+1228&ared=+1233+Vol.+2&arAuthor=Anderson%2C+B.%3B+Crowell%2C+J.)
"The Underwater Vehicle Control software is incorporated. into the MissionP software, which runs on a low-power X86. CPU"
-
Browsing for something copletely different I found this site:
http://www.cdtv.org.uk/coldfire/
This effort now seems dead since 2004. Did this have anything to do with Elbox?
-
arnljot wrote:
Browsing for something copletely different I found this site:
http://www.cdtv.org.uk/coldfire/
This effort now seems dead since 2004. Did this have anything to do with Elbox?
No, that is Oli_HD's home project... Send him a PM :-)
-
bloodline wrote:
No, that is Oli_HD's home project... Send him a PM :-)
Nah, too shy :-)
Is he still working on this?
-
arnljot wrote:
bloodline wrote:
No, that is Oli_HD's home project... Send him a PM :-)
Nah, too shy :-)
Is he still working on this?
He's a nice enough chap... He'll tell you all about it if you ask him... I don't think he works on it any more, though I could be wrong.
-
Hello :)
-
Oli_hd wrote:
Hello :)
LOL, hello. Are you working on your coldfire accellerator?
-
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.
Theoretically I can't see why not... executables have an entry point, and libraries will have some table of functions. If you start at the entry point and take both directions on each possible conditional branch... why not? I guess self modifying code may cause a problem, perhaps also jump thunks.... or any code jumps that jump to locations based on run-time variables.. and a lot of that stuff is more prominent in C++ templates and game code. But certainly a lot of C executables could be converted with relative ease.
Not a robust solution or anything that would be used for general purpose emulation, but it isn't outright impossible.
Until Lord Piru corrects me ;)
Jarrod
-
@jarrody2k
Basically you'd need to emulate the whole program then. Just splitting at branches is not enough. You correctly note the dynamic jumps: this is a huge problem. There also are many points where the code are called from within the OS: For example interrupts, hooks and other callbacks.
So not only you'd need to emulate the m68k processor, you'd also need to trap every possible OS call. Also, some 3rd party library/device/whatever might be called that jumps into the the code, again generating a problem.
To correctly interpret everything would require running all possible codepaths in simulated environment. How does your simulation know when it's done? Running all possible codepaths in a given program take time x (x can be infinite). Running the same in emulation is not going to be faster than that.
-
hello. Are you working on your coldfire accellerator?
After the last prototype failed to work Ive been playing around with other things, I will be making a new prototype but doubt you will see a finished product from me, sorry.
I will keep working on it though as I would much rather see a Coldfire Amiga than a PPC board. (even though Im using a Cyberstorm PPC at home)
-
The Atari people are working on it. (http://www.atari.org/news/index.php3?id=article&number=1767)
-
(double post)
-
Piru wrote:
@jarrody2k
Basically you'd need to emulate the whole program then. Just splitting at branches is not enough. You correctly note the dynamic jumps: this is a huge problem. There also are many points where the code are called from within the OS: For example interrupts, hooks and other callbacks.
If the OS does call to the program, the program needs to let the OS know where to jump to. These function calls could be located and determined within translated code and the numbers changed to the new locations in the program. I presume it would be quite possible (maybe not trivial) to detect kernel function calls or native library calls of the particular OS functions that register callbacks/interrupts etc.
For the locations it does register, these should also be translated. So if the program registers some event response code for a button click, the code that is executed after that button click should be translated also.
So not only you'd need to emulate the m68k processor, you'd also need to trap every possible OS call. Also, some 3rd party library/device/whatever might be called that jumps into the the code, again generating a problem.
Surely libraries have some sort of function table where the entry points could be adjusted?
But certainly if code does tell another device/library to call back at a fixed point in code in a non-os friendly or unforseen way, this would be difficult to fix.
To correctly interpret everything would require running all possible codepaths in simulated environment. How does your simulation know when it's done? Running all possible codepaths in a given program take time x (x can be infinite). Running the same in emulation is not going to be faster than that.
Of course, any branches that branch back into already-translated code segments would terminate. I hardly think you could make an accurate progress bar apart from the amount of code translated versus the total binary size (of which will be partly data sections)... but all paths will come to an end because they will eventuall skip to another part in code that is already translated or will return control to the OS.
I am not saying any of this is trivial, far from the case. I am saying it is possible, and dare I say, achievable by an experienced team of software engineers.
Cheers,
Jarrod
-
jarrody2k wrote:
I am saying it is possible, and dare I say, achievable by an experienced team of software engineers.
As an experience software (and hardware) engineer. I'm saying it isn't.
-
@Jarrod
I too, used to think that a static translation would be possible... Instead of arguing, I compiled some C source code (I forget the program) then assembled it to object code, then disassmbled the object code and manually tried to convert the resultant 68k in to PPC assembler... I remember hitting a wall and asking questions on this very forum only to discover that there were descisions that I needed to make that only the original coder knew the reasons for and I would only be able to determine at run time. Basically you hit the same problem the VLWI guys hit when they tried to take the RISC concept to the extreme.