Advertisement Jump to content
Sign in to follow this  
fir

handy inline assembly environment

This topic is 1874 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I would like to wrote and tast many codes mixing easily 

c and inline assembly and winapi

 

I do not require to much for the compiler just c, no ide

required, no good compiled code generation but it

should support modern assembly and get handy inline

assembly (easy to mix with c and supporting nice syntax

and modern sse)

 

How options do i have? I knov VS do not support inline assembly

I not used mingw too much so I am not sure how much its inline assembly is

comfortable.. maybe some other options or mingw is only option?

 

Share this post


Link to post
Share on other sites
Advertisement

Inline assembly is typically messy and doesn't look at all like ordinary assembly because you need to get the compiler to understand your assembly code so it can allocate registers properly and not screw up your own assembly. Do you really need inline assembly, would a separate assembly file with external declarations do the trick? You don't need to mess with the compiler, and you get all the instructions you want (as long as the compiler is configured to understand them).

 

It looks like this:

// main.c

void my_function(int arg1, char *arg2, void *arg3); // specify calling convention if needed

int main()
{
    my_function(...); // call your assembly function
}

// assembly.S

my_function:
    // freely write your assembly code here
    // (assuming arg1, arg2, arg3 are in the proper register
    // or stack location depending on the calling convention chosen)

Then you just compile assembly.S as an ordinary C file, and link it along with the rest of your source files, and the linker will link the "my_function" declaration with the assembly function.

 

If this is not good enough, then, sorry, I don't know (and ignore this post).

Share this post


Link to post
Share on other sites

Inline assembly is typically messy and doesn't look at all like ordinary assembly because you need to get the compiler to understand your assembly code so it can allocate registers properly and not screw up your own assembly. Do you really need inline assembly, would a separate assembly file with external declarations do the trick? You don't need to mess with the compiler, and you get all the instructions you want (as long as the compiler is configured to understand them).

 

It looks like this:





// main.c

void my_function(int arg1, char *arg2, void *arg3); // specify calling convention if needed

int main()
{
    my_function(...); // call your assembly function
}

// assembly.S

my_function:
    // freely write your assembly code here
    // (assuming arg1, arg2, arg3 are in the proper register
    // or stack location depending on the calling convention chosen)

Then you just compile assembly.S as an ordinary C file, and link it along with the rest of your source files, and the linker will link the "my_function" declaration with the assembly function.

 

If this is not good enough, then, sorry, I don't know (and ignore this post).

 

By now i am using standalone asemby exactly this way (using nasm) but the thing is i would like handy inline assembly instead (or too ).- I think this way i could wrote and use some assembly things faster and morecomfortable

Edited by fir

Share this post


Link to post
Share on other sites


How options do i have? I knov VS do not support inline assembly

 

How so ? As far as I know, VS supports inline assembly when the target architecture is x86. Under x64 you can't use inline assembly, however, intrinsic functions are still available.

 

Cheers!

Share this post


Link to post
Share on other sites

 


How options do i have? I knov VS do not support inline assembly

 

How so ? As far as I know, VS supports inline assembly when the target architecture is x86. Under x64 you can't use inline assembly, however, intrinsic functions are still available.

 

Cheers!

 

 

I need convenient environment for easy mixing c with inline assembly (supporting newest see and windows/winapi)

Share this post


Link to post
Share on other sites

By now i am using standalone asemby exactly this way (using nasm) but the thing is i would like handy inline assembly instead (or too ).- I think this way i could wrote and use some assembly things faster and morecomfortable

I need convenient environment for easy mixing c with inline assembly (supporting newest see and windows/winapi)


Inline assembly is practically guaranteed to give you the opposite results for both. It will likely be neither faster nor more comfortable to develop.


First, it prevents the optimizer from doing its work. An inline assembly block says "I know exactly what I am doing, do not optimize any of this." Also, it means the compiler is prevented from optimizing nearby code, such as placing variables in registers or making function-wide optimizations; it needs to ensure that your little block of code gets run precisely so it actually slows things down to ensure you get what you wanted.  (Note that this is different from the GCC environment where you can provide hints to the optimizer allowing it to restructure your code.)

You are taking an optimizer that contains about 20 years and many billions of dollars to develop and telling it "I can do this better." Sometimes that happens, but unless you have a very deep understanding about the microarchitecture, about the timings of the micro-ops that take place inside the OOO core to ensure everything is interleaved properly through the five execution ports that include only a single load address port, and otherwise have a perfect understanding of everything internal to the processor, you probably will do a worse job performance-wise. 


