New ppc board by Acube/A-Eon: A1222 "Tabor"

[Bif]

The AmigaOS does *not* use floating point much. Amigas without an FPU do the few floating point operations in software. However, many modern applications and games use floating point heavily because floating point on modern powerful processors has become cheap with a fast FPU and/or SIMD unit (using direct FPU and SIMD instructions in the code). These applications and games will be anywhere between slow and unusable on a low end processor without any hardware floating point support.

Even the Apollo 68k FPGA core recognizes the need for hardware FPU support and compatibility. Gunnar at first only wanted to create FPGA floating point code for the most important single precision (only) IEEE math library functions as this takes the least amount of FPGA space. The C language uses double precision floating point the most and by default and programs using the 68k FPU directly would need to be trapped or patched on the fly (the same as this cheap embedded PPC CPU). I strongly recommended against this and suggested that it was better to wait until there was space for a better solution. Next, Gunnar wanted to add a SIMD unit instead of the 68k FPU (the x86_64 uses the SIMD unit for floating point). There was no room even for single precision floating point support in the SIMD unit so floating point code (and algorithms) would have to be converted to integer code (which is no small task). Single precision floating point would be added to the SIMD unit when there was room but this was no floating point support at all for now. Once again I strongly recommended against adding an SIMD unit without single precision floating point (the most important IMO). A 68060 compatible FPU with direct FPU support and at least double precision is exactly what compilers and floating point using programs need so I highly recommended this. Gunnar doesn't like FPUs and was worried this would be too slow in FPGA. I figured out how to encode twice as many FPU registers allowing for faster instruction interleaving at his request. I also had a few simple suggestions for enhancements I had learned from working with the vbcc vclib floating point math libraries. It looks like the FPU was finally chosen for compatibility on an old 68k CPU which didn't even start with an FPU. PPC is *more* likely to need and expect an FPU, especially without Altivec. I wouldn't be surprised if the Apollo core with FPU support (in an FPGA) outperforms this hard PPC processor without floating point hardware support for floating point intensive programs. This is with the Apollo core being a fraction of the speed of a hard processor and having a fraction of the floating point performance of a SIMD unit for parallel operations. What developers are going to bother with such weak and incompatible floating point performance as this PPC embedded processor?

I do think in this day and age processors with only scalar FPU support are a little bit pointless. May as well go SIMD FPU or go home. Like you said with X64 mode, scalar FPU isn't even an option, only SIMD is available. For scalar operations you just ignore the high elements of your SIMD registers. They still compute as fast as the scalar FPU would compute them.

I think you can get a ton of mileage out of just a handful of SIMD/FPU instructions - multiply, add, subtract, and enough permute and conversion operations to get your data ready for those appropriate math operations.

Anyway, I think in that sense worrying about current Amiga scalar FPU instruction sets and compatibility/performance might be slightly overblown. If we really want to crunch through a lot of floating point values at some point it might be wise to create or adopt a SIMD FPU instruction set everyone could adopt going forward.

[matthey]

Does anyone have any hard data on the performance with software trap based FPU emulation? I'd be interested to see how much of an impact it actually has, but I can't find any published benchmarks anywhere.

Hard data is going to be difficult to find. How are the floating point operations going to be performed after the exception?

1) full precision floating point using integer instructions
2) reduced precision floating point using integer instructions
3) partial hardware accelerated floating point (possible with this new PPC board? Lattice FPGA?)  

The following link is a paper discussing the floating point options and performance for a processor without an FPU.

http://www.ll.mit.edu/HPEC/agendas/proc08/Day1/11-Day1-PosterDemoA-Spetka-abstract.pdf

The performance difference is going to depend on the number of exceptions generated. Also, some floating point operations are much more difficult to perform with integer operations than in hardware. Light floating point use may see no difference in performance while heavy use will likely be a night and day difference. OxyPatcher/CyberPatcher/MuRedox patching of 6888x FPU code on a 68060 can be 50% faster with heavy floating point use and this is with the most common 6888x instructions available in the 68060 FPU. These patchers have partial floating point hardware acceleration by using the simpler 68060 FPU also. No hardware floating point acceleration and full precision with integer operations would be devastating to floating point performance.

I do think in this day and age processors with only scalar FPU support are a little bit pointless. May as well go SIMD FPU or go home. Like you said with X64 mode, scalar FPU isn't even an option, only SIMD is available. For scalar operations you just ignore the high elements of your SIMD registers. They still compute as fast as the scalar FPU would compute them.

