83 replies to this topic

[Nick]

tbp said:

Err, nope, the whole stack is promoted to 16-byte alignment, on doze/linux with msvc/gcc/icc, on proper condition.

Compiling the following in Visual C++ 2005 in Debug mode I get "warning C4731: 'main' : frame pointer register 'ebx' modified by inline assembly code".

void main()

{

	__declspec(align(16)) float x[4] = {0, 0, 0, 0};


	__asm

	{

		mov ebx, 0

		movaps xmm0, x

	}

}

Ironically it doesn't really use ebx and just aligns esp like you said. So it appears to be a legacy limitation. I'm positive this caused trouble a couple years ago. Good to know it has been resolved! :yes:

[SigKILL]

Nick said:

Compiling the following in Visual C++ 2005 in Debug mode I get "warning C4731: 'main' : frame pointer register 'ebx' modified by inline assembly code".

void main()

{

	__declspec(align(16)) float x[4] = {0, 0, 0, 0};


	__asm

	{

		mov ebx, 0

		movaps xmm0, x

	}

}

Ironically it doesn't really use ebx and just aligns esp like you said. So it appears to be a legacy limitation. I'm positive this caused trouble a couple years ago. Good to know it has been resolved! :yes:

Just curious, but could you explain this? I clearly see a "mov ebx,0", but you claim it doesn't use ebx.

[monjardin]

I think he is refering to the compiled C code that wraps the assembly block.

[tbp]

No. That 'x' is allocated on the stack, and it's the compiler that resolves that C/C++ symbol from the inline asm part, but through esp, not ebx... because the whole stack is properly aligned as said earlier.

BTW Nick, that's

int main()

;)

[Nick]

SigKILL said:

Just curious, but could you explain this? I clearly see a "mov ebx,0", but you claim it doesn't use ebx.

It doesn't use ebx as an aligned stack pointer. On older Visual C++ compilers the "movaps xmm0, x" translates to "movaps xmm0, [ebx+<offset of 'x' on aligned stack>]". So that would cause trouble if I used ebx myself (like assigning zero in my example). Luckily Visual Studio 2005 uses the standard esp and ebp registers for stack access, so ebx is available for us. But apparently the warning still exists.

[monjardin]

Well, that's what I meant. I'm a bit out of my element. :wacko: I haven't done much x86 assembly in years.
I did get a 3-4x speed-up in some code I rewrote in assembly for a microcontroller earlier this week. :clapping:

[Nick]

tbp said:

BTW Nick, that's

int main()

;)

I like consistency. :whistle:

[karligula]

One good and undeniable reason to learn assembler is to write compilers... somebody's got to do it, they don't write themselves!

[monjardin]

Oddly enough, I think most C compilers are written in C. It's not unusual for a compiler to be written in the language that it compiles.

[tbp]

monjardin said:

Oddly enough, I think most C compilers are written in C. It's not unusual for a compiler to be written in the language that it compiles.

Yeah so it can boostrap/compile itself. Now much are written in C because historicaly there was no C++ when they've seen the light.
Unlike http://llvm.org/

[.oisyn]

monjardin said:

Oddly enough, I think most C compilers are written in C. It's not unusual for a compiler to be written in the language that it compiles.

And what kind of output do you think a C compiler has?

[SigKILL]

Nick said:

It doesn't use ebx as an aligned stack pointer. On older Visual C++ compilers the "movaps xmm0, x" translates to "movaps xmm0, [ebx+<offset of 'x' on aligned stack>]". So that would cause trouble if I used ebx myself (like assigning zero in my example). Luckily Visual Studio 2005 uses the standard esp and ebp registers for stack access, so ebx is available for us. But apparently the warning still exists.

Well, google didn't give me an answer so please correct me if I'm wrong. But, if I understand you correct vc will use an aligned stack (in addition to the 'regular' stack) when using non-standard alignment (using ebx as the stack pointer). But, why doesn't the compiler use the 'regular' stack and simply skip bytes to get everything properly aligned? It also seems likely that having alot of local variables with different alignments would make this quite messy... I have a feeling there is something I've misunderstood in this matter...

[Jare]

SigKILL said:

why doesn't the compiler use the 'regular' stack and simply skip bytes to get everything properly aligned?

I suppose alignment happens at runtime, and therefore the amount of padding bytes in the stack varies, even if the total allocation doesn't - it would just be the largest amount of padding needed. The compiler would emit a code sequence that assigns ebx to the correctly aligned address, and index from there.

[Reedbeta]

Compilers (well, at least gcc) usually tend to align new stack frames on 16-byte or 32-byte boundaries anyway, right? In looking at the assembly from gcc you frequently see "sub $8, %esp" or something similiar immediately before parameters are pushed and a call made. I always assumed that extra stack space was padding for alignment reasons...

[tbp]

For gcc it's a bit different as -mpreferred-stack-boundary has been there for ages.
http://gcc.gnu.org/o...cc_2.html#SEC31

Works better with a saner ABI :whistle:

[Axel]

Nick said:

I like consistency. :whistle:

It is consistent. The spec says main has an implicit zero return value if you don't return anything yourself.

[Nick]

Axel said:

It is consistent. The spec says main has an implicit zero return value if you don't return anything yourself.

That's exactly what I meant. The C++ specifications say the return type is int, yet it's not required to return anything (not consistent). So specifying void is strictly speaking out of spec although lots of compilers support it. But I like consistency more than obliging some stupid standard. ;)

[Reedbeta]

Why not just declare int main() and throw in the return 0 at the end? Then you'd have consistency, and keep the standard-yappers quiet too

[Axel]

Especially because every C-program returns a value to the operating system, so "void" makes no sense either.

[Nick]

Reedbeta said:

Why not just declare int main() and throw in the return 0 at the end? Then you'd have consistency, and keep the standard-yappers quiet too ;)

Because that would make every mini-example two lines longer for no practical reason.