TMS9900 assembly language tricks

[+TheBF]

5 hours ago, apersson850 said:

I think Lee was referring to that the value in R4 has to be 00XX in hex. Or XX00. If you had used 199 hex in your example, it would have added 0199 to 9901, with the result 9A9A instead.

Indeed.

The stack diagram for FILLW ( addr len c -- )  means that the top argument is a character.

I know I know. It's just a comment. Not enforced by the compiler like certain other languages that begin with the letter 'P'.

 

That is all the warning you get to make sure the argument is less than 255.

 

If that is troublesome you could always add runtime checking yourself.   

 

: FILLW   ( addr len c -- )
    DUP FF00 AND ABORT" You dummy! I told you the top argument is a character"
    FILLW 
;

 

 

 

 

 

Edited July 13, 2022 by TheBF
Updated code: mask was reversed.

[apersson850]

A few posts back we were at assembly level, and there everything is game.

[+TheBF]

3 hours ago, apersson850 said:

A few posts back we were at assembly level, and there everything is game.

Things got a bit blurry I guess because the Assembler code was a finished Forth word.

The Forth routine lets you put a number directly into R4, like Assembler code so "everything is game" as well.

The difference, I suppose, is that if you use the correct operators for byte reads from memory or use a byte literal in your code, R4 will always be clear on lower bit side.

 

[apersson850]

It doesn't matter if R4 contains a byte value per the TMS 9900 definition (to the left), or a 16-bit value not larger than 255 (to the right). As long as 8 bits are zero at one end, it will work.

 

From that point of view, the sequence

STWP R1

MOVB R4,@9(R1)

is better, since it will only duplicate the left byte in R4. The right byte doesn't have to be zero for this to work.

STWP R1

MOVB @9(R1),R4

will of course duplicate the right byte.

But it is at the expense of using one register for a temporary value. Now you frequently have such a register available, so that may not be too big a disadvantage.

[apersson850]

On 9/8/2010 at 5:20 AM, insomnia said:

By using the BLWP instruction, you can have overlapping workspaces between the caller and callee.

The standard procedure is to access the caller's registers via R13 in the called procedure's workspace.

MOV @8(R13),R2

will bring the content of the caller's R4 to the called code's R2. More flexible but slower.

 

Likewise,

MOV *R14+,R2

will bring data following the BLWP instruction in memory into R2 in the subroutine. At the same time, it will advance the return address in R14, so we return to the code after the data.

This trick you can do with BL too, but you have to do a

MOV *R11+,R2

of course.

 

This can be used to pass parameters to subroutines. Let's say you have a routine which reads keypresses from the keyboard.

BL   @KEYPRESS

DATA NULLINPUT

DATA INVALID

is a code sample where the two data items after the call instruction tells the routine what to do if the user presses just ENTER and what to do if he does enter something that's not valid, like not a number, for example.

In all cases, the subroutine must increment R11 by four to return properly, regardless of whether it really needs the data after the BL instruction or not.

 

A similar trick, but in the other direction, is that since R15 in a code called by BLWP will hold a copy of the status register, a copy that's restored to ST on return, you can pass a message there too. By manipulating R15, you can for example change the EQ bit before returning. Thus you can call a subroutine which sets up test conditions before returning, and make a call like this

BLWP @SUBVECTOR

JNE  BADDATA

Here the subroutine is supposed to come back with the EQ bit set if everything is OK. If not, you want to handle that the data wasn't correct.

Edited July 14, 2022 by apersson850