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

[matthey]

Any Amiga program should be using the OS provided Maths libraries anyway Jim so as long as Hyperion provide libs with the same public interfaces but internally using code specific for this weird FPU then most stuff should be OK. Theoretically anyway.

The math libraries are ok for light use of floating point but they are a major bottleneck for heavy floating point use. Modern powerful processors use the FPU (and/or SIMD unit) directly which is much more efficient. It is too bad that what are left of embedded PPC processors have incompatible FPUs. They might as well switch to an incompatible integer unit while they are at it to get some standardization and consistency.

[matthey]

So choosing the P10xx, P201x or P202x would be a worse decision than picking P204x, P30xx, P40xx or P50xx (or even T1). Obviously the IEEE libraries will support things, but software compiled to hit the FPU directly is going to be trapping all over the place, until it's recompiled.

Trapping direct FPU instructions would be a fraction of the speed of direct FPU support. Using the IEEE math libraries would be much faster (maybe half the speed of direct FPU use). Are developers going to compile for an incompatible FPU? It is sad that A-Eon is this desperate to keep PPC alive and affordable. Now PPC will not only be incompatible with the 68k and Amiga custom chips but also the existing PPC platform. The new board is too weak and incompatible to appeal to the classes and too incompatible and expensive to appeal to the masses. Full speed ahead with incompatible embedded PPC processors though .

[matthey]

In spite of the obvious concerns, I'd still prefer to see OS4 running on this before making any kind of judgement on it's ability to run current software well.

It's possible that software like OxyPatcher/CyberPatcher/MuRedox for the 68k could keep the PPC FPU instructions from trapping but it is still a poor choice of processors which makes Amiga support, development and keeping compatibility more difficult. Emulation is faster than trapping so PPC emulation on an i7 would have even more of an advantage in performance and price.

[matthey]

Reading everyones comments in various sites I'm not really sure how important FPU is. Some says it's used for a lot of OS and software related stuff, others that it's only used in some games. Which is it?

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?

[matthey]

That's the same suspicion i have of most OS4 ports too. I'm optimistic that stuff that Broadblues and others have written that is original OS4 software will use OS routines though.

It is more likely his software relies on compiler support code which may use the OS or processor specific instructions depending on compiler options. Blender needs to use the FPU and SIMD directly (FPU and SIMD instructions in the processor code) for near maximum performance.

Fastest - SIMD instructions (direct use)
Faster - FPU instructions (direct use)
Fast - IEEE libraries using the FPU
Slow - IEEE libraries without an FPU
Slower - Patch FPU instructions in the code before execution, no FPU
Slowest - Trap FPU instructions in the code during execution, no FPU

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

[matthey]

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.

The article I linked to has performance tests but they are for individual floating point instructions/functions. Obviously, a function/instruction like fabs is going to be near full speed (possibly a faster operation in an integer register) while a fsqrt is going to be slower than slow. The 3 common floating point emulations are compiler softfloat, FastFPE and NetWinder (NWFPE). The performance varies with the effective precision where the hardware FPU has the most precision for the floating point format (half, single, double, extended, quad). The effective precision of the floating point data in the IEEE floating point format is already reduced during many operations (extended precision like the 68k FPU uses can avoid this) with a hardware FPU. Some applications like games and 3D graphics probably want the best performance but math, science and engineering people would rather have extended precision floating point like the 68k FPU uses.

I could not find any good comprehensive benchmarks but I did see that one of the FastFPE authors using a StrongARM@200MHz with a Linux kernel tested 1.1 MFlops with a ~570 ns trap overhead and 0.4 MFlops with a ~2040 ns trap overhead. ARM claims 1.3 MFlops/MHz for the VFP9-S and 2.0 MFLops/MHz for the VFP10 which would be 260MFlops and 400MFlops at 200MHz respectively. I doubt any applications or games would use enough floating point to benchmark several hundred times faster on a StrongARM@200MHz with VFP but maybe it gives an idea of how handicapped software floating point can be.

http://linux-arm-kernel.infradead.narkive.com/gqDFIXbv/kernel-2-6-and-fastfpe

[matthey]

im pretty sure fpus are totally overrated. it just a fancy of chip designers. all the code is equally well executed in software. same for all other sorts of hardware acceleration btw.

Nice sarcasm. Yea, the Amiga started with hardware acceleration where possible and practical and now we fall further and further behind by using outdated and embedded processors without hardware support while less expensive PCs use more and improving hardware acceleration. Trapping floating point instructions with software floating point operations vs an advanced SIMD is a good example of the extreme difference. PPC will catch up any day now though.

I would say FPUs (floating points in general) are underused on Amiga. I was portit one my app from MorphOS to AmigaOS 3 and I really had problem what FPU model I should target at. There are many options (68881, 68882, 68040, 68060 and handful of math libraries) you have to choose from. Had I written the software for the 68k target first I would have used integers only.

