Hi,
It's actually the correct data.
All integers are shifted by 4 (hence the 28/60 discussions). The tag of integers was chosen to be 0 so that some operations (like +) dont' have to shift before and after. But some operations do have to shift their arguments to their actual values first.If you do : testshift ( n m -- k ) { fixnum fixnum } declare shift ;
you'll see that the second argument is shifted before the shift instruction is called.Or
: test2shift ( n -- n ) 2 shift ;
Should have the correct constant somwhere.,Le 25 nov. 2016 09:23, "Alexander Ilin" <ajs...@yandex.ru> a écrit :Thank you, John, that was very helpful!> P.S., I think 32-bit libudis86.dll exists somewhere, and I know 32-bit libudis86 is supported on other OS's.I have found the sources here: https://github.com/vmt/udis86I happen to have VS2010, so I managed to build both 64- and 32-bit versions of the DLL, v1.7.2. I can contribute those if you tell me the way.BTW, for some reason my 64-bit build DLL file is smaller than the one at http://downloads.factorcode.org/dlls/64/Maybe that's good.Anyway, when testing the thing under 32-bit I found an issue, of which I'm not sure whether it's ours or theirs:IN: scratchpad : test2+ ( n -- n ) 2 + ;IN: scratchpad \ test2+ disassemble083c2c10: a300106907 mov [0x7691000], eax083c2c15: 83c604 add esi, 0x4083c2c18: c70620000000 mov dword [esi], 0x20 ! --------> This should be 0x02083c2c1e: a300106907 mov [0x7691000], eax083c2c23: ba2d2c3c08 mov edx, 0x83c2c2d (test + 0x1d)083c2c28: e903465bff jmp 0x7977230 (+)083c2c2d: 0000 add [eax], al083c2c2f: 0000 add [eax], al083c2c31: 0000 add [eax], al083c2c33: 0000 add [eax], al083c2c35: 0000 add [eax], al083c2c37: 0000 add [eax], al083c2c39: 0000 add [eax], al083c2c3b: 0000 add [eax], al083c2c3d: 0000 add [eax], al083c2c3f: 00 invalidThe same issue is present in the 64-bit build of the libudis86.dll downloaded from http://downloads.factorcode.org/dlls/64/It can also be reproduced using their command-line client:> echo a3 00 10 69 07 83 c6 04 c7 06 20 00 00 00 | udcli -x0000000000000000 a300106907 mov [0x7691000], eax0000000000000005 83c604 add esi, 0x40000000000000008 c70620000000 mov dword [esi], 0x20All three lines of the above output have half-bytes swapped in the mnemonics (0x20 instead of 0x2, 0x4 instead of 0x40, etc.).
This begs the question: do we supply bad data to the disassembler, or does disassembler misinterprets what we give it?---=====---Александр
------------------------------------------------------------------------------
_______________________________________________
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
------------------------------------------------------------------------------
,_______________________________________________
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
------------------------------------------------------------------------------
_______________________________________________ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
