to get VC++ generate asm?

[daydreamer]

trying to use VC++ for lots of source code to get a starting point,preferably with optimization switch off to get more readable code

[TimoVJL]

/Fa[file] name assembly listing file    /FA[scu] configure assembly listing

[nidud]

deleted

[daydreamer]

thanks Timo,nidud I try that

[hutch--]

Magnus,

To use 32 VC/VS code, set it to UNoptimised and you have some chance of making sense of it. The optimised code is very difficult to follow. Start with the un-optimised code and progressively optimise it manually and with practice you should be able to get it faster.

[daydreamer]

Magnus,

To use 32 VC/VS code, set it to UNoptimised and you have some chance of making sense of it. The optimised code is very difficult to follow. Start with the un-optimised code and progressively optimise it manually and with practice you should be able to get it faster.

Magnus,

To use 32 VC/VS code, set it to UNoptimised and you have some chance of making sense of it. The optimised code is very difficult to follow. Start with the un-optimised code and progressively optimise it manually and with practice you should be able to get it faster.

thanks, I found out I need to call all "proc's" with variables in main,otherwise they arent included in source file,any switch I can use for this kinda sizeoptimized code

Code Select Expand

?calcy@@YAHHH@Z PROC ; calcy, COMDAT
; Line 109
fld QWORD PTR __real@3fe921f9f01b866e
call __CIsin
fmul QWORD PTR __real@406fe00000000000
jmp __ftol2_sse
?calcy@@YAHHH@Z ENDP
no idea what this jmps/calls do,but they have nothing todo with SSE
so I have to decypher _CIsin and all other included libraries

Code Select Expand

fild DWORD PTR _a$[esp+28]
fmul QWORD PTR ?pi@@3NA ; pi
fadd ST(0), ST(0)
fdiv QWORD PTR __real@4076800000000000
call __CIcos
fmul QWORD PTR __real@c08f400000000000
call __ftol2_sse
mov edi, DWORD PTR _a$[esp+28]
mov ebp, DWORD PTR tv420[esp+28]
xor ebx, ebx
mov DWORD PTR tv215[esp+28], eax
add edi, 720 ; 000002d0H

overuse of esp+somevalue,I am not used to this kind of codestyle,but its probably C++ pointerbased to the variables,also many memtomem moves

also tried the mixed asmcode/sourcecode option,maybe good for reference mixed C++ proc code/asm code easier to read

[aw27]

overuse of esp+somevalue,I am not used to this kind of codestyle,but its probably C++ pointerbased to the variables,also many memtomem moves

You need to configure in Properties how you want things. It takes some time to understand Visual Studio C/C++ (which is nothing when compared with the time required to understand other compilers that produce enormous and slow bloatware under windows).
There is an option that says 'Omit Frame Pointers'. When is set to Yes it does not make the usual push ebp, etc frame.
Then you must tell through Enable Instruction Set if you want SSE, AVX or the old 8087 instructions. The default for x86 is 8087.
You can also build in release mode and set some functions for no Optimization using a #pragma optimize( "", on ) and #pragma optimize( "", off ) statement.

[hutch--]

Magnus,

What I have tended to do when I find a C source that did something useful in 32 bit was to build each function alone in un-optimised form with the option to get the asm listing. You have to untangle some of the leading equates but you can generally get them to work then you manually optimise the asm listing while testing it for both speed and accuracy. Most of what you will do is get rid of redundant memory operands and jump reduction but its great practice for manual optimisation and once you get used to it you can generally but not always see a speed improvement.

[daydreamer]

Magnus,

What I have tended to do when I find a C source that did something useful in 32 bit was to build each function alone in un-optimised form with the option to get the asm listing. You have to untangle some of the leading equates but you can generally get them to work then you manually optimise the asm listing while testing it for both speed and accuracy. Most of what you will do is get rid of redundant memory operands and jump reduction but its great practice for manual optimisation and once you get used to it you can generally but not always see a speed improvement.

thanks,I have lots of HLL code, I want to try to automatize the process with help of a C compiler and some proc are very complex and some are unique, to get a starting point for make it faster
@aw,thanks

[daydreamer]

Read some about how compilers work,maybe the code becomes less cryptic if i put all variables static first ,from local variables inside proc ?because i suspect it gets rid of many cryptic esp+number ?
Make variables static and global puts them directly in .data section
???

[daydreamer]

just for fun I tested optimized option,it mostly used few more fp registers to more extent than just memory and more general regs and shifts
read randy hydes books,AoA MMX section,write great code books and he brings up BSS section and different sections of memory and how compilers do ,mixed with masm code,something interesting things worth trying

[daydreamer]

another exercise using VC++ and masm would be port alternative math functions to C

different VC++ versions produce different final size of code

[daydreamer]

What I have tended to do when I find a C source that did something useful in 32 bit was to build each function alone in un-optimised form with the option to get the asm listing. You have to untangle some of the leading equates but you can generally get them to work then you manually optimise the asm listing while testing it for both speed and accuracy. Most of what you will do is get rid of redundant memory operands and jump reduction but its great practice for manual optimisation and once you get used to it you can generally but not always see a speed improvement.

how about improve esp pointer to local arrays codestyle compiler produces with save esp at the beginning of proc to a variable and restore at the end of proc?as long as I use mov's instead of push/pop to save registers in that section,so lots of movss xmm0,[esp] instead of movss xmm0,[esp+offset]
nonarray variables moved into static global section

[daydreamer]

Progress so far:
Because so many functions are based on trigonometry
Cosine
Sine
Sincos
Calcx proc
Wraps cosine + mul
Calcy proc
Wraps sine+ mul

functions need to be tested and real8 versions need to be made

[hutch--]

Magnus,

The ESP or EBP numbers are just memory operands that are usually LOCAL in scope, with a stack frame it will be EBP, with no stack frame it will be ESP and you will just have to get used to it. I suggested using the UN optimised output options as they can usually be understood and you then have the choice of how to optimise it. It will need things like redundant jump removal and memory operand removal where possible.

Now with a stack frame in 32 bit that has 3 arguments, you start at [ebp+8], next arg is [ebp+12] and the third argument is [ebp+16]. A NO stackframe procedure uses [esp+4], [esp+8] and the third arg is [esp+12] but it starts to get complicated once you use PUSH to preserve registers.

If you have to preserve ESI and EDI, you PUSH them in order then the ESP addresses have to be corrected by 8 (2 pushes). What I tend to do to keep track of the arguments is use a notation like this, [esp+4][8], [esp+8][8] and [esp+12][8].

It looks messy and you have to get it right but it comes with practice.