@cdimauro


read your posts from Tabor running Debian 8.2 powerpc32.

The same Linux kernel runs the 3 verisons of Linux installed on my Tabor .
Ubuntu 12.04, Debian 8.2 powerpc32 and Debian 8.0 powerpcSPE.
The build option for the linux kernel is emulate all floating point instructions.

Would this indicate that there are traps even under the Debian 8.0 powerpcSPE as there
is only provision for emulated floating point in the Linux kernel ?

_________________
Sam460ex : Radeon Rx550 Single slot Video Card : SIL3112 SATA card

@Spectre660: according to the Debian PowerPCSPEPort's page, this distro doesn't trap & emulate the FPU instructions (only the string ones, I guess), like the other two do, but SPE instructions are used for the compiled binaries (kernel and applications).

It can also run regular PowerPC applications, but in this case the trap mechanism is used.

Try to run exactly the same application (LAME, Blender, etc.: whatever stresses the FPU) with the PowerPC and then with the PowerPCSPE version, and look at the results.

@Spectre660

Quote:

Anyway A-Eon now own DvPlayer and Tunenet. Two programs that would be affected by the FPU emulation speed. So special SPE floating point versions of these should not be a problem.

There will be difficulties because the system ABI has no concept of SPEFP. But that is just another item on the todo list.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

Quote:

eder wrote: @OlafS25 How can something be slow, yet not tested

Hehe, I love that. Simple and efficient to summarize a big part of this thread.

Yes, trap and emulate is slow compared to execution of an instruction on a core with the support of standard FPU.

But Tabor is more than an that. And SPE is also a vector unit, after all, even if not Altivec.

@corto

Quote:

corto wrote: Quote: eder wrote: @OlafS25 How can something be slow, yet not tested Hehe, I love that. Simple and efficient to summarize a big part of this thread. Yes, trap and emulate is slow compared to execution of an instruction on a core with the support of standard FPU.

That's something which was already stated here from the beginning, and contrary to the false statement of some (non-technical, I suppose) guy from Hyperion.
Quote:

But Tabor is more than an that.

Like what? Do you know some feature that can contribute on this context?
Quote:

And SPE is also a vector unit, after all, even if not Altivec.

Altivec:
- can elaborate 4 single precision data per instruction (SPE has 2);
- load/store unit 128-bit of data (SPE only 64-bit)
- has 32 dedicated registers to better exploit parallelism / unrolling code (SPE shares the general purpose registers);
- has support for different datatypes;
- supports data streams to better handle data flows;
- has 4 operands instructions.
Regarding the last 3 sentences, I've to check if SPE offers some support. I had not time to see the details of the SPE unit: I'll do it this week-end, if possible.

BTW, you can use the SPE "vector unit" only on ad-hoc compiled binaries, and if the compiler is able to autovectorize the code.

Otherwise coders should rewrite part of the code to directly support it, exactly like what happens with Altivec. I don't know how much it can be interesting to provide so much effort, considered also the small niche.

In both cases (only compilation needed, and coders support to the SPE), there's the ABI question which itix already raised, and should be solved. I gave a solution before, but it slows down the execution.

