Common assembler mistakes for newbies and oldbies.....

[marc.hull]

I thought it would be useful to log our recurring lamentables while coding in language of mnemonics. Perhaps we can help each other and get a laugh... Come on..... how many times have you SWORN your machine was broken

 

My top 10.....

 

10. Not remembering the fact that my DEC loop does not end until after zero has been reached.

 

09. Chasing down an impossible error because a BLWP was where a BL should have been. (#1 reason for shelving old BLWP....)

 

08. Confusing your CPU memory moves with your VDP memory moves. (Happens to the most seasoned sometimes...)

 

07. Not shutting off the interrupt and winding up in video la-la land. (why is the screen broken ???)

 

06. Getting the color table mixed up with the pattern table and scratching your ass for an hour....

 

05. Typing 0854 when you meant >0854. Stupid computer do what I MEAN !!

 

04. Buffer full... WTF do you mean buffer full ???

 

03. @, * +,() ?????? Who doesn't have to revisit the addressing modes section every now and then ??

 

02. Ohhhhh, MOVB byte DOESN'T clear the LSB....... Damn... that would have been good to remember

 

 

and finally my favorite and most likely error caused for us fumble fingers....

 

 

01. NOOOOoooooo. If I have told you once I have told you a million times you STOOOOPID computer..... It is NOT R-OH you simple minded POS ! It is R-ZERO !!!!!! Just because I typed R-OH.... you should know I meant R-ZERO !!!!! You sorry piece of M***F*** SH****. Are you TRYING to piss me off tonight ??? Oh.... Sorry....

 

Let's hear em coders ....

[matthew180]

Haha, that's a pretty good list. My top few are:

 

1. Forgetting that it is the MSB of a register that goes to the VDP.

 

2. Using MOV @BUFF,R0 instead of LI R0,BUFF. ARRRGGHH! That one caused me a 30 minute Classic99 debug session the other night.

 

3. Remembering how the registers for MPY and DIV are used.

 

4. Remembering that the source to destination is left to right, which is opposite from a lot of other systems, notably the x86.

 

5. That R0 cannot be used for an index register.

 

And yeah, I have to revisit the access modes every now and then too, to make sure I really can't do: MOV R1+,R2 (auto increment without the indirect addressing.) Oh, how that would be so nice.

 

Matthew

[+adamantyr]

Common assembler errors:

 

5) Forgetting to update constants after a major change "Oh, that's why my video screen is screwed up, it's using the color table for screen positions"

4) Not updating COPY directives for an emulated assembler and a PC-based assembler

3) Disabling interrupts without a key scan "WHY ISN'T QUIT WORKING?!"

2) Using a return stack and forgetting to do a DECT on it one time

 

AND the number one...

 

1) DEC R2 JNE LOOP "Oh... R2 is already 0... crap"

[marc.hull]

3. Remembering how the registers for MPY and DIV are used..................

 

 

!!! I gotta read the manual ever friggin time on that one !!! Excellent....

[Willsy]

>3. Remembering how the registers for MPY and DIV are used.

 

Ha! Yes, every time!

 

However, for me, the most EVIL instructions on the TI are the SOC and SZC instructions.

 

Man. They get me EVERY freaking time. WHY OH WHY OH WHY couldn't they just have OR and AND for god's sake!

[+InsaneMultitasker]

1. CRU instructions - remembering when the offset is doubled or not. As well as which order the bits get loaded/stored.

2. Using a WRITE opcode in place of a READ, especially where sectors 0 and 1 are being accessed.

3. combining #2 with a MOV instead of a MOVB, and writing random sectors all over your hard drive containing your source code files.

4. Backing up your source files AFTER you made a thousand modifications and finding out that nothing works properly anymore, without a clue as to when it stopped working

 

and my favorite:

 

5. assembling the files over and over, making more "fixes", as frustration mounts, nothing is working.... until you realize the object code you are testing is the PREVIOUSLY named iteration and that you should be testing the new object file you told the assembler to create.

[Tursi]

5. assembling the files over and over, making more "fixes", as frustration mounts, nothing is working.... until you realize the object code you are testing is the PREVIOUSLY named iteration and that you should be testing the new object file you told the assembler to create.

 

Bingo!! That one bites me all the bloody time! hehe.

 

However, for me, the most EVIL instructions on the TI are the SOC and SZC instructions.

Man. They get me EVERY freaking time. WHY OH WHY OH WHY couldn't they just have OR and AND for god's sake!

 

SOC is OR. SZC, well, I finally have started to live with it.

 

um... I really should have a good list here, but I don't. My worst ones:

 