The 68881 and 68882 are essentially the same target even if it is possible to specify one or the other. Vbcc will generate the exact same code with 68881 or 68882 specified. The 68040 and 68060 FPU are similar but the 68040 made the biggest blunder in processor history by leaving out the common FINT/FINTRZ instruction which the 68060 fixed. There are big differences in the instruction timings and exception handling between the 68040 and 68060. Code compiled for the 68040 should work on the 68060 and vise versa but with reduced performance. Code compiled for the 6888x will work on the 68040 and 68060 but with further reduced performance (from lots of trapped instructions). Code compiled for the 68040 or 68060 may not work for the 6888x (GCC=no, vbcc=yes). Heavy use floating point applications will benefit from multiple executables for all 68k CPU+FPU processors or 6888x and 68060 (telling 68040 users to use OxyPatcher/CyberPatcher/MuRedox). Light use 68k floating point can target the IEEE math libraries, 6888x-68060 or 6888x. I compiled vbcc using vbcc with both the IEEE libraries and direct 68060 FPU support and found no significant difference in speed of my test compiles (to my surprise). Testing will give a good indication of what is best for a particular application.

[matthey]

All very interesting, and it does demonstrate how big such overhead can be. Nevertheless, none of the results in the documents you linked to are for the P1022 or even for a PowerPC processor.

ARM processors (usually for embedded) are the most common processors without hardware floating point. PPC processors without an FPU are highly unusual so we will have to wait for benchmarks. I do expect adding efficient software floating point support to PPC will be more work due to it being unusual. I also expect the trapping overhead of PPC to be higher than ARM where fast traps and fewer registers are an advantage.

Is VBCC using floating point much? It is supposed to run on systems without FPU...

Vbcc is not using floating point much which is why the overhead of the IEEE math libraries doesn't make much difference. The 68k vbcc distributions use the IEEE math libraries so they work without an FPU but gain performance from a FPU. Vbcc and vasm primarily use floating point when compiling programs which use floating point so performance could vary substantially from my testing. I had originally wanted to create optional higher performance vbcc distributions compiled for the 68020+6888x and 68060 but the performance difference wasn't enough to warrant them. Floating point precision is better with direct FPU support than the IEEE math libraries and it was important to test the vbcc vclib floating point work I had done (new m060.lib) so it wasn't a complete waste of time.

[matthey]

What does that mean? Floats have a very specific use, which is to trade accuracy for a greater range (they effectively are lossy compression).

Floating point does trade precision for range but it has other uses. There are standard C support functions to handle floating point including fractions while there are none for fixed point integer fractions. This is very convenient and probably the most common reason to use floating point. There are other less obvious advantages and disadvantages.

AND, with that in mind, I've buried my hatchet (and, no, not in this guy's skull).
IF priced in line with its value...it could start a trend that leads to future affordable hardware.

I see the trend to less standardized and weak handicapped hardware as a negative regardless of price. It is kind of like a 68EC060 in a classic Amiga accelerator which is a bastard. It may be cheaper and it may work with AmigaOS but enough 68060 software will fail that the mistake will become evident. Compatibility and standardization are two of the few advantages the Amiga has left. Throw these away and the value of even relatively low priced hardware is reduced. I believe the Amiga masses will accept reduced performance before reduced compatibility. My priorities for new Amiga hardware are:

1) compatibility (not an Amiga without it)
2) price
3) performance

PPC is acceptable at performance but will never be good at compatibility and price. Insistence of PPC only is likely ignoring the Amiga masses (biggest Amiga market). The Amiga classes are already buying more expensive PPC hardware. I hope there is an embedded customer for these boards.

[matthey]

True, C does lack a fixed floating point type. That doesn't mean that using a float is in any way a good idea though. Just that the consequences doesn't trump the laziness of implementing with fixed point maths. You can also stir paint with a screwdriver.

It's surprising that neither C99 nor C11 have added 16.16 and 32.32 integer fixed point data types and support. They could be useful as a standard optional feature, especially for embedded processors without an FPU.

The best case overhead of using hardware floating point is not much in a modern processor. A few more pipeline stages are required (compared to a similar length integer) for normalization but this provides saturation saving min/max or saturating integer operations for some algorithms. The longer pipeline adversely affects floating point branches (I advocated new branchless FMIN/FMAX 68k FPU instructions for this reason) and integer<->fp conversions. The worst case overhead for out of range subnormal/denormal handling depends on the hardware implementation but can be very high for mostly software handling. More hardware precision like extended precision floating point can avoid some of the overhead while SIMD units may do a simple rounding of subnormals (giving inaccurate results).

[matthey]

