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/udis86 I 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+ disassemble 083c2c10: a300106907 mov [0x7691000], eax 083c2c15: 83c604 add esi, 0x4 083c2c18: c70620000000 mov dword [esi], 0x20 ! --------> This should be 0x02 083c2c1e: a300106907 mov [0x7691000], eax 083c2c23: ba2d2c3c08 mov edx, 0x83c2c2d (test + 0x1d) 083c2c28: e903465bff jmp 0x7977230 (+) 083c2c2d: 0000 add [eax], al 083c2c2f: 0000 add [eax], al 083c2c31: 0000 add [eax], al 083c2c33: 0000 add [eax], al 083c2c35: 0000 add [eax], al 083c2c37: 0000 add [eax], al 083c2c39: 0000 add [eax], al 083c2c3b: 0000 add [eax], al 083c2c3d: 0000 add [eax], al 083c2c3f: 00 invalid The 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 -x 0000000000000000 a300106907 mov [0x7691000], eax 0000000000000005 83c604 add esi, 0x4 0000000000000008 c70620000000 mov dword [esi], 0x20 All 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