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

[psxphill]

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.

That is assuming that running incompatible FPU opcodes will even trap (I don't have any idea whether it will or not).

Otherwise you're looking at recompiling when loading anyway, which if you're doing that you really might as well just switch to x64.

[psxphill]

is this a smartphone perhaps?

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

It's hot, slow and power hungry, so hopefully not.

You can't install 64 bit windows on it because of a crippled UEFI. They make the excuse that with 2gb you don't need 64 bit, but there are other benefits to running x64 code. They destroy their own argument by selling a 64 bit Linux version with only 1gb of ram.

I'm not sure what point you're trying to make, but it's not the type of cpu you even want to compare against. If it beats you then you're in real trouble and there is no kudos in beating it.

http://gizmodo.com/intel-compute-stick-review-don-t-buy-it-1699377058

[psxphill]

My programs was not using floats much. I just used floats for convenience.

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

i would expect linux to decode and play video content on the gpu, the machine merely shoving video data through the bus.

I wouldn't expect that on any operating system, especially Linux, even if your gpu supports H264 acceleration. Although you can help the planets align https://github.com/erkserkserks/h264ify (but I still wouldn't expect it).

[psxphill]

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.

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.

[psxphill]

Weird analogy.
"That doesn't mean that using a float is in any way a good idea though."

Seriously?

Yes. For example a float can't accurately store the number "0.4"

Anything that deals with money should never use floating point, anything where the results have to be the same on different platforms shouldn't use floating point (or use http://www.jhauser.us/arithmetic/SoftFloat.html).

There are some circumstances where floats are ok to use, but most people who try to use floats have no idea when it's ok to use them and when it isn't.

http://stackoverflow.com/questions/16595668/any-risk-of-using-float-variables-as-loop-counters-and-their-fractional-incremen

In multiple projects I've had to remove the use of floats because people thought they should use them because "the C library supports them so they must be a good idea".

However there are situations where software does require the use of an FPU (both 68k & PPC) so new hardware should support them.

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

[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

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

[psxphill]

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

Yes, you can buy a p1021 reference design board cheaper.

http://uk.farnell.com/freescale-semiconductor/p1021rdb-pc/reference-design-board-qoriq-p1021/dp/2315643

But the cpu is only one part of the price, so it doesn't make a huge difference.

Reference boards aren't really designed for end users and are low volume. They are only made so you can prototype products where you'll eventually buy a cpu and stick it on your own board. At that point the cost of the cpu is more relevant.

However if you can't compete with the freescale's reference boards on volume then you won't be able to compete with them on price, so you might as well buy freescale reference boards.

[psxphill]

@psxphill

really?! could you point me to where the tabor price has been released? perhaps you should actually find out the price before making accusations about how 'astonishing' it is how they can 'justify' it. it might save you some embarassment later.

-- eliyahu

Ok, so I've assumed that the price is going to be in the range here.

http://www.amiga-news.de/en/news/AN-2015-10-00027-EN.html

If instead they sell it for around 400 euros instead then yes I would have to apologise.

[psxphill]

@psxphill

the price quoted there is incorrect. it will be lower.

Don't you think that it's pretty stupid that they haven't made an official announcement about it then? Not that this choice of CPU is particularly suitable for AmigaOS even if it is cheaper. A board with a P204x that has double the clock speed and double the number of cores wouldn't be four times the price, it shouldn't even double the price.

For fun. I am not a slave.

You get fun from releasing software that people would like to run but can't because they don't have an FPU, even though your software doesn't really require a FPU? That is twisted.

[psxphill]

again, perhaps you should wait a little and see what the finished product is before passing judgement?

I'll take it for what it is then, a vague vapourware announcement.

As hyperion have admitted that AmigaOS isn't actually working on it yet, then no I don't think A-EON have any idea whether it's suitable. Trevor is an evangelist, not an engineer.

[psxphill]

i see. you know better. i guess that clears that up, then. :lol:

Anybody without a vested interest knows better. I would let Trevor off because it will have been over sold to him.

They don't know anything about how well it will work, because it's not actually working. Making everything they say a guess, their guess is financially influenced and therefore should be taken with a huge pinch of salt.

Hyperion have never been very good with guesses anyway.

Regardless, this is a thread about Tabor, not about what you think Tabor should have been. If you want to discuss other Freescale parts, start a thread about it, or better yet, don't

What I said is relevant to Tabor as it is showing how much of a bad idea it is, but enjoy the car crash.... *grabs popcorn*

[psxphill]

In that speech he said that they've made a big number of boards and that they would be low in price. Trevor then said that with an increase of new users, they would see more software sales. These sales would cover the losses on the boards.

I wonder how much software they need people to buy before they don't lose money. I admire him for taking the risk, but I'm glad it's not my money.

"Last year we sold 1000 boards and made a 5000€ loss. This year we've exceeded expectations and sold 10000 boards which has pushed our losses to 50000€ euros. Next year we hope to sell 100000 boards".

[psxphill]

Haha.
I did not just mean old games new ones as well.
And ofcourse browsing.

It sounds like you want AROS running on a ps3.