Backwards compatibility is purely about preserving the previous generations bad ideas. It's why I think that at the very least there should be support for a full 060 with compatible MMU & FPU in FPGA reproductions, not because everything about the 060 implementation was a good idea but because it existed.

I don't understand your seemingly contrary statements. You say that backward compatibility is "preserving the previous generations bad ideas" which implies that an 060 compatible MMU and FPU were a mistake yet you want to keep them? Was a standard PPC FPU a bad idea since the P1022 CPU dropped the standard FPU?

I think you misunderstood my point though. Just because C includes printf() etc support for floats doesn't mean you should use floats when you decide whether to use fixed point or floats. Floating point is a huge compromise and unless you understand all the compromises then you can't say whether it's a good idea or not. If you are writing anything that involves money then you should definitely avoid floating point, cross platform code where the results need to be consistent (even across x86 platforms) should avoid floating point.

While you have correctly highlighted some of the problems of floating point data types, I believe you have also exaggerated the problems. Some numbers can not be represented exactly but choosing a floating point data type with adequate precision usually gives a good enough approximation. It is important to realize that the effective floating point precision is commonly several bits less than the data type precision due to cumulative rounding errors and more precision needed in some algorithms to maintain full data type precision (thus the usefulness of extended precision fp for simpler and higher effective precision double precision fp calculations). Cross platform floating point results can vary but this is usually not a problem unless precision or accuracy are lost. The IEEE standard reduces variance but there are still several reasons why results may vary. Money calculations in high precision floating point should give a good approximation although an exact data type is preferable for financial use.

Sure in your example you can justify it because you are unlikely to get any bug reports if the volume is slightly wrong, although you shouldn't compile it to require an fpu as that is putting an unnecessary requirement.

It would be nice if a version of the program is available which does not require an FPU. Should or shouldn't isn't really up to us though.

[matthey]

I want to keep them for backward compatibility. It's not contradictory at all.

Logically then, I must infer that you want to keep compatibility even though it is "preserving the previous generations bad ideas". This was not clear to me in what you wrote.

Of course they weren't necessarily bad ideas at the time, but some things make less sense now than they did but that doesn't mean they shouldn't be supported. Otherwise we might as well just switch to x64. I personally wouldn't even think about extending the ISA until a compatible CPU+MMU+FPU was implemented & then I'd work on adding switchable 64 bit mode to the CPU+MMU.

Supported can mean trapping every FPU or MMU instruction though. The Apollo Team discussed trapping all FPU and MMU instructions for the 68k. I didn't like it, especially for the minimal 68060 FPU which has a nice ISA considering its age. The MMU is more of a problem as adding modern enhancements while maintaining high compatibility is more difficult. There is not much Amiga software using the MMU though.

I don't know enough about PPC, but from an outsider the entire CPU seems like a bad idea.

I don't see anything inherently bad about PPC other than it is currently out of favor and losing market share. Sure, instruction acronyms and aliases are out of control, the ISA is so broad that hardware implementations are incomplete, assumptions about what the compiler could do and assembler programmers would not have to do were incorrect and the ISA is overall less friendly and the code not as compact compared to the 68k but the new ARMv8 (AArch64) is very similar and makes some of the same mistakes.

They are. Precision on x87 is variable per process on Windows and Direct3D changes it under you (I have no idea what precision Linux selects). The same software compiled for x64 will behave differently because the accuracy is different again (floating point appears to use SSE and not x87 on x64).

The x87 FPU was a poor design that was more difficult than the 68k FPU to modernize. Newer x86 software has been using the SIMD for floating point since 1997, except for a few programs needing higher precision, trig instructions or logarithm instructions. Yes, the precision of each floating point data type can vary by compiler (with options) even on the same computer. It is up to the programmer cross compiling or porting software to be aware of these kinds of problems which are not uncommon. Integer formats vary by data type (according to the ABI) as well.

It makes noticeable differences in some software, stuff like collision detection in multiplayer games becomes horrendously complicated. You have to have a huge QA team to find all the problems. If you can avoid that then it's much easier. Sometimes you can't avoid floating point because of performance, but in the code I worked I never found switching to float with 68882 to be faster than integer (x86 performs differently though).

Some uses of floating point are bad and some programmers are amateurs. This doesn't mean everyone should stop using floating point and hardware floating point should be removed.

The 6888x FPUs were very slow, as most external FPUs were, because of the slow communications between the CPU and FPU. It made sense to do complex instructions on the FPU which reduced the communications overhead. As the processors became faster and integrated FPUs reduced the overhead, simple FPU instructions made more sense. This is why the 68040 and 68060 trapped many complex instructions while keeping many of the common ones. This was a good idea, IMO, although I would have kept a few more simple but useful FPU instructions (they did keep the most common core instructions in hardware). The x87 FPU kept all their instructions as it became integrated but they had this crazy stack based (no FPU registers like the 68k or PPC "standard" FPU) instruction argument scheme which was not easy for compilers or good for superscalar execution so they deprecated the whole FPU and added more floating point support to the SIMD. The x87 FPU also had more inconsistencies and bugs than the better designed and more IEEE compliant 68k FPU which may have added extra incentive to deprecate it.

