@kas1e

Quote:

But probably they will find some solutions, like add something to kernel, which will software emulate missing stuff, or skip them

That Cow demo shows current software works on Tabor, albeit with speed penalty (expected from 3D application). Really good news!

However far more important question is severity of such penalty with FPU+3D demanding games.

@Tompelli
Quote:

Software which would be better being recompiled are mostly game ports from Linux and people like Huno are still around and active in the community to make multiple binaries.

:) that very naive :) I mean, no one will make "multiply binaries" (ok, maybe one or two, who will have that Tabor thing). See how much multiply binaries we have for altivec (which is doing things _better_, and it we didn't support it all the time, why anyone will support some slow, different cpu even if he dind't have it by hands ? For what reassons ?). Also not only Huno doing his ports, there is a loooot of different kind of stuff on os4depot, which is in binary form and _never_ will be recompiled as those who do it die, or left. But to be seen, what ones will just works, and what ones will not.

I just do not know why that problem need it at all. I can understand if it was 10GHZ cpu, with all super ultrafast stuff, and "mostly" ppc , but "just" fpu problems. Ok, that can be reasonable to live with problems. But why need to spend developer's time, on making different binaries for some underpowered HW ? Sorry, i fail to see any logic and motivation here. Maybe only me.

Quote:

Another idea is that we need a middle code solution, where the code is compiled to machine code at runtime (like in Java and Dot Net). That way the code is always optimized for the CPU make and model which ever you have in your hardware. (I'm wondering if it would be possible to license that virtual CPU stuff of Amiga Anywhere still

Did you really think anyone will implement that hardcore stuff like "code solution with runtime like java" ?:) No one will do so. There is no time and resources. And even as idea, it will make everything worse and slower (same as Java and DotNet in end).

But all that to be seen how it will be. Maybe everything will be not that bad in end. Just underpowered HW :))

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@pavlor

It'll depend. As Trevor said, this was the X5000 ISO running on Tabor.
Or the FPU will be a problem, or the SPE will be able to function as FPU, in which case there isn't.

I suppose that they will do something similar to what existed for 68040 and 68060 CPUs even 68881 and 68882.
Kamelito

@kamelit0

It's cute that people are still trying to push this false equivalence. The 040 and 060 FPU was a fast subset of 68881. The SPESFP is completely different from the PowerPC FPU.

_________________
This is just like television, only you can see much further.

@kas1e

A-EON are somewhat duty bound to make special builds of their own software where required, otherwise they'd be somewhat shooting themselves in the foot.

@BSzili

IIRC when a software used an FPU instruction that was not implemented in hardware an exception was raised and that particular instruction was simulated with those libraries. I suppose that the instruction not available in the Tabor FPU could be simulated the same way. I suppose that it will not be without any penalties thought. It was commun back then to have an FPU version and an FPU less of programs needing such instructions (ex 3D packages)
FAT binaries like it was done for the Next computer would be nice too.
Kamelito

@all

Please dont extrapolate too much about cow3d/tabor

1) after all it is not a real application nor even a real game
2) it dont use much cpu or fpu as it is nova/gpu that do the job
3) so if cow is slow on tabor it may have other reasons (that I dont knows) but that also may change

Alain Thellier

@TRIPOS

My sam 460 was gave me 61 fps on quake ... 60 was on my pegasos 2 G4 1133 ghz. 47 on my AmigaOne Xe G4 933

how you can say that the sam is the slowest ...

Last edited by tlosm on 23-Jan-2017 at 07:55 PM.

_________________
I love Amiga and new hope by AmigaNG
A 500 + ; CDTV; CD32;
PowerMac G5 Quad 8GB,SSD,SSHD,7800gtx,Radeon R5 230 2GB;
MacBook Pro Retina I7 2.3ghz;
#nomorea-eoninmyhome

It might happen that situation with the SPE compiled software will go in opposite direction. Maybe all new software will get SPE version first because of more sold A1222 units than X5000. A1222 is cheaper and probably will have bigger user base than other Amiga One models that are either not available any more or more expensive.

So IMHO if A1222 sells very well than we dont have to worry about if there will be SPE version of any new software. Many A1222 users will automaticay generate demand for SPE version and maybe otbers will have to wait for a "normal" one

-Dooz

@dooz

Even if Tabor sells all 1000 units withing a few months then it will still be outnumbered by Eyetech AmigaONEs, Sam440, Sam460, X1000, X5000, CS/BPPC and emulation.

@kamelit0

Again, you are peddling the same misinformation. SPESFP has a completely different instruction set from the PowerPC FPU, with different side effects to make things worse.

_________________
This is just like television, only you can see much further.

@BSzili

So I've been looking the SPE situation up on multiple manuals and manufacturers of embedded software and this is what I found.

The SPE unit uses it's own set of instructions, so for an application to make full use of it, it'll have to be compiled for the SPE instructions.

However, this does not mean applications compiled for an FPU will have to run these instructions all in software emulation.

The SPE has a set of General Purpose Registers which can execute Floating Point operands. This doesn't cover all FP instructions, but it means the SPE unit can be used to speed up FPU instructions over software emulated ones. QNX even has an fpassist mode for the SPE that traps FP instructions that aren't covered by the SPE in software.

In short, the SPE will be slower then a real FPU, but it can be used in parts as an FPU and it'll definitely be faster then software emulated FP instructions.

@WolfpackN64

It's not that simple, the SPE FPU instructions effect the integer registers in an incompatible way. It's not like the Tabor was announced yesterday, we've went through this a thousand times.

_________________
This is just like television, only you can see much further.

@BSzili

Yet multiple embedded systems use the General Registers of the SPE in a way which is at least partially compatible with some standard FP instructions.

@WolfpackN64

Quote:

Yet multiple embedded systems use the General Registers of the SPE in a way which is at least partially compatible with some standard FP instructions.

Example?

As far as we know Linux uses softfloats for PowerPC32 port.

@BSzili

I won't judge anyone until I saw real results on the Tabor regarding FPU performance until then I'll wait & see.
Kamelito

@pavlor

Linux uses the softfloats and as far as I know, there hasn't been use of the interbetween method yet. But QNX uses an fpassist mode which uses the General Purpose Registers of the SPE.

These GPR's can be used for IEEE floating point operations (but not all floiting point instructions are covered by them).

From NXP themselves: "These APUs provide IEEE-compatible floating-point
operations to power- and space-sensitive embedded
applications. Rather than implementing the FPRs de
fined by the PowerPC architecture, these embedded
floating-point instructions share the GPRs, extendi
ng them to 64-bits in the case of the vector
single-precision and scalar double-precision APUs. use the double-word load and store instructions defined by the SPE APU."

Quote:

tlosm wrote: My sam 460 was gave me 61 fps on quake ... 60 was on my pegasos 2 G4 1133 ghz. 47 on my AmigaOne Xe G4 933 how you can say that the sam is the slowest ...

What resolution?

_________________

double post

Last edited by Seiya on 24-Jan-2017 at 05:10 PM.

_________________