IWETHEY v. 0.3.0 | TODO
1,095 registered users | 0 active users | 0 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New Re: Scratches head...
Oh sure. It won't really be essentially different, but here goes:


\tTITLE\tC:\\My Documents\\Visual Studio Projects\\Junk1\\Junk.cpp
\t.386P
include listing.inc
if @Version gt 510
.model FLAT
else
_TEXT\tSEGMENT PARA USE32 PUBLIC 'CODE'
_TEXT\tENDS
_DATA\tSEGMENT DWORD USE32 PUBLIC 'DATA'
_DATA\tENDS
CONST\tSEGMENT DWORD USE32 PUBLIC 'CONST'
CONST\tENDS
_BSS\tSEGMENT DWORD USE32 PUBLIC 'BSS'
_BSS\tENDS
$$SYMBOLS\tSEGMENT BYTE USE32 'DEBSYM'
$$SYMBOLS\tENDS
$$TYPES\tSEGMENT BYTE USE32 'DEBTYP'
$$TYPES\tENDS
_TLS\tSEGMENT DWORD USE32 PUBLIC 'TLS'
_TLS\tENDS
;\tCOMDAT ??_C@_02ELOP@42?$AA@
CONST\tSEGMENT DWORD USE32 PUBLIC 'CONST'
CONST\tENDS
;\tCOMDAT _main
_TEXT\tSEGMENT PARA USE32 PUBLIC 'CODE'
_TEXT\tENDS
FLAT\tGROUP _DATA, CONST, _BSS
\tASSUME\tCS: FLAT, DS: FLAT, SS: FLAT
endif
PUBLIC\t_main
PUBLIC\t??_C@_02ELOP@42?$AA@\t\t\t\t; `string'
PUBLIC\t__real@8@400ff120000000000000
EXTRN\t_pow:NEAR
EXTRN\t_puts:NEAR
EXTRN\t__chkesp:NEAR
EXTRN\t__fltused:NEAR
;\tCOMDAT ??_C@_02ELOP@42?$AA@
; File C:\\My Documents\\Visual Studio Projects\\Junk1\\Junk.cpp
CONST\tSEGMENT
??_C@_02ELOP@42?$AA@ DB '42', 00H\t\t\t; `string'
CONST\tENDS
;\tCOMDAT __real@8@400ff120000000000000
CONST\tSEGMENT
__real@8@400ff120000000000000 DQ 040fe240000000000r ; 123456
CONST\tENDS
;\tCOMDAT _main
_TEXT\tSEGMENT
_main\tPROC NEAR\t\t\t\t\t; COMDAT
; File C:\\My Documents\\Visual Studio Projects\\Junk1\\Junk.cpp
; Line 5
\tpush\tebp
\tmov\tebp, esp
\tsub\tesp, 72\t\t\t\t\t; 00000048H
\tpush\tebx
\tpush\tesi
\tpush\tedi
\tlea\tedi, DWORD PTR [ebp-72]
\tmov\tecx, 18\t\t\t\t\t; 00000012H
\tmov\teax, -858993460\t\t\t\t; ccccccccH
\trep stosd
; Line 6
\tpush\t1074266112\t\t\t\t; 40080000H
\tpush\t0
\tpush\t1076101120\t\t\t\t; 40240000H
\tpush\t0
\tcall\t_pow
\tadd\tesp, 16\t\t\t\t\t; 00000010H
\tfdivr\tQWORD PTR __real@8@400ff120000000000000
\tfstp\tQWORD PTR -8+[ebp]
\tpush\t1074266112\t\t\t\t; 40080000H
\tpush\t0
\tpush\t1076101120\t\t\t\t; 40240000H
\tpush\t0
\tcall\t_pow
\tadd\tesp, 16\t\t\t\t\t; 00000010H
\tfdivr\tQWORD PTR __real@8@400ff120000000000000
\tfcomp\tQWORD PTR -8+[ebp]
\tfnstsw\tax
\ttest\tah, 64\t\t\t\t\t; 00000040H
\tje\tSHORT $L928
\tpush\tOFFSET FLAT:??_C@_02ELOP@42?$AA@\t; `string'
\tcall\t_puts
\tadd\tesp, 4
$L928:
; Line 8
\tpop\tedi
\tpop\tesi
\tpop\tebx
\tadd\tesp, 72\t\t\t\t\t; 00000048H
\tcmp\tebp, esp
\tcall\t__chkesp
\tmov\tesp, ebp
\tpop\tebp
\tret\t0
_main\tENDP
_TEXT\tENDS
END

-drl
New Thanks...
...I was just wanting to see the instructions that immediately followed the float compare. In this case it was:

fnstsw ax
test ah, 64
je SHORT $L928

Which is strange compared to my experience with the MC68881, where there are direct floating point branch instructions (at least that's the way I remember it).
New BTW
Did you figure out what I put between the brackets? :)
-drl
New Hmmmm
Well, I see the instructions:

push OFFSET FLAT:??_C@_02ELOP@42?$AA@ ; `string'\ncall _puts


