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

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

[eliyahu]

@thread

ok, guys. this is starting to get out-of-hand. please keep conversation focused on the new tabor boards (despite not knowing terribly much about them) and no personal attacks, please. if you want sling mud and score points, do it elsewhere.

-- eliyahu

[kolla]

Based on previous experiences with FPU less Linux systems, you do not want to compile for FPU emulation (soft float) - it is dreadfully slow - you want to replace any software that relies on FPU with software that only does simple integer math.

[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

[wawrzon]

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.

[itix]

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.

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.

[wawrzon]

@itix

as long as you are staying with and run parallax scrolling games as popular on amiga you will be fine with integers. who needs all these 3d software flooding us to the death anyway.

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

[Hans_]

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

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.

The performance of such an emulator will depend on a number of factors ranging from how well the emulator itself has been designed (i.e., the software) through to the CPU architecture and indeed the design of the individual chip. I have no idea how any of these factors compare between the P1022 and the ARM CPUs in the test results, so I'd really prefer some results from the actual device.

Hans

[itix]

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

My programs was not using floats much. I just used floats for convenience. I think I tried using math libs first but stumbled on some issue why I couldn't use it. In the end I used 68882 target although it really requires fast 68060 (for other reasons than floats).

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.

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

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

[Spectre660]

No official price for Tabor has been announced.
Figure quoted is not correct.


http://amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=40622&forum=2&start=300&viewmode=flat&order=0#770615

[SACC-guy]

@thread

To My Knowledge, No price and NO specs have been announced!
Please inform us when these details are announced.

M

[Everblue]

No official price for Tabor has been announced.
Figure quoted is not correct.


http://amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=40622&forum=2&start=300&viewmode=flat&order=0#770615

Thanks for that link
Would be nice if the board is much cheaper than 700 Euro!

Anyway, what does the following bit imply/mean, as I am not a technical person:

"The demo at the show was Debian 8 running an HD video concurrently with the 3D Gears demo and an animated Libre Office presentation."

[Oldsmobile_Mike]

Anyway, what does the following bit imply/mean, as I am not a technical person:

"The demo at the show was Debian 8 running an HD video concurrently with the 3D Gears demo and an animated Libre Office presentation."

Means that it doesn't bog down when multitasking like a single-core Athlon XP trying to play multiple YouTube videos at the same time (ask me how I know this, LOL).  

[wawrzon]

Means that it doesn't bog down when multitasking like a single-core Athlon XP trying to play multiple YouTube videos at the same time (ask me how I know this, LOL).  

ill just copy my considerations from aw.net in here:

i would expect linux to decode and play video content on the gpu, the machine merely shoving video data through the bus. also i would expect linux to have working hardware mesa/gallium acceleration, so it shouldnt have problem with playing the simplest gl demo. i dont know what the libre office presentation do, but i expect that, similarly to video, displaying demo of office software isnt demanding what concerns the cpu or fpu. taking into account that so far i know neither full gpu, nor 3d acceleration, nor even libre office is available for os4, i doubt that such a presentation gives a reliable estimation about, how os4 would run on particular hardware.