ARM or x86 with FPGA emulator

[matthey]

@matt, trying this phoenix demo under winuae on my surface pro gave me around 37fps. isnt that a little low in comparison? probably it rather reflects memory throughput than cpu speed, gunnars favorite argument if i recall well.

The Phoenix demo is not a very good test of CPU speed. However, a certain amount of processing power is needed to have a good frame rate. The demo shows that Phoenix has good performance and potential despite the scaled down core. It makes me wonder how much performance the full Apollo core would have in a larger fpga. Then I wonder how much rendering power the Apollo core would have with a fast fpga Amiga chipset like the Natami would have been. I don't think the 37 fps of UAE would be very difficult to beat.

[wawrzon]

right.

judging by the link the demo relies on 64bit multiplication, so thats probably where this softcore scores the best.   but the actually good news is that it runs already on vampire. would be fun to have more details.

[Iggy]

I like the idea of adding an FPGA to our existing PPCs.
JIT 68K translation would be much quicker than implementing the 68K in the FPGA and would leave room for chip set enhancements.
Running 68K and PPC code concurrently on processors operating at up to 2.7 GHz would greatly outperform any solution involving only the 68K.
A complete melding of legacy and NG environments.
What do you think?

[wawrzon]

dual core g5 running one core 68k and the other powerup? no, thanks. pure 68k code runs everywhere: amigas, uae, amithlon, fpgas, os4, mos, aros, pick your choice, no need for any further strange ideas.

[matthey]

right.

judging by the link the demo relies on 64bit multiplication, so thats probably where this softcore scores the best.   but the actually good news is that it runs already on vampire. would be fun to have more details.

I don't believe there was room for 64 bit integer multiply in the Phoenix core so it's like the 68060 in this regard. There had been talk of letting multiply and division execute OoO while the processor continues provided that there are no dependencies. The 68060 is in order for integer multiply and divide and only the first pipe can be used. With a few more resources, the 68060 could have had 1 cycle 16x16=32 in both pipes which would have quadrupled the most common multiply performance. That and adding SWAP into the second pipe would have been simple and provided a nice boost in performance. As for details on Phoenix, I think the team is too busy playing right now .

I like the idea of adding an FPGA to our existing PPCs.
JIT 68K translation would be much quicker than implementing the 68K in the FPGA and would leave room for chip set enhancements.
Running 68K and PPC code concurrently on processors operating at up to 2.7 GHz would greatly outperform any solution involving only the 68K.
A complete melding of legacy and NG environments.
What do you think?

It's not a bad idea if implemented correctly. It could probably be done cheaper and with better performance that a 68k in fpga. An fpga 68k can have better integration with the Amiga chipset and an eventual Amiga SoC could be created. An ASIC of the SoC may outperform the PPC setup (CPU+SoC performance) and has advantages. The cost could then be cheaper with enough unit sales. It's 2 totally different concepts but neither is bad. The PPC way could almost be done on the SAM with it's Lattice fpga but it's too small. Maybe the CIAs could be implemented .

[wawrzon]

i think something like this is on schönfelds list, but he apparently aims for mips. curiously he always claimed ppc were unstable by design, if hard to comprehend how they could get away with major flaws all these years.

[bloodline]

i think something like this is on schönfelds list, but he apparently aims for mips. curiously he always claimed ppc were unstable by design, if hard to comprehend how they could get away with major flaws all these years.

I think he might have been referring to the development path and supply of actual chips, which has never been particularly good. Even when Apple were using the chips, supply was poor due to Apple buying up all the Desktop/laptop grade units.

[takemehomegrandma]

i think something like this is on schönfelds list, but he apparently aims for mips. curiously he always claimed ppc were unstable by design, if hard to comprehend how they could get away with major flaws all these years.

You can say a lot about PPC, but a statement that this architecture would be more unstable than any other (individual flawed chips/designs aside) is indeed difficult to "buy"...

[takemehomegrandma]

I like the idea of adding an FPGA to our existing PPCs.

It would be like a ball and chain. Crippling. And expensive. And pointless. But other than that...

