Gotchas: Difference between revisions

===Numeric Literals===

Integer literals used in instruction operands need to begin with a #, otherwise, the CPU considers them to be a pointer to memory. This applies to any integer representation, even ASCII.

OR 3 ;bitwise OR the accumulator with the 8-bit value stored at memory address 0x0003

 

 

 

However, data blocks do ''not'' get the # treatment:

 

 

 

 

Some examples of bad memory-mapped port I/O for various hardware:

 

===Inverted Carry===

The carry flag is "backwards" compared to most languages with regard to comparisons and subtractions.

On most CPUs, carry set is used to mean "less than", and carry clear is used to mean "greater than or equal." The 6502 is the opposite!

CMP #$19

 

Not only that, carry clear indicates a borrow when subtracting. This is also the opposite to most CPUs. To do a normal subtraction you need to ''set'' the carry before subtracting.

SEC

 

===Carry===

 

Therefore, any time you want to add two numbers without involving the carry flag you have to do this:

 

Failure to correctly use the carry flag can often result in unexpected "off-by-one" errors.

* When using <code>$nn,x</code> or <code>$nn,y</code>, if <code>$nn + x</code> or <code>$nn + y</code> exceeds 255, the instruction will wrap around back to $00 rather than advancing to $0100. For a more concrete example:

 

 

In other words, ''an indexed zero page addressing mode cannot exit the zero page.''

 

It should be noted that the above bug does '''not''' apply to indexed absolute addressing.

 

This also happens with the indirect JMP operation, which jumps to the 16-bit address stored at the specified address.

STA $3000

LDA #$40

STA $3001

 

The following will '''not''' execute in the way you expect, because this instruction has a similar bug where it doesn't advance to the next page when calculating the address.

STA $30FF

LDA #$40

STA $3100

 

As long as you don't put a number that looks like <code>$nnFF</code> in the parentheses as shown above, you can avoid this bug entirely.

===Numeric Literals===

Integer literals used in instruction operands need to begin with a #, otherwise, the CPU considers them to be a pointer to memory. This applies to any integer representation, even ASCII.

 

However, data blocks do ''not'' get the # treatment:

 

 

===LEA Does Not Dereference===

When dereferencing a pointer, it is necessary to use parentheses. For these examples,

MOVE.L A0,D0 ;move the quantity $A04000 into D0

MOVE.B (A0),D0 ;get the 8-bit value stored at memory address $A04000, and store it into the lowest byte of D0.

 

However, the <code>LEA</code> instruction (load effective address) uses this parentheses syntax, but ''does not dereference!'' For extra weirdness, you don't put a # in front of a literal operand either.

 

 

===Partitioned Registers===

One key feature of the 68000 is that its instructions can operate at different "lengths" (8-bit, 16-bit, or 32-bit). When performing an operation at the "word length" (16-bit), only the least significant 16 bits are affected, and the rest of the register is ignored. The flags also only reflect the result of the calculation with respect to the instruction's "length", not the entire register. For example:

 

MOVE.W #$7FFF,D0 ;D0 = $12347FFF

ADD.W #1,D0 ;D0 = $12348000

TRAPV ;the above operation set the overflow flag, so this instruction will call the signed overflow handler.

 

As implied by the previous example, loading a value at a length less than 32 bits into a register will leave the "high bits" the same. This can often cause subtle errors that lead to your program failing unexpectedly.

 

forloop:

; loop body goes here

 

The above code is flawed in that <code>DBRA</code> (and its cousins) ''operate at word length.'' Given that, and the fact that we only loaded the loop counter at byte length, the loop will execute <code>$nn10</code> times instead of the intended <code>$10</code> times, where <code>$nn</code> is the prior value of the register being used as the loop counter.

===Automatic Sign-Extension===

When moving values into ''address registers at word length'', the value is sign-extended first.

 

There is no sign-extension when moving values into data registers.

 

If you want sign-extension on data registers, you'll need to do it manually:

EXT.W D0 ;D0 = $????FFFF

 

MOVE.L #$8000,D1

 

=={{header|MIPS Assembly}}==

Due to the way MIPS's instruction pipeline works, an instruction placed after a branch instruction is executed during the branch, ''even if the branch is taken.''

 

beqz $t0,myLabel ;branch if $t0 equals 0

 

