A problem with 'prefetcht0' instruction ( AT&T inline-assembler syntax )

[SergeyKostrov]

I have a problem with 'prefetcht0' instruction. Here are two examples how I tried todeclare itusing

AT&T inline-assembler syntax for a GCC-like C/C++ compiler:

...
void *pvAddress = ( void * )pData;
...

// 1st declaration
...
__asm__
(
"prefetcht0 pvAddress;"
);
//Compilation Error: Undefined reference to `pvAddress'
...

and

// 2nd declaration
...
__asm__
(
"prefetcht0 %0;" : : "r" ( pvAddress )
);
// Compilation Error: Suffix or operands invalid for `prefetcht0'
...

I'm porting to Linux some codes and I wonder how it has to be declared. Thank you for yourtime!

[TimP]

The _mm_prefetch macros mentioned in the other thread are preferable to asm.

[SergeyKostrov]

Of course,_mm_prefetch can be used but, unfortunately, I can't use it due to portability requirements.

I understood thatintrinsic functions arenot part of GCC-like C/C++ compilersbecause aGCC C/C++ compilerrequires ANSI C headers.

[SergeyKostrov]

1. Finally resolved and this is how it has to be declared for a GCC-like C/C++ compiler:

...
__asm__
(
"prefetcht0 %0;" : : "m" ( pvAddress )
);
...

and it compiles to an instruction in a *.s assembler file:

...
prefetcht0 DWORD PTR [ebp+8];
...

2. There is also another way to prefetch data with GCC-like compilers:

...
__builtin_prefetch( pvAddress, 0, CACHELINE_HINT_T0 );
...

3. A command line option '-masm=intel' broke functionality in some algorithms ( long time ago tested and
stabilized ) and next week I'll try to investigate why it happened. As soon as the '-masm=intel' is removed problems are gone.

Best regards,
Sergey

[SergeyKostrov]

>>3. A command line option '-masm=intel' broke functionality in some algorithms ( long time ago
>>tested and stabilized )...

Completed an investigation related to '-masm=Intel' command line option of a GCC-like compiler
and I confirm there is an issue with how it applies a cast from 'double' to 'uint' in Debug
configuration.

Here is a piece of codes that became broken:
...
RTdouble dPartI = 0.0L;
RTdouble dPartF = CrtModf( dX, &dPartI );

// In Debug there is a problem with 'double'-to-'uint' cast
if( ( RTuint )dPartI != m_uiRows || ( RTuint )dPartI != m_uiCols )
break;
...
// A corrected version without cast works properly
if( dPartI != m_uiRows || dPartI != m_uiCols )
break;
...

All the rest C/C++ compilers that are used in the development process on my project don't have any problems with 'double'-to-'uint' cast.

Note: Variables dX, dPartI, dPartF, m_uiRows and m_uiCols are always positive.