Second, it is rarely 'more comfortable'. Inline assembly is harder to maintain and debug, and it is generally more difficult to replace and improve at an algorithmic level. Optimized assembly is about 5x to 10x more verbose, so instead of looking at around 150 lines of code you will be looking at around 1500 lines of code. Good luck wrapping your brain around it.

Third, you can call any Windows function from inline assembly, you just need to load up the registers and the stack properly using a series of mov/push instructions, then call the function "call SomeFunction", and finally clean up the registers and stack when it returns.

For example, if you wanted to call the new CopyFile2 function that allows for restartable and unbuffered asynchronous copies, you would use something like this:
 

__asm
{
... your other code here ...
mov eax, offset parameters
push eax
mov eax, offset newnane
push eax
mov eax, offset oldname
push eax
call _CopyFile2@12
...
}

Or instead of 7 lines of line assembly, you could just write:
CopyFile2(oldname, newname, parameters);
which might actually result in fewer total instructions because the optimizer might be able to leave the values in the stack through side effects elsewhere.

 

 

These days about the only real reason to use inline assembly is when you are writing a legacy device driver and need to read and write from ports on the bus. Even then, modern hardware typically uses memory mapped regions rather than bus ports.

Share this post


Link to post
Share on other sites

 

By now i am using standalone asemby exactly this way (using nasm) but the thing is i would like handy inline assembly instead (or too ).- I think this way i could wrote and use some assembly things faster and morecomfortable

I need convenient environment for easy mixing c with inline assembly (supporting newest see and windows/winapi)


Inline assembly is practically guaranteed to give you the opposite results for both. It will likely be neither faster nor more comfortable to develop.


First, it prevents the optimizer from doing its work. An inline assembly block says "I know exactly what I am doing, do not optimize any of this." Also, it means the compiler is prevented from optimizing nearby code, such as placing variables in registers or making function-wide optimizations; it needs to ensure that your little block of code gets run precisely so it actually slows things down to ensure you get what you wanted.  (Note that this is different from the GCC environment where you can provide hints to the optimizer allowing it to restructure your code.)

You are taking an optimizer that contains about 20 years and many billions of dollars to develop and telling it "I can do this better." Sometimes that happens, but unless you have a very deep understanding about the microarchitecture, about the timings of the micro-ops that take place inside the OOO core to ensure everything is interleaved properly through the five execution ports that include only a single load address port, and otherwise have a perfect understanding of everything internal to the processor, you probably will do a worse job performance-wise. 

Second, it is rarely 'more comfortable'. Inline assembly is harder to maintain and debug, and it is generally more difficult to replace and improve at an algorithmic level. Optimized assembly is about 5x to 10x more verbose, so instead of looking at around 150 lines of code you will be looking at around 1500 lines of code. Good luck wrapping your brain around it.

Third, you can call any Windows function from inline assembly, you just need to load up the registers and the stack properly using a series of mov/push instructions, then call the function "call SomeFunction", and finally clean up the registers and stack when it returns.

For example, if you wanted to call the new CopyFile2 function that allows for restartable and unbuffered asynchronous copies, you would use something like this:
 





__asm
{
... your other code here ...
mov eax, offset parameters
push eax
mov eax, offset newnane
push eax
mov eax, offset oldname
push eax
call _CopyFile2@12
...
}

Or instead of 7 lines of line assembly, you could just write:
CopyFile2(oldname, newname, parameters);
which might actually result in fewer total instructions because the optimizer might be able to leave the values in the stack through side effects elsewhere.

 

 

These days about the only real reason to use inline assembly is when you are writing a legacy device driver and need to read and write from ports on the bus. Even then, modern hardware typically uses memory mapped regions rather than bus ports.

 

 

I do not wont go better than optymizer - I need to do some test

and inline assembly would by more handy to me than standalone

(it should be easier to use, I can go with standalone but would like

to test inline and I am curious which options to choose I have )

Edited by fir

Share this post


Link to post
Share on other sites

VizStudio inline is too obtuse?

 

Watcom inline used to be a snap.   

 

I would think VizStudio would be similar....

 

Haven't played with VizStudio inline myself (assuming it exists) - no real need for it anymore - except perhaps for research purposes.

 

I'd assume VS still supports it.

 

Other than that, i doubt many compilers will support it.

 

Probably going to have to take what you can find.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!