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

[Iggy]

Yeah, cos what would Hyperion know about that

Not that much actually, since they subbed the OS out to the Friedens.

And I am willing to give the brothers more credit than many, as they have gotten OS4 this far.

But we now know they are expecting to emulate unsupported fpu instructions.
Calling those illegal ops traps 'transparent' isn't exactly accurate nor is the claim that the impact will not exist.
And the OS will have to implement the emulation code, BUT its not nearly as bad as I may have made out originally.

However...you guys can consider whether or not you want to buy it.
If I buy anything its still going to be an X5000 with its e5500 cored processors.

[Everblue]

Well X5000 is way too funky pricewise for me. So that basically means either a Sam460CR (assuming these are still in production) or wait for a Tabor board hoping that considering the price "it won't be THAT bad".

Alternatively, MorphOS on an x86 board, but thats probably years away.

[eliyahu]

@thread

there's tons of great discussion on MOS and AROS PPC alternatives, but it's getting off-topic. so i've moved that discussion to a new thread. please continue the MOS/AROS discussion there and keep this thread focused on tabor itself. thanks!


-- eliyahu

[psxphill]

Your last statement seems to run counter to the "That doesn't mean that using a float is in any way a good idea though" argument.

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

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.

[itix]

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.

Why not? If I have used floats to save some typing and it works then why on earth I should care if it won't work on some non-FPU machine? It is same reason why I don't support palette based displays. I could do that but I have other tasks to do.

Anyway, just checked what my floats do. It is for real time effects in audio playback (it is a CD player,, so it is useless today).

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

[psxphill]

Why not? If I have used floats to save some typing and it works then why on earth I should care if it won't work on some non-FPU machine?

Why would you bother writing software if you don't care if it will work or not?

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?

I want to keep them for backward compatibility. It's not contradictory at all. 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.

Was a standard PPC FPU a bad idea since the P1022 CPU dropped the standard FPU?

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

Cross platform floating point results can vary but this is usually not a problem unless precision or accuracy are lost.

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

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

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.

I said should, not must. Although releasing something that needs an FPU purely for loading a preference would still deserve criticism.

Similar comment from Jens Schöenfelt

http://eab.abime.net/showpost.php?p=1045850&postcount=7

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

There are some details here: https://wiki.debian.org/PowerPCSPEPort
and http://community.qnx.com/sf/wiki/do/viewPdf/projects.core_os/wiki/E500_SPE_support

It appears you have to emulate the fpu (at least in part) using integer instructions (the SPE isn't IEEE compatible).
Every FPU instruction is going to need to hit memory a lot because the SPE uses the integer registers and they are obviously already in use.

Either Jens or the guy he talked to was being economical with the truth, or there was some form of information lost in translation. None of the FPU instructions can be run natively, they all trap to one of 2 exceptions. So yeah, you have to catch a couple of exceptions and emulate the whole chip. Not like the 68060 at all, where the most common instructions (according to motorola) get executed natively.

The e200mc (used in the P204x and later) is just missing two instructions from the PowerPC FPU.

There have been enough Amiga announcements made in good faith because the developers believed something was achievable and then they didn't achieve it. They can probably make it do something, I'll believe it is something worth doing when you can buy it and try it.

We could all just buy http://www.digikey.com/product-detail/en/P2041RDB-PC/P2041RDB-PC-ND/4234547 http://www.farnell.com/datasheets/1854648.pdf which is likely going to be cheaper than the slower A1222

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

[OlafS3]

one news... despite different rumours AmigaOS is still not running on Tabor

FPU emulation is slow and not tested. They have plans for a better one later.

[Iggy]

one news... despite different rumours AmigaOS is still not running on Tabor

FPU emulation is slow and not tested. They have plans for a better one later.

Well that wasn't completely unexpected, otherwise they could have shown it running at AmiWest.

It DOES take time to do the porting work.

We will have to wait and see how this compares to the SAM460.

But remember, even though this only has a 100MHz advantage, it could turn out that even with the disadvantage of having to trap and emulate fpu instructions that the Freescale cpu is still more powerful than the Applied Micro cpu used in the SAM.

Yes, I still maintain the e500v2 is not the best choice, but it may not be the worst either.

[Spectre660]

The P1022 core should be about 30% faster than the 460ex in single core integer performance . The Mplayer decode benchmarks single core results under Linux are Tabor (SPE) 214s . Sam460ex 469s .
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.

Well that wasn't completely unexpected, otherwise they could have shown it running at AmiWest.

It DOES take time to do the porting work.

We will have to wait and see how this compares to the SAM460.

But remember, even though this only has a 100MHz advantage, it could turn out that even with the disadvantage of having to trap and emulate fpu instructions that the Freescale cpu is still more powerful than the Applied Micro cpu used in the SAM.

Yes, I still maintain the e500v2 is not the best choice, but it may not be the worst either.

[Iggy]

The P1022 core should be about 30% faster than the 460ex in single core integer performance . The Mplayer decode benchmarks single core results under Linux are Tabor (SPE) 214s . Sam460ex 469s .
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.

Then Sir, I owe you an apology for being a rather obnoxious, aggressive  and somewhat self centered a-hole.

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.

Further, Applied Micro has essentially abandoned further PPC development in favor of ARM.

While Freescale is also moving in this direction, they are still planning a few new cpus.
And their existing product line is stronger.

[psxphill]

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.

I thought I spelt that out in my original post, you shouldn't need to infer anything.

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.

There is enough that MMU compatibility would be more than a nice to have, it would mean the difference between choosing a real 060 or an FPGA. Anything that creates fragmentation is bad.

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.

Again I think you misunderstood what I was saying. I was merely saying that just because printf() supports float and doesn't support fixed point, doesn't mean using floating point is a good idea. You should choose the type carefully, most programmers don't really have a clue what floating point even means & get caught out.

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

Multiple cores work great if you have a large amount of work to split out that has no reliance on data calculated by another core, so you don't need to synchronise the cores until the end. Trying to use the second core as an fpu will generally just add overhead with thread synchronisation and the first core will end up waiting for the second core to finish.

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

I find that unlikely, but until they actually get it working it's all speculation.

A mini-ITX with a P204x is available now for the bottom of the projected cost of the Tabor and it has four cores, a much faster clock speed and an FPU that will mostly just work. This Tabor board is a waste of time.

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

[Bennymee]

I thought I spelt that out in my original post, you shouldn't need to infer anything.



There is enough that MMU compatibility would be more than a nice to have, it would mean the difference between choosing a real 060 or an FPGA. Anything that creates fragmentation is bad.



Again I think you misunderstood what I was saying. I was merely saying that just because printf() supports float and doesn't support fixed point, doesn't mean using floating point is a good idea. You should choose the type carefully, most programmers don't really have a clue what floating point even means & get caught out.



Multiple cores work great if you have a large amount of work to split out that has no reliance on data calculated by another core, so you don't need to synchronise the cores until the end. Trying to use the second core as an fpu will generally just add overhead with thread synchronisation and the first core will end up waiting for the second core to finish.



I find that unlikely, but until they actually get it working it's all speculation.

A mini-ITX with a P204x is available now for the bottom of the projected cost of the Tabor and it has four cores, a much faster clock speed and an FPU that will mostly just work. This Tabor board is a waste of time.

Isn't the P204x much more expensive then the P1xxx dual core ?

[Spectre660]

@matthey

I already have a Tabor and I am enjoying it.