1) When comparing for magnitude (ie: greater than, less than, etc), remembering which way to order the arguments and remembering which jumps are for signed or unsigned, and which combinations also have 'or equal to' available... (JH, JHE, JL, JLT, JGT... oi...)

 

2) CRU was said. But I dislike everything about it enough for it to be worth repeating.

 

3) MPY and DIV were touched on, but while I remember WHICH registers to use, I sometimes forget that one of the arguments to each is 32 bit...

 

4) I have trouble remembering the names of the shift instructions. This is not 9900 specific -- in fact if it were just the 9900 I'd be fine. But there's no consistency across assemblers for what order to put the words in. They all have an arithmetic shift left... or is it an arithmetic left shift, or a shift left arithmetic.... which mneumonic will compile today?

[matthew180]

and remembering which jumps are for signed or unsigned,

 

I got over that recently by realizing there are only two that deal with signed values: Jump if Greater Than (JGT) and Jump if Less Than (JLT). They are the only two that use the words "greater" and "less". The other unsigned jumps use the words "high" and "low", i.e. JHE is Jump if High or Equal, etc.

 

Matthew

[+Vorticon]

Sounds extremely familiar (even the ass scratching part), but my favorite hair puller remains number 2. I would also add storing nested subroutines return addresses to... the same location WTF is right he he.

[Willsy]

Why is it that BRANCH needs an @ but JMP doesn't?

 

B @THIS

JMP THAT

 

WTF? That's a killer fow newbies. Is there some logic to it?

[matthew180]

There is some logic actually.

 

The B instruction can use any of the addressing modes for its 1 and only argument. The jump instructions only accept an offset. But the other part is the assembler. When the assembler sees a label by itself, it replaces the label with a number (the address at that label), and in the case of the jump instructions, it calculates the offset for us.

 

The @ symbol informs the assembler of two things:

 

1. How to encode the opcode.

2. What address to use for the symbolic addressing.

 

This is where the 9900 datasheet or quick reference sheet comes in handy over the E/A manual. Any instructions that indicate a Ts,S or Td,D for the source or destination can use all the addressing modes, and that would mean using the @ symbol with a label.

 

The Ts,S and Td,D are encoded like this (B instruction shown here):

 0   1   2   3   4   5   6   7   8   9   10  11  12  13  14  15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 1 |   Ts  |       S       |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

Ts indicates the addressing mode, and S determines the destination, which can be a register or if symbolic addressing is being used (in which case the value of S is zero), the CPU uses the word in memory immediately following the instruction as the 16-bit address to use.

 

For the jump instructions, the label is converted to an offset and encoded right in with the instruction.

 

Clear as mud, right?

 

Matthew

Edited June 6, 2010 by matthew180

[Willsy]

Actually, yes, that does make sense! Thanks!

[Opry99er]

I don't know if this one has been previously stated, but...

 

*"I changed the value to the new necessary value... why isn't it doing what it's supposed to?!! Oh..... That wasn't a value... that was a freakin address!"

 

Probably just a noob thing... but damn. Ate me up for 2 hours last night. =)

[Gary from OPA]

Neat topic, I should add to it, if I can remember my mistakes from when I first started.

 

But I do have a list of OFFICIAL MISTAKES, ones that TI themselves made in various modules,

and even in the OS, some of them don't matter because of the TI hardware, but others were even

noted in sidebar of TI docs, and then had work arounds, or had been quickly fixed in later

production runs.

[Opry99er]

Yea--- I have to say that I have fallen into most of these pitfalls listed above already (save the obscure ones) and this is only my first assembly project. I promise, if there is a mistake to be made, I'm gonna make it.

[marc.hull]

Hmmmmmmmmmmmm. This bit my ass for a couple days and cause some heated words and a drywall hole or two How about figuring Hex on your fingers for and ANDI, scratching you ass for a day or two wondering how this little piece of AND and SHIfT could not be correct only to find that your Hex digit (pun intended) was off by one....

 

I have a project for some hardy fool... How about a decimal to hex converter that lurks somewhere in memory until a load switch or some other interrupt is given at which time it pop's up on the TI screen for instant conversion. You would be my personal hero whoever you are...

[marc.hull]

Neat topic, I should add to it, if I can remember my mistakes from when I first started.

 

But I do have a list of OFFICIAL MISTAKES, ones that TI themselves made in various modules,

and even in the OS, some of them don't matter because of the TI hardware, but others were even

noted in sidebar of TI docs, and then had work arounds, or had been quickly fixed in later

production runs.

 

 

Well...... let's here em Gary....