Last but not least:
- the existing code traps anyway, even if just using the FPU only to quickly move data (like someone else has already reported);
- "string" instructions are also unsupported and trap every time;
- Petunia needs sensible changes to introduce SPE support;
- Petunia needs bigger changes to support SPE's vector unit, because you need a much more sophisticated code analizer, and the corresponding code emitter should take care of initialization and finalization of loop unrolling (and the loop unrolling itself, of course);
- the kernel should be changed to support the 64-bit wide registers file;
- o.s. changes to support the SPE unit slow down EVERY application (yes, even the ones which don't make use at all of FPU or string instructions), due to the bigger context-switch time.

@cdimauro

Quote:

In both cases (only compilation needed, and coders support to the SPE), there's the ABI question which itix already raised, and should be solved. I gave a solution before, but it slows down the execution.

There is one more complex case...

Consider you have following library code compiled for the FPU:

double foobar(double a, double b) { return a + b; }

Next you are compiling your binary for SPEFP and want to use this foobar() function from the library (shared, static, or dynamic):

void main()
{
// Compiled using SPE floating points
double x = 1.0, y = 2.0;

// Call our FPU floating point function with SPEFP params
double rc = foobar(x, y);

// Ooops?
}

Do you see the problem?

Quote:

- "string" instructions are also unsupported and trap every time;

That is not big deal. In GCC it is not automatically enabled and to use those instructions you must pass additional flag to the compiler. It is just matter grep'ng makefiles and not using string instructions anymore.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@cdimauro

also posted on another thread already...

that is from annual report of Applied Micro Circuits. It explains why new hardware from a different supplier developed. And it shows the decline of PPC in general.


"As part of our current business, we offer a line of embedded computing products based on Power Architecture, sometimes referred to as PowerPC
products. Our HeliX family of embedded products is based on the ARM Instruction Set Architecture (“ISA”), and we expect that our future embedded
processor products will also be based on the ARM ISA. Our embedded processor products are currently deployed in applications such as control- and dataplane
management, wireless access points, residential gateways, wireless base stations, storage controllers, network attached storage, network switches and
routing products, and multi-function printers.

We do not own or operate foundries for the production of silicon wafers from which our products are made. We use external foundries, primarily Taiwan
Semiconductor Manufacturing Corporation (“TSMC”) and to a lesser extent, IBM, for our silicon wafer needs. In late 2014, IBM announced that it had
agreed to sell its foundry business to GlobalFoundries, which we believe has contributed to the continuing decline in demand for our PowerPC products,
which are based on IBM’s Power Architecture. Subcontracting our manufacturing requirements eliminates the high fixed cost of owning and operating a
semiconductor wafer fabrication facility and enables us to

For our Computing
business, as well, the migration of the networking industry away from products utilizing the PowerPC architecture and towards products utilizing other
architectures such as ARM, has presented challenges. In line with such migration, we are no longer introducing new PowerPC product designs and are
reducing our resources equipped to support our older PowerPC product lines. Moreover, as many of our older, PowerPC-based Computing products are
experiencing declining sales, we will increasingly depend on revenues from our new ARM-based products, such as the X-Gene product family and our HeliX
embedded products."

Source:
http://www.sec.gov/Archives/edgar/data/711065/000144530514002375/amcc331201410-k.htm

BTW some confusion... is Sam 460 now dropped or not?

Last edited by OlafS25 on 20-Oct-2015 at 10:00 AM.
Last edited by OlafS25 on 20-Oct-2015 at 09:59 AM.

@OlafS25

They confirmed that they will be making more.

_________________

@Everblue

where do you read that? They write that sales are declining and they are heading more and more to ARM

@OlafS25

On their Facebook page, I asked them publicly and they replied.

_________________

@Everblue

there is not necessary a opposition between what I wrote and that what you write. I write PowerPC is declining and they are heading to ARM and that PowerPC has no future. The same is true for Freescale who are bought by another ARM based company. So finally both companies will drop PowerPC at some point propably when producing current designs is no longer profitable and they will not invest in new processor generations and concentrate where they earn most money in future and that is ARM.

@OlafS25

Quote:

OlafS25 wrote: @Everblue there is not necessary a opposition between what I wrote and that what you write. I write PowerPC is declining and they are heading to ARM and that PowerPC has no future. The same is true for Freescale who are bought by another ARM based company. So finally both companies will drop PowerPC at some point propably when producing current designs is no longer profitable and they will not invest in new processor generations and concentrate where they earn most money in future and that is ARM.

But that is in the future, and then we are all dead so enjoy what you have

@eder

I am still not old enough for that I think they will drop it long before I am dead

@OlafS25

https://www.power.org/newsletter/power-org-september-2015-newsletter/

_________________
retired

From what I understand (which isn't saying much) x86/AMD64 is fast but power hungry, ARM is a lot slower but very power efficient and PPC is suppose to be very fast but reasonably power efficient. Problem is that all processors are getting faster and faster, even ARM, making PPC pretty much obsolete as it simply can't keep up.

The only place left is servers, where even a little power saving means a lot of cash not spent. Which is the route IBM is going with Power8 and beyond, and they are not an alternative for desktop computing because of it's high price (and very much overkill for Amiga use, it's top of the line processor has some 96 cores).

Basically, PPC is screwed and we can maybe even consider ourself lucky that we can buy any types of processors today. Which I guess is the reason why they chose this processor in the first place: no better options for it's design.

_________________
Amiga Forum - Sweden's best Amiga Magazine

My MorphOS Blog

"Free speech includes other peoples right to offend you."

@Yasu

At the time. This design stems from the days when we had very little to choose from in the lower segments. The list of available CPUs from Freescale looks a WHOLE lot better now.

_________________
This weeks pet peeve:
Using "voltage" instead of "potential", which leads to inventing new words like "amperage" instead of "current" (I, measured in A) or possible "charge" (amperehours, Ah or Coulomb, C). Sometimes I don't even know what people mean.

@Yasu

As long as FPGA exists there wil be no problem putting that Power 8 core in an FPGA eg : Virtex-5 FPGA Embedded Processor Block with PowerPC 440 Processor

Price is still a huge problem and it's not likely to improve.

_________________
Amiga Forum - Sweden's best Amiga Magazine

My MorphOS Blog

"Free speech includes other peoples right to offend you."

@Yasu

Quote:

Yasu wrote: Price is still a huge problem and it's not likely to improve.

I dont think the price is going to be an issue, things are moving fast in the "real " world. Meanwhile we have lots of different choises for the next foreseeable timeframe.

@eder

Quote:

eder wrote: @Yasu Quote: Yasu wrote: Price is still a huge problem and it's not likely to improve. I dont think the price is going to be an issue, things are moving fast in the "real " world. Meanwhile we have lots of different choises for the next foreseeable timeframe.

Are we talking about this from an mainstream users point of view, or a hobbyists point of view here?

_________________
Amiga Forum - Sweden's best Amiga Magazine

My MorphOS Blog

"Free speech includes other peoples right to offend you."