If creating new floating point hardware, a combined FPU and SIMD (the result being a SIMD) like the x86_64 makes a lot of sense. An FPU with double precision support for C programs and an SIMD which is single precision only also has advantages (PPC with Altivec way).

I think you can get a ton of mileage out of just a handful of SIMD/FPU instructions - multiply, add, subtract, and enough permute and conversion operations to get your data ready for those appropriate math operations.

Right. Keep it fairly simple for hardware floating point support. Hardware designers need to pay attention to what compilers need and are using where they have made major mistakes before in cutting common and valuable instructions though.

Anyway, I think in that sense worrying about current Amiga scalar FPU instruction sets and compatibility/performance might be slightly overblown. If we really want to crunch through a lot of floating point values at some point it might be wise to create or adopt a SIMD FPU instruction set everyone could adopt going forward.

Both the 68k and PPC would probably maintain a separate FPU and SIMD for compatibility. This requires more logic but the SIMD only needs to support single precision floating point which saves some logic. Today, logic savings isn't as important as compatibility or performance.

[zylesea]

I regularly read that OS4 is not A-Cube's main market, and they mostly sell their PPC boards to the embedded market.  Is there any proof of this, or is it just a forum urban-legend?

I asked that question several times over the recent years, too and never got much evidence tehy significantly sell to teh embedded market.
At least they tried to get more active on the embedded market as they partnered up with MasEletronica a few years ago. And indeed Acube is still listed as partner at MasElettronica's hp, but bo Acube products are listed by MasElettronica. All  in all I guess Acube is a part time biz focusing very much at the Amiga ppl but also a few non Amiga related sales.

[Hans_]

Hard data is going to be difficult to find. How are the floating point operations going to be performed after the exception?

1) full precision floating point using integer instructions
2) reduced precision floating point using integer instructions
3) partial hardware accelerated floating point (possible with this new PPC board? Lattice FPGA?)  

I'm talking about whatever FPU emulation is currently available (under Linux), using whatever benchmarks are available. Sure, people can argue ad nauseum about whether benchmark results are meaningful, but having any data would be better than making big claims about performance based on assumptions.

Of course the emulation is going to have overhead; I'd like to know how it actually performs.

Hans

[Iggy]

I thought that you had already decided to get an X5000.
If that was the case then the Tabor should not bother you.
It being good,bad or indifferent should not affect your original plans.

Actually, it does in that Tabor looks like a design intentionally hobbled to prevent it from competing with the higher end products.
It presents compromises not born of economic or engineering rational, but of pure marketing BS.
So, I question whether its wise to continue to support higher end A-eon products, if marketing plays such a large role in the company's design decisions.

This isn't meant to be personal, and I wasn't the first to go there.
I'm not trying to sell anything, I'm just warn my friends about a product I believe would be best avoided.

And, btw, I'm not to keen on getting blown off by you OR Andre Siegel when I have been in this trade as long or longer than either of you.
On my worst days, tin foil hat and all, I've got more brain cells firing than most Amigans.

[Iggy]

The AmigaOS does *not* use floating point much. Amigas without an FPU do the few floating point operations in software. However, many modern applications and games use floating point heavily because floating point on modern powerful processors has become cheap with a fast FPU and/or SIMD unit (using direct FPU and SIMD instructions in the code). These applications and games will be anywhere between slow and unusable on a low end processor without any hardware floating point support.

Even the Apollo 68k FPGA core recognizes the need for hardware FPU support and compatibility. Gunnar at first only wanted to create FPGA floating point code for the most important single precision (only) IEEE math library functions as this takes the least amount of FPGA space. The C language uses double precision floating point the most and by default and programs using the 68k FPU directly would need to be trapped or patched on the fly (the same as this cheap embedded PPC CPU). I strongly recommended against this and suggested that it was better to wait until there was space for a better solution. Next, Gunnar wanted to add a SIMD unit instead of the 68k FPU (the x86_64 uses the SIMD unit for floating point). There was no room even for single precision floating point support in the SIMD unit so floating point code (and algorithms) would have to be converted to integer code (which is no small task). Single precision floating point would be added to the SIMD unit when there was room but this was no floating point support at all for now. Once again I strongly recommended against adding an SIMD unit without single precision floating point (the most important IMO). A 68060 compatible FPU with direct FPU support and at least double precision is exactly what compilers and floating point using programs need so I highly recommended this. Gunnar doesn't like FPUs and was worried this would be too slow in FPGA. I figured out how to encode twice as many FPU registers allowing for faster instruction interleaving at his request. I also had a few simple suggestions for enhancements I had learned from working with the vbcc vclib floating point math libraries. It looks like the FPU was finally chosen for compatibility on an old 68k CPU which didn't even start with an FPU. PPC is *more* likely to need and expect an FPU, especially without Altivec. I wouldn't be surprised if the Apollo core with FPU support (in an FPGA) outperforms this hard PPC processor without floating point hardware support for floating point intensive programs. This is with the Apollo core being a fraction of the speed of a hard processor and having a fraction of the floating point performance of a SIMD unit for parallel operations. What developers are going to bother with such weak and incompatible floating point performance as this PPC embedded processor?