Now, you may think that the 1 gets added first and therefore the branch doesn't take place since the conditions are no longer true. However, this is '''not the case.''' The condition is already "locked in" by the time <code>addiu $t0,1</code> finishes. If you compared again immediately upon arriving at <code>myLabel</code>, the condition would be false.

On earlier versions of MIPS, this also happened when loading from memory. The register you loaded into wouldn't have the new value during the instruction after the load. This "load delay slot" doesn't exist on MIPS III (which the Nintendo 64 uses) but it does exist on the PlayStation 1.

 

lw $t0,($a0) ;load the 32-bit value at memory address 0xDEADBEEF

 

Like with branches, putting a <code>NOP</code> after a load will solve this problem.

Issues with array rank and type should perhaps be classified as gotchas. J's display forms are not serialized forms and thus different results can look the same.

 

ex2=: '1 2 3 4 5'

ex1

11 12 13 14 15

10+ex2

 

Also, constant values with a single element are "rank 0" arrays (they have zero dimensions) while constant values with some other count of elements are "rank 1" arrays (they have one dimension -- the count of their elements -- they are lists).

Another gotcha with J has to do with function composition and J's concept of "[[wp:Rank_(J_programming_language)|rank]]". Many operations, such as <code>+</code> are defined on individual numbers and J automatically maps these over larger collections of numbers. And, this is significant when composing functions. So, a variety of J's function composition operators come in pairs. One member of the pair composes at the rank of the initial function, the other member of the pair composes at the rank of the entire collection. Picking the wrong compose operation can be confusing for beginners.

 

5 7 9

+/ 1 2 3 + 4 5 6

21

1 2 3 +/@+ 4 5 6

 

Here, we are adding to lists and then (after the first sentence) summing the result. But as you can see in the last sentence, summing the individual numbers by themselves doesn't accomplish anything useful.

Perl has lists (which are data, and ephemeral) and arrays (which are data structures, and persistent), distinct entities but tending to be thought of as inter-changable. Combine this with the idea of <i>context</i>, which can be 'scalar' or 'list', and the results might not be as expected. Consider the handling of results from a subroutine, in a scalar context:

 

sub list1 { return qw{ 1 2 3 } }

 

 

say scalar array2(); # prints '3', number of elements in array

 

The behavior is documented, but does provide an evergreen topic for SO questions and blog posts.

<br>

Forward calls may thwart constant setup, eg:

<span style="color: #008080;">forward</span> <span style="color: #008080;">procedure</span> <span style="color: #000000;">p</span><span style="color: #0000FF;">()</span>

<span style="color: #000000;">p</span><span style="color: #0000FF;">()</span>

<span style="color: #0000FF;">?</span><span style="color: #000000;">hello</span> <span style="color: #000080;font-style:italic;">-- fatal error: hello has not been assigned a value</span>

<span style="color: #008080;">end</span> <span style="color: #008080;">procedure</span>

Not a problem if the first executed statement in your program is a final main(), or more accurately not a problem after such a last statement has been reached.<br>

Quite a few of the standard builtins avoid a similar issue, at the cost of things not officially being "constant" anymore, using a simple flag and setup routine.

strings may be used almost interchangeably in most cases.

 

say "12" + "5.7"; # add two numeric strings together

 

<pre>123456

each object are within. Works great for strings.

 

say $bag{'a'}; # a count?

 

<pre>Bag(a(3) b(2) c d)

But numerics can present unobvious problems.

 

say $bag{ 1 }; # how many 1s?

say $bag{'1'}; # wait, how many?

say $bag< 1 >; # WAT

 

<pre>Bag(1 1(2) 1(3))

and we want to print the contents to the console.

 

 

<pre>(1,2,3)

flatten the object due to the single argument rule.

 

 

<pre>1

like multiple object parameters even if there is only one. (Note the trailing comma after the list.)

 

 

<pre>(1,2,3)</pre>

Conversely, if we want the flattening behavior when passing multiple objects, we need to manually, explicitly flatten the objects.

 

 

<pre>1

 

I've tried to construct an example below which illustrates these pitfalls.

construct new(width, height) {

// Create two fields.

System.print(rect.area) // runtime error: Null does not implement *(_)

System.print(rect.diagonal) // runtime error (if previous line commented out)

 

=={{header|X86 Assembly}}==

===Don't use LOOP===

This doesn't affect the 16-bit 8086, but <code>LOOP</code> has some quirks where it's slower than:

;loop body goes here

DEC ECX

 

Which is very ironic considering that <code>LOOP</code> was originally designed to be a more efficient version of the above construct. (It was more efficient in the original 8086, but not in today's version.) Thankfully, compilers are "aware" of this and don't use <code>LOOP</code>.

===JP (HL) Does Not Dereference===

For every other instruction, parentheses indicate a dereference of a pointer.

LD A,(HL) ;treating the value in HL as a memory address, load the byte at that address into A.

EX (SP),HL ;exchange HL with the top two bytes of the stack.

 

 

This syntax is misleading since nothing is being dereferenced. For example, if HL equals &8000, then <code>JP (HL)</code> effectively becomes <code>JP &8000</code>. It doesn't matter what bytes are stored at &8000-&8001. In other words, <code>JP (HL)</code> ''does not dereference.''

Depending on how the Z80 is wired, ports can be either 8-bit or 16-bit. This creates somewhat confusing syntax with the <code>IN</code> and <code>OUT</code> commands. A system with 16-bit ports will use <code>BC</code> even though the assembler syntax doesn't change. Luckily, this isn't something that's going to change at runtime. The documentation will tell you how to use your ports.

 

ld bc,&0734

 

Unfortunately, this means that instructions like <code>OTIR</code> and <code>INIR</code> aren't always useful, since the B register is performing double duty as the high byte of the port and the loop counter. Which means that your port destination on systems with 16-bit ports is constantly moving! Not good!

===RET/RETI/RETN===

Here's one I didn't learn until recently. Depending on the wiring, <code>RETI</code> (return and enable interrupts) and <code>RETN</code> (return from Non-Maskable Interrupt) may end up functioning the same as a normal <code>RET</code>. This means that sometimes you have to use the following (which just makes anyone else reading your code think that you don't know what <code>RETI</code> does.)

 

Fortunately, there's a bit of a "reverse gotcha" that helps us out. When interrupts are enabled with <code>EI</code>, there is no chance that an interrupt will occur during the next instruction. <code>EI</code> doesn't actually enable interrupts until the instruction ''after'' it is finished.