To rotate or to shift, that is the question

While thinking about ways to print a 32 bit value with only a 16 bit NUMBER_TO_STRING I found an opcode called RLx. Happily I thought it meant Rotate Left, and that is also what it says in the documentation.

/*! \page Logic
*
* opRL16 (SOURCE1, SOURCE2, DESTINATION)
*
*- Rotate left 16 bit value DESTINATION = SOURCE1 << SOURCE2\n
*- Dispatch status unchanged
*
* \param (DATA16) SOURCE1
* \param (DATA16) SOURCE2
* \return (DATA16) DESTINATION
*/

Happily I figured I could rotate left and pick the lowest byte four times and convert those into figures that could be converted, but unfortunately it doesn’t really rotate left. By looking at the implementation I can see that it shifts left.

void cMathRl16(void)
{
  DATA16  Tmp;

  Tmp   =  *(DATA16*)PrimParPointer();
  Tmp <<=  *(DATA16*)PrimParPointer();
  *(DATA16*)PrimParPointer()  =  Tmp;
}

So unless the left shift operator on the Brick is actually a rotate the RLx function won’t be of much use.

I guess what I can do is MOVE32_8 the 32 bit number to an 8 bit number, and then sign convert it to a 16 bit value that I convert and add to a string, then DIV32 the original 32 bit number by 256 and do the same procedure again until I’ve fetched all of the 4 bytes individually.

Luckily I love these kinds of quirky limitations. It just makes me more inspired to keep learning about things and think about what to build for the device. It changes my own expectations of the game I’ll make and takes some of the pressure off.

Tomorrow I’ll look into printing that 32 bit value.

UPDATE!

After looking at the documentation generated by Doxygen I found the NUMBER_FORMATTED function that accept a 32 bit number and converts into a string. So that seems like it’ll do the trick. :)

Leave a Reply