Re: [Factor-talk] Disassembly

2018-01-19 Thread Björn Lindqvist 
Hi Alex,

In this case, the new optimizer actually is strictly better. Mostly because
it uses shorter instruction encodings. For example, it uses inc rbx whereas
old factor used add rbx, 1. But the old factor had a compiler pass called
"height normalization" which in some situations made it emit superior code.
But it also sometimes generated faulty code so it had to be removed. :) I
have been working on a new step to get rid of redundant height changes but
it is not done. See https://github.com/factor/factor/issues/1617

2018-01-17 23:17 GMT+01:00 Alexander Ilin :

> Hello, Björn!
>
> Thanks for the explanation! I've already lost hope of seeing a reply to
> that, but you appeared out of nowhere and saved the day. Thank you!
>
> Are you saying there was a different (better?) optimizer in the previous
> Factor releases? What happened to it?
>
> 17.01.2018, 22:25, "Björn Lindqvist" :
>
>
> r14 contains the datastack top pointer. It is incremented by 0x10 which is
> 16 bytes or 2 cells. Your code was supposed to put two items on the stack,
> but then the optimizer did a great job and noticed that the values didn't
> have to be put on the stack but could be kept in registers. But it didn't
> optimize away the stack increment/decrement. Possibly, the optimizer in
> 0.96 or 0.97 did a better job at optimizing code like that.
>
>
>
> ---=---
> Александр
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Factor-talk mailing list
> Factor-talk@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/factor-talk
>
>


-- 
mvh/best regards Björn Lindqvist
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

Re: [Factor-talk] Disassembly

2018-01-17 Thread Alexander Ilin 
Hello, Björn! Thanks for the explanation! I've already lost hope of seeing a reply to that, but you appeared out of nowhere and saved the day. Thank you! Are you saying there was a different (better?) optimizer in the previous Factor releases? What happened to it? 17.01.2018, 22:25, "Björn Lindqvist" : r14 contains the datastack top pointer. It is incremented by 0x10 which is 16 bytes or 2 cells. Your code was supposed to put two items on the stack, but then the optimizer did a great job and noticed that the values didn't have to be put on the stack but could be kept in registers. But it didn't optimize away the stack increment/decrement. Possibly, the optimizer in 0.96 or 0.97 did a better job at optimizing code like that.  ---=---Александр --
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

Re: [Factor-talk] Disassembly

2018-01-17 Thread Björn Lindqvist 
The mov [rip-0x117cfdf], eax instruction is indeed peculiar. It actually is
polling a safe point. When ctrl-c is pressed, the running thread is ordered
to stop as quickly as possible. It can't just halt anywhere but must
continue to execute until it comes to a point where it is safe to halt -- a
safe point. Meanwhile, the VM has set the memory page at address rip-0x117cfdf
to write protected which makes it so the instruction triggers a page
fault.  You can see how it is handled in the memory_signal_handler_impl()
function in errors.cpp This page explains safe points in more detail:

http://psy-lob-saw.blogspot.se/2014/03/where-is-my-safepoint.html

r14 contains the datastack top pointer. It is incremented by 0x10 which is
16 bytes or 2 cells. Your code was supposed to put two items on the stack,
but then the optimizer did a great job and noticed that the values didn't
have to be put on the stack but could be kept in registers. But it didn't
optimize away the stack increment/decrement. Possibly, the optimizer in
0.96 or 0.97 did a better job at optimizing code like that.



2017-10-12 23:32 GMT+02:00 Alexander Ilin :

>
> Hello!
>
>   I'm trying to make sense of some disassembled code. Could someone help
> me out here?
>
> ```
> IN: scratchpad [ 256  [ drop ] each ] disassemble
> 001a8dbcdfc0: 89053a30e8fe  mov [rip-0x117cfc6], eax !
> What's this?
> 001a8dbcdfc6: b80001mov eax, 0x100
> 001a8dbcdfcb: 31db  xor ebx, ebx
> 001a8dbcdfcd: 4983c610  add r14, 0x10
> 001a8dbcdfd1: e90900jmp 0x1a8dbcdfdf (( gensym ) + 0x1f)
> 001a8dbcdfd6: 48ffc3inc rbx
> 001a8dbcdfd9: 89052130e8fe  mov [rip-0x117cfdf], eax !
> What's this?
> 001a8dbcdfdf: 4839c3cmp rbx, rax
> 001a8dbcdfe2: 0f8ceeff  jl dword 0x1a8dbcdfd6 (( gensym ) + 0x16)
> 001a8dbcdfe8: 4983ee10  sub r14, 0x10
> 001a8dbcdfec: 89050e30e8fe  mov [rip-0x117cff2], eax !
> What's this?
> 001a8dbcdff2: c3ret
> 001a8dbcdff3:   add [rax], al
> 001a8dbcdff5:   add [rax], al
> 001a8dbcdff7:   add [rax], al
> 001a8dbcdff9:   add [rax], al
> 001a8dbcdffb:   add [rax], al
> 001a8dbcdffd:   add [rax], al
> 001a8dbcdfff: 00invalid
> ```
>
>   The lines like `mov [rip-0x117cfdf], eax` I read as "copy the contents
> of the EAX register to a memory location pointed to by a memory address
> relative to the current Instruction Pointer register (rIP)". Am I right? If
> so, why is that being done inside the loop, and twice at the procedure
> entry and exit?
>
>   Also, why is the register r14 incremented by 0x10 on entry, and
> decremented on exit? What is r14 used for?
>
> ---=---
>  Александр
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Factor-talk mailing list
> Factor-talk@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/factor-talk
>



-- 
mvh/best regards Björn Lindqvist
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

[Factor-talk] Disassembly

2017-10-12 Thread Alexander Ilin 

Hello!

  I'm trying to make sense of some disassembled code. Could someone help me out 
here?

```
IN: scratchpad [ 256  [ drop ] each ] disassemble
001a8dbcdfc0: 89053a30e8fe  mov [rip-0x117cfc6], eax ! What's 
this?
001a8dbcdfc6: b80001mov eax, 0x100
001a8dbcdfcb: 31db  xor ebx, ebx
001a8dbcdfcd: 4983c610  add r14, 0x10
001a8dbcdfd1: e90900jmp 0x1a8dbcdfdf (( gensym ) + 0x1f)
001a8dbcdfd6: 48ffc3inc rbx
001a8dbcdfd9: 89052130e8fe  mov [rip-0x117cfdf], eax ! What's 
this?
001a8dbcdfdf: 4839c3cmp rbx, rax
001a8dbcdfe2: 0f8ceeff  jl dword 0x1a8dbcdfd6 (( gensym ) + 0x16)
001a8dbcdfe8: 4983ee10  sub r14, 0x10
001a8dbcdfec: 89050e30e8fe  mov [rip-0x117cff2], eax ! What's 
this?
001a8dbcdff2: c3ret 
001a8dbcdff3:   add [rax], al
001a8dbcdff5:   add [rax], al
001a8dbcdff7:   add [rax], al
001a8dbcdff9:   add [rax], al
001a8dbcdffb:   add [rax], al
001a8dbcdffd:   add [rax], al
001a8dbcdfff: 00invalid 
```

  The lines like `mov [rip-0x117cfdf], eax` I read as "copy the contents of the 
EAX register to a memory location pointed to by a memory address relative to 
the current Instruction Pointer register (rIP)". Am I right? If so, why is that 
being done inside the loop, and twice at the procedure entry and exit?

  Also, why is the register r14 incremented by 0x10 on entry, and decremented 
on exit? What is r14 used for?

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

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk