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 <ajs...@yandex.ru> 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" <jon.harpe...@gmail.com>:
>
> 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
>
>
>
> ---=====---
> Александр
>
>
> ------------------------------------------------------------
> ------------------
>
> _______________________________________________
> 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