Running integer code on one core and having it switch to another to emulate the FPU would be horrendously slow. If it is just a couple of commands that throw exceptions then it probably isn't a big deal, but it would surely be done on the same core. The fpu in the e500v2 (P10xx series, P2010 and P2020) appears to be completely incompatible to the classic PowerPC, but the e500mc (P204x, P30xx and P40xx) is supposed to be compatible to the classic PowerPC fpu. It would have seemed more logical to use a P204x instead of a P102x. The announcement is a little strange as it said 1.2ghz (which is the speed of the P202x) and not 800mhz (which is the P102X).

I only saw disadvantages to having the 2nd core handle the 1st core's trap but then I don't have much multi-core programming experience (maybe Jens doesn't either). I at least looked at some P1022 CPU documentation that seemed to suggest that all "standard" PPC FPU instructions (and registers) have disappeared and would need to be trapped. The documentation I found was not very good but no one has claimed I was wrong yet.

[matthey]

By the way Trever did confirm in his Amiwest 2015 presentation the the T series cpus were not available when the Tabor design was started.

Maybe we need a poll. Which of the following choices best applies to the P1022 PPC CPU choice without a compatible PPC FPU for the Tabor motherboard?

1) poor decision
2) bad decision
3) desperation

Is the writing on the wall not clear enough? It says, "PPC is dying and the remaining choices are slower, more expensive and/or handicapped". Freescale being bought out makes it easier for the new parent company to say we didn't promise anything regarding PPC. If there is not desperation yet then there could be at any time and very likely will be in the future. If not wanting to give up PPC then diversifying outside of PPC could allow Hyperion and/or A-Eon to survive the demise of PPC (if it is not already too late). Maybe Amiga Inc. understands and is patiently waiting to get their now "developed" intellectual property back for free.

I rather suspected that the e500 core would outperform an Applied Micro core.
So it is a move forward, especially in consideration of the fact that it is a dual core cpu.

That 30% will more than cover any deficit that fpu emulation will cost.

30% faster integer performance will make some applications feel snappier while others with heavy floating point use (like Blender) will likely run at a fraction of the speed of a PPC with standard FPU. It's kind of like hiring a motivated worker who is missing one arm. He may be a little faster than average at some jobs but is going to have major trouble doing some work.

[matthey]

I have run AmigOS 4.1 update6 on Sam440ep-Flex,FE on Sam460ex.
Linux on both Sams and the Tabor.
I have run Both the Special FPE Debian on the Tabor and the regular
Debian with the emulated floating point on the Tabor.
The Tabor is much faster than the Sams under Linux .

Linux is probably using both cores of the Tabor CPU so it would be significantly faster at integer math than the SAM. FPU trapping probably isn't going to be noticeable for light floating point use while being devastating to heavy use floating point programs. Run a MFlops benchmark under Linux using the traps on the Tabor board and let us know how it performs. The AMCC (SAM) 460EX gives 2.0 MFLOPS/MHz. I would be surprised if the P1022 can do 10% of the SAM's MFLOPS with trapping. Traps have a huge amount of overhead (20+ cycles per trap) and allow no superscalar parallelism.

Well, one vote for 'poor decision' but not a lethal one.

I'll wait to place my vote but I have low expectations. My scale would go something like this:

0) acceptable decision as better than half the FLOPS of the SAM 460
1) poor decision as 1/2 - 1/4 the FLOPS of the SAM 460
2) bad decision as 1/4 - 1/8 the FLOPS of the SAM 460
3) desperation as worse than 1/8 the FLOPS of the SAM 460

Is there an NG port of Blender?

Andy Broad did a port of Blender to AmigaOS 4.

http://www.broad.ology.org.uk/amiga/blender/

I can't picture it working well on a single core system with memory limitations.

What makes you think the 68k can't do multi-core? It is not much more difficult than copy and paste of an existing FPGA CPU core. The FPGA has an advantage of being able to deal with problems like the executive base forbid counter in a more compatible way. I believe the 68k in FPGA has a better chance of preserving compatibility while exceeding the 4GB addressing barrier. The PPC can not use 64 bit pointers and keep compatibility with AmigaOS 3 or AmigaOS 4 because structure sizes would change. Better code density (smaller code size) is an advantage with a memory extension like XMS for the PC. How many Amiga 68k users complain about 128MB of memory not being enough compared to Amiga PPC users complaining about 512MB not being enough? I wonder how much memory the Tabor FPU trapping support code will take up?