And I know that _puts is most likely the printf function, but I can't really decode the constant that's pushed on the stack there. The assembler comment 'string is pretty useless - yes I know it's a string - tell me something I didn't know. But I can't make out the rest of the encryption (something with ELOP in it). :-)
New puts("42");
-drl
     C decimal question: - (admin) - (53)
         Equality on Real/Double is always a crapshoot - (tablizer)
         Don't know... - (Simon_Jester)
         Re: C decimal question: - (deSitter) - (1)
             Makes no difference. - (admin)
         The boolean compare operators - (ChrisR) - (36)
             I've done the subtract - (admin) - (35)
                 Assembly dump? - (ChrisR) - (22)
                     I did my dump with GDB - (Arkadiy)
                     What I get: - (admin) - (20)
                         Speculating... - (ChrisR) - (19)
                             gcc 2.95.4 results - (admin) - (18)
                                 Re: gcc 2.95.4 results - (deSitter) - (1)
                                     EBP is base of stack frame - (Arkadiy)
                                 I86 Assembly is not my specialty... - (ChrisR)
                                 ASM Comments - (ChrisR) - (13)
                                     Errrr... - (admin) - (12)
                                         Getting ASM from VC6 - (deSitter) - (11)
                                             Results - (deSitter) - (10)
                                                 Request... - (ChrisR) - (9)
                                                     Re: Request... - (deSitter) - (8)
                                                         Trimming it down... - (ChrisR) - (7)
                                                             Re: Trimming it down... - (deSitter) - (6)
                                                                 Scratches head... - (ChrisR) - (5)
                                                                     Re: Scratches head... - (deSitter) - (4)
                                                                         Thanks... - (ChrisR) - (3)
                                                                             BTW - (deSitter) - (2)
                                                                                 Hmmmm - (ChrisR) - (1)
                                                                                     puts("42"); -NT - (deSitter)
                                 gcc 2.95.26 - (ChrisR)
                 Did you try it with optimizations off? -NT - (deSitter) - (7)
                     A really good optimizing compiler... - (ChrisR) - (6)
                         Yes.. - (deSitter)
                         Compiler has no way to predict how pow() is implemented - (Arkadiy) - (4)
                             IEEE - (deSitter) - (2)
                                 pow() is library, not hardware - (Arkadiy) - (1)
                                     True - (deSitter)
                             Re: Compiler has no way to predict how pow() is implemented - (deSitter)
                 An option of interest? - (ChrisR) - (3)
                     I'll look into that. Datum: gcc 3.2.1 on glibc 2.3.1 -NT - (admin)
                     Doesn't seem to make any difference. - (admin) - (1)
                         Re: Doesn't seem to make any difference. - (deSitter)
         Not a direct answer, but still on-topic. - (static)
         RESOLUTION: - (admin) - (10)
             A caveat from Borland: - (a6l6e6x) - (6)
                 This was slightly different. - (admin) - (5)
                     Re: This was slightly different. - (deSitter)
                     Oh - to discover a real compiler problem - (deSitter) - (1)
                         This is not considered a compiler problem by the GCC folks. - (admin)
                     Scott, that's a bug worthy of catching - (Simon_Jester) - (1)
                         Fun to track down, at least. - (admin)
             Re: RESOLUTION: - (deSitter) - (2)
                 Historically speaking... - (ChrisR) - (1)
                     Re: Historically speaking... - (deSitter)

bash#_
580 ms