Differences of codegeneration for not-DWORD argments in INVOKE

Started by Antariy, November 16, 2010, 09:48:44 PM

Previous topic - Next topic

Antariy

Quote from: clive on November 17, 2010, 01:18:36 AM
For giggles, trying the 32-bit MSVC 1.00 (MSC 8.00 circa 1993)

Some giggles would be probably  :bg. More "modern" optimizers of MSVC will not produce code for functions which is have no code inside it, and "remove" calls to that strange functions.



Alex

clive

Quote from: Antariy on November 17, 2010, 01:26:32 AM
Some giggles would be probably  :bg. More "modern" optimizers of MSVC will not produce code for functions which is have no code inside it, and "remove" calls to that strange functions.

I know the code is pretty stupid. Just trying to see if this was mainly a MASM issue, I think the C compilers are better validated.

Doesn't get much better in MSVC 6.00 (12.00 circa 1998)

Intel's C/C++ 4.0 (circa 1998) generates this
00000070                    _main:
00000070 55                     push    ebp
00000071 8BEC                   mov     ebp,esp
00000073 83EC03                 sub     esp,3
00000076 83E4F8                 and     esp,0FFFFFFF8h
00000079 83C404                 add     esp,4
0000007C 83EC04                 sub     esp,4
0000007F 57                     push    edi
00000080 33C0                   xor     eax,eax
00000082 66890424               mov     [esp],ax
00000086 E8C5FFFFFF             call    _ProcWORD@4
0000008B 57                     push    edi
0000008C 33C0                   xor     eax,eax
0000008E 66890424               mov     [esp],ax
00000092 E8B9FFFFFF             call    _ProcWORD@4
00000097 57                     push    edi
00000098 C7042400000000         mov     dword ptr [esp],0
0000009F E8BCFFFFFF             call    _ProcDWORD@4
000000A4 57                     push    edi
000000A5 C7042400000000         mov     dword ptr [esp],0
000000AC E8AFFFFFFF             call    _ProcDWORD@4
000000B1 B801000000             mov     eax,1
000000B6 8BE5                   mov     esp,ebp
000000B8 5D                     pop     ebp
000000B9 C3                     ret
It could be a random act of randomness. Those happen a lot as well.

frktons

What do you think? Intel guys know better than MS guys how to use their own CPU?
Mind is like a parachute. You know what to do in order to use it :-)

Antariy

Quote from: clive on November 17, 2010, 02:05:32 AM
Doesn't get much better in MSVC 6.00 (12.00 circa 1998)

Did you used /Ox switch? That is strange, if with this switch it is not removes all stuff without payload - it automatically enables maximal inlineing.



Alex

Antariy

With MSVC10 and /Ox I get this listing:

; Function compile flags: /Ogtpy
_TEXT SEGMENT
_argc$ = 8 ; size = 4
_argv$ = 12 ; size = 4
_main PROC
; Line 23
mov eax, 1
; Line 24
ret 0
_main ENDP


If separation of the functions for linker is on, no any other code will be included to executable, and in main function is not called anything - only return 1.



Alex

Antariy

Quote from: frktons on November 17, 2010, 02:13:13 AM
What do you think? Intel guys know better than MS guys how to use their own CPU?

Of course, they better :P

The same beautiful part of listing is:

00000079 83C404                 add     esp,4
0000007C 83EC04                 sub     esp,4


and


00000097 57                     push    edi
00000098 C7042400000000         mov     dword ptr [esp],0




Alex

Magnum

Quote from: frktons on November 17, 2010, 02:13:13 AM
What do you think? Intel guys know better than MS guys how to use their own CPU?

Delete your 1st sentence.

Replace the question mark in the 2nd sentence with an exclamation point.  :bdg
Have a great day,
                         Andy

frktons

Quote from: Magnum on November 28, 2010, 06:42:17 PM
Quote from: frktons on November 17, 2010, 02:13:13 AM
What do you think? Intel guys know better than MS guys how to use their own CPU?

Delete your 1st sentence.

Replace the question mark in the 2nd sentence with an exclamation point.  :bdg

Delete your first advice, it is redundant.  :green2

Delete your second advice, it it redundant too.  :cheekygreen:
Mind is like a parachute. You know what to do in order to use it :-)

ToutEnMasm

Quote
ProcWithByteParam   PROTO param1:BYTE
ProcWithWordParam   PROTO param1:WORD
ProcWithDWordParam   PROTO param1:DWORD
ProcWithQWordParam   PROTO param1:QWORD
Where is the problem ?
The first proto need a push BYTE to work and this instruction don't exist.
The second need PUSH word to work ,the instruction exist but there is a risk of stack misalign.
                      You need to made this type of push by Two to avoid a misalignement of the stack.
                       This made the push word unusable in a prototype.
Each time you use a byte or a word in a prototype , you ignore this.
Masm try only to arrange this (not always without problem).I don't know exactly for what purpose but it isn't a thing to do.
The movzx instruction can be used in case you need to use a byte in a call
Here is the intel documention on push
Quote
Decrements the stack pointer and then copies the specified immediate value or the value in the
specified register or memory location to the top of the stack (the memory location pointed to by
SS:rSP).
The operand-size attribute determines the number of bytes pushed to the stack. The stack-size attribute
determines whether SP, ESP, or RSP is the stack pointer. The address-size attribute is used only to
locate the memory operand when pushing a memory operand to the stack.
If the instruction pushes the stack pointer (rSP), the resulting value on the stack is that of rSP before
execution of the instruction.
There is a PUSH CS instruction but no corresponding POP CS. The RET (Far) instruction pops a value
from the top of stack into the CS register as part of its operation.
In 64-bit mode, the operand size of all PUSH instructions defaults to 64 bits, and there is no prefix
available to encode a 32-bit operand size. Using the PUSH CS, PUSH DS, PUSH ES, or PUSH SS
instructions in 64-bit mode generates an invalid-opcode exception.
Pushing an odd number of 16-bit operands when the stack address-size attribute is 32 results in a
misaligned stack pointer.




Magnum

Quote from: frktons on November 28, 2010, 06:44:54 PM
Quote from: Magnum on November 28, 2010, 06:42:17 PM
Quote from: frktons on November 17, 2010, 02:13:13 AM
What do you think? Intel guys know better than MS guys how to use their own CPU?

Delete your 1st sentence.

Replace the question mark in the 2nd sentence with an exclamation point.  :bdg

Delete your first advice, it is redundant.  :green2

Delete your second advice, it it redundant too.  :cheekygreen:

I meant my comments as humor.

Had a really really crappy week last week.

In my job search, I "networked" with 2 of Pearland's finest men.

They were smiling when they left.

I am thankful that their lights were off.  :U

"What are you doing?"

I am riding my bike sir. I am job hunting.

"Don't get smart with me!"

Andy
Have a great day,
                         Andy