Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Memory Management
#12
boriel Wrote:
Darkstar Wrote:Also if you do:
Asm
ld e, (NN)
End asm

Then the assembler acctepts it and it is there in the generated ASM file and
when you compile it with zbasm it goes through without a hitch but as
there is no such instruction in the Z80A instruction set then the result is
garbage. That one can see in a debugger after the TAP file is loaded.
This is a matter of ambiguity: For the assembler (16384) is also an arithmetical expression. So the above is compiled to:
Code:
asm
ld e, NN
end asm
Since e is ubyte, the result is truncated to its lower byte. In this case, ld e,(16384) is assembled as ld e,0 (as Britlion pointed). This is rather problematic, because when you want to use parenthesis for an arithmetical expression with something like LD HL, (Mylabel + 3) it doesn't know whether you are referring to LD HL, [Mylabel + 3] or LD HL, Mylabel + 3. A rule of thumb: it will try always the 1st case and will fallback to the 2nd if the first is not possible (as it happened in the example above).

Pasmo already allows brackets [ ] for memory indirection. Zxbasm will also do (in the near future).

This is all fine and well but the instruction itself does not exist. In the thread
<!-- l --><a class="postlink-local" href="http://www.boriel.com/forum/how-to-tutorials/topic468-30.html#p1444">how-to-tutorials/topic468-30.html#p1444</a><!-- l --> Britlion posted on the string bug thread there was
a mention of doing variables FreeBasic style and then ld [e], (NN) could work
but as it stands...

For the record I was trying to do: "ld e, (23693)" and it produced ld e, 143
and some byte that I can't quite remember. Well, garbage in, garbage out in
the debugging window.

It's a work in progress Big Grin
Reply


Messages In This Thread

Forum Jump:


Users browsing this thread: 1 Guest(s)