Re: [Sbcl-devel] Arithmetic on tagged integers

 Re: [Sbcl-devel] Arithmetic on tagged integers From: Paul Khuong - 2014-07-08 23:52:15 ```Erik Varga wrote: > I'm currently working on adding some optimisation for tagged integers > to the division-to-multiplication transforms, but I'm unsure of > whether I'm taking the right approach, so I'd like to ask for some > opinions on it. [..] > And the compiled code really would only have those three instructions. > This seems to work in practice too, but I'm not sure if this solution > is elegant enough, so I'd like to ask other's opinion on it. Are there > some already-existing functions for this, or has something similar > been done before? Or would I perhaps need to take a completely > different approach? You probably want a pair of (depending on the result's representation) multiply-shift VOPs. Paul Khuong ```

 [Sbcl-devel] Arithmetic on tagged integers From: Erik Varga - 2014-07-08 19:26:39 ```Hello everyone, I'm currently working on adding some optimisation for tagged integers to the division-to-multiplication transforms, but I'm unsure of whether I'm taking the right approach, so I'd like to ask for some opinions on it. To be able to access the internal representation of fixnums at the source level, I wrote a function that takes a fixnum and returns a word that contains number in its tagged form. I also made a reversing function, so I could do the arithmetic on tagged numbers between calls to the two converting functions. Calling these functions don't give the compiled code any overhead. For example, I could do multiplication and shift on the fixnum x with (%tagged-word-to-fixnum (logandc2 (ash (* (%fixnum-to-tagged-word x) 30) -5) sb!vm:fixnum-tag-mask)) And the compiled code will only have a multiplication, shift and logand instruction, instead of multiple shifts... at least that was my assumption, but this isn't the case. If the derived type of the shift's result is a fixnum, the compiler decides to change it into tagged representation before the logandc2, so a shift is added there. Then the call to %tagged-word-to-fixnum adds another shift in the opposite direction because it got a tagged integer as argument. So there are two unnecessary shifts. This wouldn't happen if the derived type remained "word" after the first shift, so my solution was to make a function that returns its argument but so that the type becomes "word", making the compiler forget the derived type. With this, the multiply-and-shift would look like this: (%tagged-word-to-fixnum (logandc2 (%lose-word-derived-type (ash (* (%fixnum-to-tagged-word x) 30) -5)) sb!vm:fixnum-tag-mask)) And the compiled code really would only have those three instructions. This seems to work in practice too, but I'm not sure if this solution is elegant enough, so I'd like to ask other's opinion on it. Are there some already-existing functions for this, or has something similar been done before? Or would I perhaps need to take a completely different approach? Best regards, Erik ```
 Re: [Sbcl-devel] Arithmetic on tagged integers From: Paul Khuong - 2014-07-08 23:52:15 ```Erik Varga wrote: > I'm currently working on adding some optimisation for tagged integers > to the division-to-multiplication transforms, but I'm unsure of > whether I'm taking the right approach, so I'd like to ask for some > opinions on it. [..] > And the compiled code really would only have those three instructions. > This seems to work in practice too, but I'm not sure if this solution > is elegant enough, so I'd like to ask other's opinion on it. Are there > some already-existing functions for this, or has something similar > been done before? Or would I perhaps need to take a completely > different approach? You probably want a pair of (depending on the result's representation) multiply-shift VOPs. Paul Khuong ```
 Re: [Sbcl-devel] Arithmetic on tagged integers From: Erik Varga - 2014-07-09 08:56:45 ```Paul Khuong wrote: > You probably want a pair of (depending on the result's representation) > multiply-shift VOPs. That would solve the problem for the multiply and shift, but there's some additional arithmetic in the signed version of the truncate transform, where I subtract (ash x (- sb!vm:n-word-bits) from the result, which also adds some unnecessary shifts. I could write VOPs for this too, and there aren't any other operations, but I thought it would be simpler to have just three VOPs for conversion. ```