Editing Spec.isa (section)

==== Putting it all together ====

While not terribly useful as anything more than a teaching example, we can combine several of the techniques from above create to generic mask that functions the same as the bit slicing operation <code>%value[%top:%bottom]</code>:
<pre>
%zerofix = 0 - ((0 - popcount(%top)) >> 63)
%mask = (1 << %top) | (((1 << ((%top - 1) & %zerofix)) - 1) << 1) | 1
%value = 0x123456789ABCDEF
%extracted = (%value & %mask) >> %bottom
</pre>
{{note|type=error|1=The highest bit (63) currently causes a lot of problems, many of which crash the game.  A bit of a description of what's happening there:
* <code>0 - popcount(%top)</code> will return zero if <code>%top</code> is zero, or a negative value if <code>%top</code> is greater than zero (it's an unsigned operand so we don't have to worry about it being less than zero!).
* <code>(0 - popcount(%top)) >> 63</code> extracts just the sign bit: <code>1</code> if the subtraction is negative (and therefore <code>%top&gt;0</code>) or zero if <code>%top=0</code>.
* <code>0 - ((0 - popcount(%top)) >> 63)</code> will again return <code>0</code> if the previous step was zero, but it will return <code>-1</code> if the previous step is <code>1</code>, giving us a mask with either all 64 bits clear or all 64 bits set.
* <code>(%top - 1) & %zerofix</code> will give us zero if <code>%top</code> is zero, by using the all-zeroes mask from the prior step to erase the <code>-1</code> we'd otherwise expect from the subtraction.  If <code>%top</code> is not zero, we accept whatever <code>%top - 1</code> is, using the all-ones mask from the prior step.  This gives us a shift value between 0 and 62 (importantly, not 63.  The whole point of this mess is to remove 63 from our potential range of values).
* <code>((1 << ((%top - 1) & %zerofix)) - 1) &lt;&lt; 1</code> creates the (up to) 62-bit mask as described in the prior sections, and then shifts it over to compensate for the <code>-&nbsp;1</code> we took out initially.
* <code>{{!}} 1</code> fills in the gap created by the shift, and gives us the 63rd bit of our mask.  We can always assume this is valid as our smallest possible mask is <code>1&nbsp;&lt;&lt;&nbsp;0</code> (only the LSB), and every larger mask necessarily also includes the LSB.
* <code>(1 << %top)</code> is the 64th bit of our mask (maximally).  While bit 63 can have a lot of problems with arithmetic operations such as subtraction, it's generally safe with bitwise operations like <code>&lt;&lt;</code> and <code><nowiki>|</nowiki></code>.
These issues will presumably be fixed (or at least no longer crash) as the alpha branch matures, but in the meantime these types of workarounds are necessary (and even when it's fully mature you still won't be able to do <code>1&lt;&lt;64</code> (or whatever the maximum bit width is by then), so some smaller workarounds will still be needed even if they aren't crashing the game).}}

The various methods can also be combined (using AND, OR, XOR, etc.) to create all sorts of interesting masks.  For the most part though, mask-and-shift of contiguous bits is far more commonly used than "interesting" masks.