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

[wawrzon]

Does this sound like people who rely on this to make a living or like individuals who work on this as a passion project (like pretty much anybody else in this community)?

not even individual computers, while serving hobby customership, is being run as charity. as long as one dedicates a finite amount of his time to what is his hobby anyway, as in case of software, and then shares it with others, it is one thing. but as soon as you yourself need to make considerable investments, as in case of hardware development, production, retail and service, if you wouldnt expect return at least at some point in the future, it would be straight out giving money away to strangers. i have hard time to believe anyone in hardware branche is operating like that, not in amiga, not even in os4 sector.

edit: after consideration the closest to what i describe above is probably majsta and his vampire boards, still he resonably tries to keep his investments covered, even if certainly his dedicated time isnt any close to generate return. from this perspective, as own development acube boards are probably being sold at some discount, which is possible as long as it is as an "in house" development. in contrary to that aeon initiatives seem to be based on a sort of shares, sold to fans with the hardware they purchase. not shares on the company though, but rather contibutions to finance certain hardware projects.

[nicholas]

is this a smartphone perhaps?

http://www.intel.com/content/www/us/en/compute-stick/intel-compute-stick.html

 Not the best choice of argument there.  I've got an ASUS Transformer T100 TAM with a faster version of that same CPU and it's performance is terrible under 32bit Windows 10 Pro, slightly more tolerable under 64bit Linux but not much more.  

[eliyahu]

@thread

since folks seem rather, er, excited by the new board previewed at nuess, let's try another approach. instead of pontificating on something without the full facts, let's get some. i'll be at amiwest in a few days (i'm on the train now, actually) and will try and get your questions answered from trevor and matthew.

so, feel free to post your questions in this thread or send them to me via PM. even if the answer is "we can't say at this time," i'll report back. to get the ball rolling, here are my questions:

• can you give us the background as to why the P1022 was chosen for this board rather than, say, one of the T1 series?
  
• is the board primarily aimed at amigans, or also for embedded clients, as with acube boards in the past?
  
• how will hyperion be dealing with the e500v2 FPU? what are the estimated performance impacts?
  

anyone have any others?

-- eliyahu

[nicholas]

Huh, V8 exist for PowerPC now?

 For quite a while now.  https://developer.ibm.com/opentech/2015/06/30/ppc-support-for-google-v8-goes-mainstream/

[Andre.Siegel]

I do not know how is it in Italy but as long you do not have got lots of money by someone else you have to earn it

How does operating ACube preempt any of the involved individuals from having other means of income? Do you think their Amiga customers require so much time that it would not leave time to pursue other activities?

[kolla]

For quite a while now.  https://developer.ibm.com/opentech/2015/06/30/ppc-support-for-google-v8-goes-mainstream/

Cool, that is the greatest news for me on this thread, haha

[broadblues]

Let's assume that Acube/A-Eon knew about the FPU problem. If so, then what would be the reason to choose it anyway? Are there no price worthy alternatives they could have used instead? Or did they reason that the FPU isn't that important?

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?

It's used in games, programs like blender, my own SketchBlock is very floating point based as I use ARGBfloat pixels , these kind of things would benefit from a recompile, much as you might have for 68060 in the olden days.

I have read people say that FPU is also used in OS for optimised coppies etc, if so this is done inside the OS and so alternate optimisations can be used, every machine type has a slightly different kernel, there no reason to expect this one would differ in that.

[nicholas]

It's used in games, programs like blender, my own SketchBlock is very floating point based as I use ARGBfloat pixels , these kind of things would benefit from a recompile, much as you might have for 68060 in the olden days.

 Do you use the OS Maths libraries in your own stuff or internal routines?  I'm wondering just how big a percentage of 3rd native OS4 programs don't use the OS libs and also how this incompatible FPU would affect 68k programs that don't use them.

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

[wawrzon]

Do you use the OS Maths libraries in your own stuff or internal routines?  I'm wondering just how big a percentage of 3rd native OS4 programs don't use the OS libs and also how this incompatible FPU would affect 68k programs that don't use them.

im not sure about boadblues, but given that almost all software today is more or less quick and dirty ports and that on os4 so objects support must have been added, to avoid the neccessity to build amiga dynamic libraries, which is probably a task hardly anyone is capable and patient to do anymore. id say chances are that almost everything is linked statically this days. which means the code that demands fpu needs to be recompiled for this board.

[nicholas]

im not sure about boadblues, but given that almost all software today is more or less quick and dirty ports and that on os4 so objects support must have been added, to avoid the neccessity to build amiga dynamic libraries, which is probably a task hardly anyone is capable and patient to do anymore. id say chances are that almost everything is linked statically this days. which means the code that demands fpu needs to be recompiled for this board.

 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.

[danwood]

for the 4.x market not, at least not in big batches. Acube is selling embedded PPC devices so for them it might make sense even when AmigaOS software not runs acceptable.

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?

[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

[broadblues]

Do you use the OS Maths libraries in your own stuff or internal routines?  I'm wondering just how big a percentage of 3rd native OS4 programs don't use the OS libs and also how this incompatible FPU would affect 68k programs that don't use them.

There are no OS maths libraries in the sense you mean for PPC code only for backward compatabilty with 68k.

On the other hand pretty much all higher level maths functions are handled via newlib.library  which is a shared library.

AS to 68k programs that don't use the Math#?.libraies well they are running on and emulated CPU  so probably irrelavent.

[Hans_]

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.

NOTE: When doing any benchmarks to test this, you need to make sure that you're using software compiled with hardware FPU enabled, otherwise you're testing GCC's software FPU emulation.

Hans

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