Thanks.
If it wasn't an important issue, I would have been using the reduced cost '060 EC and LC chips that were available at the end of production.
They easily clock from 75 to 100MHz, but with out the fpu, relying on replacement math libraries, their performance is INFERIOR to slower clocked full '60s.

[Everblue]

Actually, it does in that Tabor looks like a design intentionally hobbled to prevent it from competing with the higher end products.
It presents compromises not born of economic or engineering rational, but of pure marketing BS.

Do you mean that they actually made a bad product (which may not even become commercially available) just to make the X5000 look better? Has anyone actually contacted A-EON so we hear their side of the story on this?

[Spectre660]

I am totally confused now.
http://www.amiga.org/forums/showpost.php?p=797215&postcount=12

[itix]

I'm talking about whatever FPU emulation is currently available (under Linux), using whatever benchmarks are available. Sure, people can argue ad nauseum about whether benchmark results are meaningful, but having any data would be better than making big claims about performance based on assumptions.

Of course the emulation is going to have overhead; I'd like to know how it actually performs.

I am very surprised if Linux had FPU emulation there...

[Iggy]

Do you mean that they actually made a bad product (which may not even become commercially available) just to make the X5000 look better? Has anyone actually contacted A-EON so we hear their side of the story on this?

If you haven't noticed, we have been getting a hard sell on this project from people directly involved with it.

This has put me at odds with at least one MorphOS developer even though its unlikely that that OS will get ported to this board.

And the whole mess has been complicated by some personal crap that I let myself get draw into.

Frankly, I'm disgusted, disappointed with all involved (including myself), and ready to take a break.

Edit: But I DO owe Trevor this, NO compromises don't necessarily mean that the flaws are as much intentional as they are accepted. They must have thought this would be "good enough" for you all.

[Everblue]

Well to be honest I don't really know who is who, or the politics involved, I want just to be sure that if I invest my money in a Tabor (or anything else), I am not ripped off my money by a lack of important feature.

[Iggy]

Well to be honest I don't really know who is who, or the politics involved, I want just to be sure that if I invest my money in a Tabor (or anything else), I am not ripped off my money by a lack of important feature.

No, I wouldn't go THAT far.
It is only MY opinion that it doesn't represent a good investment of your funds.

And I've been willing to recommend the X5000, so my views can be skewed.

You are spending a boat load of money either way, but at least one choice offers you something you can take pride in owing.

[yssing]

I am sure no one will be ripped off.
Actually it is very simple, if you don't like, any given product, don't invest in it.

I am also sure, that Acube and A-EON, would not produce a product, with out solutions to, what ever, problems could arise.

[Everblue]

I agree my choice of words was not the best. I am sure that A-EON will explain their choices for "Tabor" and what this means for the end user so more knowledgeable purchasing decisions can be made, so no one feels "ripped off".

Hope that amends it Anyway I guess at Amiwest we will learn more.

[number6]

I agree my choice of words was not the best. I am sure that A-EON will explain their choices for "Tabor" and what this means for the end user so more knowledgeable purchasing decisions can be made, so no one feels "ripped off".

Hope that amends it Anyway I guess at Amiwest we will learn more.

An almost identical comment was made on AW, so I'll post the same response:

What will come out of AmiWest is just speeches unless people take advantage of the opportunity:

Please post questions for participants

#6

[zylesea]

I am also sure, that Acube and A-EON, would not produce a product, with out solutions to, what ever, problems could arise.

Like providing drivers for inbuild devices in a narrow time scale? Impressive track record i that regard...