Hi,
I have to compile a package which uses the following to convert a double to int:
int main(void)
{
int i;
double num = 5.0;
__asm { __asm fld num __asm fistp i}
return 0;
}
This should be MS compatible.
In PellesC both is allowed, eiter an __asm in front of a inline block or __asm in front of each assembly instruction, but both simultaneously is not working.
Is this a known difference to MS or should this treated as a bug and corrected?
czerny
Why would you use the __asm prefix on a single instruction when you are already in an __asm {} block? ???
Sorry, that just doesn't make any sense to me... :-\
Ralf
This code is not mine. It is used in lua 5.2. Don't know if others write it the same way or not.
czerny
Hi czerny,
Bitbeisser is right. You should avoid multiple __asm prefixes. A single __asm {} block is much easy to type and read :
#define WIN32_LEAN_AND_MEAN
#include <windows.h>
char *szUpper(char *text)
{
__asm{
mov ecx,1
mov eax,text
sub eax,ecx
@repeat:
add eax,ecx
cmp BYTE PTR [eax],0
je @end
cmp BYTE PTR [eax],97
jb @repeat
cmp BYTE PTR [eax],122
ja @repeat
sub BYTE PTR [eax],32
jmp @repeat
@end:
}
return text;
}
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,LPSTR lpCmdLine, int nCmdShow)
{
char msg[]="inline assembly programming";
MessageBox(0,szUpper(msg),"Hello!",MB_OK);
return 0;
}
Since you are using the open source scripting language Lua, have you asked the Lua development team, why they coded it this way?
In the end you could always change the line to
#ifndef _POCC_
__asm { __asm fld num __asm fistp i}
#else
__asm {
fld num
fistp i
}
#endif
The reason could be that they wanted to avoid multiple line ASM code, so they used this way.
Quote from: czerny on April 24, 2012, 05:54:34 PM
This code is not mine. It is used in lua 5.2. Don't know if others write it the same way or not.
czerny
Well, it doesn't matter who's code this is, it just doesn't make any sense...
Can you post a snippet of the original Lua code that shows what exactly they are doing there, it might be possible that you got "lost in translation" (between different C compilers)...
Ralf
My question was NOT how I should code that. I know what I had done if it where my code.
My question was: Should Pelles C Mircrosoft compatible at this point (than should nested __asm be allowed) or not.
czerny
Here is some code from the lua 5.2 package:
#if defined(LUA_WIN) && defined(_MSC_VER) && defined(_M_IX86) /* { */
#define MS_ASMTRICK
#if defined(MS_ASMTRICK) /* { */
/* trick with Microsoft assembler for X86 */
#define lua_number2int(i,n) __asm {__asm fld n __asm fistp i}
#define lua_number2integer(i,n) lua_number2int(i, n)
#define lua_number2unsigned(i,n) \
{__int64 l; __asm {__asm fld n __asm fistp l} i = (unsigned int)l;}
czerny
Quote from: czerny on April 24, 2012, 10:35:37 PM
My question was NOT how I should code that. I know what I had done if it where my code.
My question was: Should Pelles C Mircrosoft compatible at this point (than should nested __asm be allowed) or not.
JMHO, absolutely not. The Lua folks seem to use some Microsoft specific quirk in that macro, in case of the right defines, so there should be another, probably more appropriate option to handle this in this case...
Ralf
Quote from: Bitbeisser on April 25, 2012, 12:48:51 AM
there should be another, probably more appropriate option to handle this in this case...
Sure there is one. But once more that is not the point here.
czerny
Just to remember: Pelles C defines _MSC_VER
Well, _MSC_VER is defined 1100 - "Visual C++ version 5.0". The version number is sometimes important, but probably not in this case.
I don't like inline assembly in general, and I wish Microsoft would have choosen asm("text") over the current syntax - which is a complete mess.
If it's really easy to fix I will do that, but otherwise it will have to be an incompatibility...
Hi czerny,
Do you have the option to move the assembly routine to a separate .asm module?
Quote from: Vortex on May 16, 2012, 10:37:51 PM
Do you have the option to move the assembly routine to a separate .asm module?
Sure, that would be possible. But it is simpler to adjust it to Pelles Syntax.
I do not have any real problem with this. It was an incompatibility to MS compiler that i noticed and Pelle should decide if he would like to correct it or if he wants to be incompatible here. What in my opinion is a little problem is the _MSC_VER definition. Mybe it is enough to mention this and maybe other incompatibilities in the help file.
If possible one could select to set it or not, would be an enhancement currently.
Moving assembly code to a separate .asm module avoids conflicts with the C compiler's optimization engine.
The compiler actually tried to handle this case, but I suspect it got broken in 2007 (the only logged change in this function after the support for nested __asm was added).
At leasted nested __asm statements appears to be rather "unpopular"...