[wawrzon]

@bloodline, tmhg

well, he actually wasnt refering to supply but to own experience with designing devices, routers, such as his nequester. the technical difficulties with reaching desired stability have in his own words resulted in that he turned his back at ppc. even though statement as this seems unbelievable even to me, who is not a ppc lover, i either im able nor want to question his technical expertise, so i just leave it open.

just for the sake of interest here a genuine statement paradroids on a1k concerning the ppc controversy (english speakers will have to use some translator service, sorry):
http://www.a1k.org/forum/showthread.php?p=445998&highlight=ppc#post445998

[ElPolloDiabl]

@above
You like the PowerPC to program in assembler?

I've never tried, but it looked several times harder than 68k.

[LiveForIt]

@above
You like the PowerPC to program in assembler?

I've never tried, but it looked several times harder than 68k.

I've never tried, but it looked several times harder than 68k.

Not really, its just more instruction names to remember move does many things on 680x0 depending on syntax with '(' and ')' or whit out, PowerPC assembler does not have that.

Most PowerPC instructions have 3 parameters, parameter 1 and 3 is normally source and destination, number 2 is often optional, normally used for indirect addressing.

Etch of the letters in the instruction normally stands for some thing, if you remembering what letters stand for you can guess what the instruction does easily. If you spent just as much time whit PowerPC as 680x0 you remember the names.

'S' Store
'L' Load
'Z' Zero
'R' reverse order (little endien mode).
'X' Indexed addressing.
'B' Branch

And so on.

[matthey]

@above
You like the PowerPC to program in assembler?

I've never tried, but it looked several times harder than 68k.

PowerPC uses too many acronyms and aliases for the mnemonics. It is tedious and tricky to program efficiently being a load/store architecture but it does have more instructions than most RISC processors (the down side being some instructions are missing from the hardware of some PowerPC processors). Most instructions have 3 operands which is convenient. More has to be done manually and considered than the 68k which is auto everything and forgiving. Other than that, PowerPC is a clean and consistent 32 register load store architecture. It's actually similar in many ways to the new ARMv8 ISA.

The 68k is still much easier to program and debug. It's simple (mostly 2 operands) and consistent (unlike x86) with powerful addressing modes for working directly in memory. I love the tiny programs which helps performance also. It's the easiest and funnest halfway modern CISC processor. It could use some modernization where ease of use and code density can be improved more.

[bloodline]

PowerPC uses too many acronyms and aliases for the mnemonics. It is tedious and tricky to program efficiently being a load/store architecture but it does have more instructions than most RISC processors (the down side being some instructions are missing from the hardware of some PowerPC processors). Most instructions have 3 operands which is convenient. More has to be done manually and considered than the 68k which is auto everything and forgiving. Other than that, PowerPC is a clean and consistent 32 register load store architecture. It's actually similar in many ways to the new ARMv8 ISA.

 
Actually I noticed there was a slight similarity too, probably due to the 32 registers and inherent 64bit support. But the ARM v8 is very very clean, and not really meant for human eyes.

The 68k is still much easier to program and debug. It's simple (mostly 2 operands) and consistent (unlike x86) with powerful addressing modes for working directly in memory. I love the tiny programs which helps performance also. It's the easiest and funnest halfway modern CISC processor. It could use some modernization where ease of use and code density can be improved more.

68k is by far the nicest "CISC", and is assembly featured in my life I would opt for it... But the compiler (clang specifically) rules my coding now

That said, I totally love these 68k FPGA projects and think there is a place for them in our amiga world!

[Iggy]

It would be like a ball and chain. Crippling. And expensive. And pointless. But other than that...

Not really, as most NG code wouldn't use it.
And bit banging legacy code could.
Obviously running that would slow the system down, but only by choice.
And if it was supported by ASMP, no slow down of the other cores.

[ppcamiga1]

Clone-A with powerpc is exactly what is needed for Amiga community.

Really a pity that Jens to quickly gave up on that idea.

Not emulated 68k with AGA plus not emulated powerpc it would be really interesting.