Use lowest bit in pointer as flag

[+retroclouds]

So I'm currently reading this book on Java virtual machines (Oracle jRockit to be more precise) and came to an interesting thing that might work on the TI-99/4A as well.

 

Assuming that pointers always refer to a WORD, you can use the least significant bit as a flag for own use. Thought that was a nice little trick. I for one didn't know about this. Getting back to TI-99/4A, assume PNTR contains the addres of a routine you want to call, say >A000 for example.

 

You could do

    MOVE @PNTR,R1
    .... check if bit is set and do something if set
    ANDI R1,>FFFE ; reset bit
    BL *R1
    ORI R1,1 ; set bit
    MOVE R1,@PNTR

 

Now the question is do you have to reset the bit before calling the subroutine, this is what I did in my example. Can I get around with just leaving the lowest bit set. That would mean, in our case that R1 contains >A001. What does the TMS9900 CPU do in that case, does it ignore the low bit and jumps to >A000 ?

 

I have some use for the low bit, planning on using it in my thread scheduler table in spectra2. For example pause/resume threads without needing extra memory for bookkeeping information. This trick could easily be extended to other memory operations and even though it only offers 1 bit of extra information, can be good if scratchpad memory is tight.

Edited August 19, 2012 by retroclouds

[+Lee Stewart]

It wouldn't be difficult to prove. The TMS9900 only has 15 address lines, so I cannot imagine the low bit is used. According to the E/A manual, each jump instruction takes the jump address, adds 2, subtracts the jump instruction's address (always even) and divides by 2 (or shifts right 1), which leaves the result even. I am sure that branch instructions behave in a similar fashion. They cannot branch to an odd address.

 

...lee

[+retroclouds]

Tried it in classic99 and the emulator seems to handle it right (meaning it doesn't crash)

However, the debugger displays an odd address in the PC, which actually can't be the case (even though I supplied one).

 

In the example I supplied the odd address >6CD3 in R7.

At >6B26 the CPU then does a "BL *R7" and I'd expect it to branch to >6CD2.

 

Are we dealing with a bug in the classic99 debugger ?

 

Edited August 19, 2012 by retroclouds

[+retroclouds]

It wouldn't be difficult to prove. The TMS9900 only has 15 address lines, so I cannot imagine the low bit is used. According to the E/A manual, each jump instruction takes the jump address, adds 2, subtracts the jump instruction's address (always even) and divides by 2 (or shifts right 1), which leaves the result even. I am sure that branch instructions behave in a similar fashion. They cannot branch to an odd address.

 

...lee

 

I have just tried it on my TI-99/4A and yes, it works as expected. cool!

[matthew180]

The 9900 will never have an odd address in the PC, and *all* word based operations always happen on even addresses, even if the actual specified address is odd. Your initial assumptions were correct.

 

[Tursi]

Classic99 probably should not /save/ the LSb in the PC, you're right.. but it should fetch correctly since it masks everything as it fetches.

 

I'm torn about whether to fix it. One reason I show that bit is so you can detect bugs in your code, but it's true that the 9900 probably does not even implement that bit in its registers.

 

Showing the wrong instructions in the debugger, though, that IS a bug. Thanks for the tip!