What About Some Decent Ports?

[ldesnogu]

Scalar means single element, non-vector. NEON handles it, not just vector, although it is single precision only (but games have little business using double precision in the first place). The Cortex-A8 CPU is capable of issuing some VFPv3 instructions to the NEON unit, so GCC doesn't even have to emit NEON instructions in order for those floating point operations to be pipelined.

For NEON specific instructions I could not find any scalar FP operation in the ARM ARM.
But I indeed found that some scalar FP VFPv3 instructions are dispatched to NEON FP unit. However you will notice this in Cortex-A8 TRM:

QUOTE
VFP instructions that execute in the NFP pipeline have results that are 32-bit single-precision writes to the upper or lower half of the 64-bit register value. A restriction that applies to VFP instructions executing in the NFP pipeline is that instruction results cannot be forwarded early to subsequent instructions.

So we are back to non pipelined instructions, at least for dependent instructions...

BTW does anyone know what silicon rev OMAP3430 uses? I hope it's r2p0, which is faster

 

[Exophase]

For NEON specific instructions I could not find any scalar FP operation in the ARM ARM.

Apparently not, I'm not sure how I determined this. I must have been thrown off by the vector x scalar operations.

So we are back to non pipelined instructions, at least for dependent instructions...

Don't you think saying that is a little extreme? In the VFP11 spec data forwarding only saved one latency cycle to begin with, look at this excerpt:

QUOTE

In Example 4.1, the second FADDS instruction depends on the result of the first FADDS instruction. The result of the first FADDS instruction is forwarded, reducing the stall from eight cycles to seven cycles.

Example 4.1. Data forwarded to dependent instruction

FADDS S1, S2, S3
FADDS S8, S9, S1


8 cycles to 7 cycles, hardly a huge improvement.

So I would like to think that GCC would already be trying to schedule out dependencies - there are 32 registers in the register file so it has a lot of opportunity to do so. Although true dependencies do exist they don't spoil all of the benefits of pipelining.

 

[ldesnogu]

Apparently not, I'm not sure how I determined this. I must have been thrown off by the vector x scalar operations.

Quite understandable, reading through the 2000 pages of the ARM ARM v7 + hundreds of pages of TRM can be confusing

So we are back to non pipelined instructions, at least for dependent instructions...

Don't you think saying that is a little extreme? In the VFP11 spec data forwarding only saved one latency cycle to begin with, look at this excerpt:

QUOTE

In Example 4.1, the second FADDS instruction depends on the result of the first FADDS instruction. The result of the first FADDS instruction is forwarded, reducing the stall from eight cycles to seven cycles.

Example 4.1. Data forwarded to dependent instruction

FADDS S1, S2, S3
FADDS S8, S9, S1

8 cycles to 7 cycles, hardly a huge improvement.
I am spoiled by more efficient FP units, I guess. I never saw the VFP11 was that bad!

So I would like to think that GCC would already be trying to schedule out dependencies - there are 32 registers in the register file so it has a lot of opportunity to do so. Although true dependencies do exist they don't spoil all of the benefits of pipelining.

Definitely. I just hope the Pandora will use the EABI which is much more efficient for FP param passing than the old ABI...

If Pandora dev's listen: please use CodeSourcery gcc

 

[ldesnogu]

BTW does anyone know what silicon rev OMAP3430 uses? I hope it's r2p0, which is faster

Cortex-A8 is r1p1. Ref OMAP35x SPRUFA0.

 

[TheLonelyGod]

we should secretly remake chrono trigger without square enix finding out. . .

 

[javaJake]

we should secretly remake chrono trigger without square enix finding out. . .

Well, that blows my cover. Thanks a lot.