Re: [Factor-talk] Libudis86.dll (Was: TYPED: Declarations)

[Alexander Ilin]

Thank you for the advice, Björn!

25.11.2016, 17:29, "Björn Lindqvist" :
> It is easiest if you put the builds online somewhere and open an issue
> referencing them. Then John and Doug can add them to the dll directory
> here: http://downloads.factorcode.org/dlls/ That the files you have
> built are smaller than the existing ones can be good or bad. I've
> found that it is often hard to control what dependencies VS will add
> to dlls you build. Sometimes it will decide to link to debug libraries
> and such. But you can check that with the excellent depends.exe
> utility: http://www.dependencywalker.com/

---=--- 
 Александр

--
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

Re: [Factor-talk] Libudis86.dll (Was: TYPED: Declarations)

[Björn Lindqvist]

It is easiest if you put the builds online somewhere and open an issue
referencing them. Then John and Doug can add them to the dll directory
here: http://downloads.factorcode.org/dlls/ That the files you have
built are smaller than the existing ones can be good or bad. I've
found that it is often hard to control what dependencies VS will add
to dlls you build. Sometimes it will decide to link to debug libraries
and such. But you can check that with the excellent depends.exe
utility: http://www.dependencywalker.com/

2016-11-25 9:22 GMT+01:00 Alexander Ilin :
> 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: a300106907mov [0x7691000], eax
> 083c2c15: 83c604add esi, 0x4
> 083c2c18: c7062000  mov dword [esi], 0x20 ! > This should be
> 0x02
> 083c2c1e: a300106907mov [0x7691000], eax
> 083c2c23: ba2d2c3c08mov edx, 0x83c2c2d (test + 0x1d)
> 083c2c28: e903465bffjmp 0x7977230 (+)
> 083c2c2d:   add [eax], al
> 083c2c2f:   add [eax], al
> 083c2c31:   add [eax], al
> 083c2c33:   add [eax], al
> 083c2c35:   add [eax], al
> 083c2c37:   add [eax], al
> 083c2c39:   add [eax], al
> 083c2c3b:   add [eax], al
> 083c2c3d:   add [eax], al
> 083c2c3f: 00invalid
>
> 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
>  a300106907   mov [0x7691000], eax
> 0005 83c604   add esi, 0x4
> 0008 c7062000 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
>



-- 
mvh/best regards Björn Lindqvist

--
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

Re: [Factor-talk] Libudis86.dll (Was: TYPED: Declarations)

[Jon Harper]

All things in factor carry their type with them at runtime. For everything
but integers, this is done by manipulating pointers to the thing instead
and requiring an alignment of the address of the thing. This means that a
pointer to this thing will have its lower bits with a value of 0 (the
number of bits depends on the alignment. In factor, everything is aligned
to 16 bytes, so 4 bits are 0). This is not much of a cost because most
things (think tuples, arrays, etc) are bigger then 16 bytes, and you want
stuff to be aligned for performance anyway.
So since the lower bits always have a value of 0, you can actually put any
value in there an just ignore it when following the pointer.

For integers only, you don't manipulate pointers, you manipulate the value.
When you are doing operations on integers, you need to shift right to get
the value (and throw away the tag), do the operation, then shift left and
re add the tag. You then notice that if you choose the tag 0 for integers,
you don't have to re-add the tag because shifting left inserts zeroes. And
you also notice that "( (a >> 4) + (b >> 4)  ) << 4" is "a + b"  (except
when there is an overflow) because of the maths properties (distribution of
* to +). So for many operations on integers (like +), you can just do them
directly on the tagged (= shifted) integer.

Hopefully I didn't make too many mistakes in my explanation, anyone feel
free to correct me if I'm wrong :)



Jon

On Fri, Nov 25, 2016 at 12:24 PM, Alexander Ilin  wrote:

> Hi!
>
> I have no idea what integer tagging is, but it's great that there is no
> bug.
>
> To all: I still have the 32-bit buld of the DLL, which I'd like to make
> available on the Factor Downloads page.
>
> 25.11.2016, 11:57, "Jon Harper" :
>
> 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"  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: a300106907mov [0x7691000], eax
> 083c2c15: 83c604add esi, 0x4
> 083c2c18: c7062000  mov dword [esi], 0x20 ! > This should be
> 0x02
> 083c2c1e: a300106907mov [0x7691000], eax
> 083c2c23: ba2d2c3c08mov edx, 0x83c2c2d (test + 0x1d)
> 083c2c28: e903465bffjmp 0x7977230 (+)
> 083c2c2d:   add [eax], al
> 083c2c2f:   add [eax], al
> 083c2c31:   add [eax], al
> 083c2c33:   add [eax], al
> 083c2c35:   add [eax], al
> 083c2c37:   add [eax], al
> 083c2c39:   add [eax], al
> 083c2c3b:   add [eax], al
> 083c2c3d:   add [eax], al
> 083c2c3f: 00invalid
>
> 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
>  a300106907   mov [0x7691000], eax
> 0005 83c604   add esi, 0x4
> 0008 c7062000 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

Re: [Factor-talk] Libudis86.dll (Was: TYPED: Declarations)

[Alexander Ilin]

Hi! I have no idea what integer tagging is, but it's great that there is no bug. To all: I still have the 32-bit buld of the DLL, which I'd like to make available on the Factor Downloads page. 25.11.2016, 11:57, "Jon Harper" :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"  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+ disassemble083c2c10: a300106907    mov [0x7691000], eax083c2c15: 83c604    add esi, 0x4083c2c18: c7062000  mov dword [esi], 0x20 ! > This should be 0x02083c2c1e: a300106907    mov [0x7691000], eax083c2c23: ba2d2c3c08    mov edx, 0x83c2c2d (test + 0x1d)083c2c28: e903465bff    jmp 0x7977230 (+)083c2c2d:   add [eax], al083c2c2f:   add [eax], al083c2c31:   add [eax], al083c2c33:   add [eax], al083c2c35:   add [eax], al083c2c37:   add [eax], al083c2c39:   add [eax], al083c2c3b:   add [eax], al083c2c3d:   add [eax], al083c2c3f: 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 a300106907   mov [0x7691000], eax0005 83c604   add esi, 0x40008 c7062000 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 listFactor-talk@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/factor-talk ,--,___Factor-talk mailing listFactor-talk@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/factor-talk  ---=---Александр --
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

Re: [Factor-talk] Libudis86.dll (Was: TYPED: Declarations)

[Jon Harper]

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"  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: a300106907mov [0x7691000], eax
083c2c15: 83c604add esi, 0x4
083c2c18: c7062000  mov dword [esi], 0x20 ! > This should be
0x02
083c2c1e: a300106907mov [0x7691000], eax
083c2c23: ba2d2c3c08mov edx, 0x83c2c2d (test + 0x1d)
083c2c28: e903465bffjmp 0x7977230 (+)
083c2c2d:   add [eax], al
083c2c2f:   add [eax], al
083c2c31:   add [eax], al
083c2c33:   add [eax], al
083c2c35:   add [eax], al
083c2c37:   add [eax], al
083c2c39:   add [eax], al
083c2c3b:   add [eax], al
083c2c3d:   add [eax], al
083c2c3f: 00invalid

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
 a300106907   mov [0x7691000], eax
0005 83c604   add esi, 0x4
0008 c7062000 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

Re: [Factor-talk] Libudis86.dll (Was: TYPED: Declarations)

[Alexander Ilin]

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+ disassemble083c2c10: a300106907    mov [0x7691000], eax083c2c15: 83c604    add esi, 0x4083c2c18: c7062000  mov dword [esi], 0x20 ! > This should be 0x02083c2c1e: a300106907    mov [0x7691000], eax083c2c23: ba2d2c3c08    mov edx, 0x83c2c2d (test + 0x1d)083c2c28: e903465bff    jmp 0x7977230 (+)083c2c2d:   add [eax], al083c2c2f:   add [eax], al083c2c31:   add [eax], al083c2c33:   add [eax], al083c2c35:   add [eax], al083c2c37:   add [eax], al083c2c39:   add [eax], al083c2c3b:   add [eax], al083c2c3d:   add [eax], al083c2c3f: 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 a300106907   mov [0x7691000], eax0005 83c604   add esi, 0x40008 c7062000 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