"Unknown Variable" error on Instruction names which are not meant to be variables

[ProxyPlayerHD]

I got a few instructions which use 3 Registers as a sort of index with offset. Registers C and D being combined into CD to form the base index, and Register B being added as the offset.

so my instruction to load from and address pointed by CD + B to some other address is:

LD (addr), (CDB)

and i also got some instructions that load from one address to another directly, which would be:

LD (addr), (addr)

and this must be why the assembler thinks that CDB is a variable, because it sees the second instruction as the correct one instead of checking if there is one with a more correct/relevant name.

and i cannot think of an elegant way to get rid of this.

i tried removing the brackets, i tried using different brackets, i tried adding characters inside CDB to make it not count as a variable, but nothing worked to tell the assembler "this is not a variable, it's text, search an instruction with exactly this text"

[hlorenzi]

Could you show me what your #cpudef looks like exactly? Are you using #tokendef for this?

This issue could have many causes, and the first thing that comes to mind is that you should usually define the register variants before the address variants -- it seems like you're already doing this, though?

I'll try to reproduce this later, too. It should be perfectly possible to do as you intended, but I'm not sure how you are implementing this register combination syntax. So your exact definitions should come in handy to sorting this out!

[ProxyPlayerHD]

my CPUDEF looks like this: https://pastebin.com/WtCsTrmv

i also tried to change the order so that the instructions in question come first but that didn't seem to change anything so i changed it back

here is also the program i tried it in. in case that helps understanding my mess:

[hlorenzi]

So, this problem appears to be caused by an ambiguity between lines 101 and 143 from your pastebin, as seen in this minimal example:

#cpudef
{
    ; line 101
    LD ({dest}), ({src}) -> 0b101 @ 0b101 @ 0b01 @ src[15:0] @ dest[15:0]

    ; line 143
    LD {dest}, (CDB)     -> 0b101 @ 0b111 @ 0b01 @ dest[15:0]
}

LD (0xffff), (CDB)

While ambiguities are usually solved by the order in which instructions are defined, in this case the current implementation will always choose Line 101 no matter the order. The decision tree looks like the following, in a simplified version:

      "LD"           # step 1
     /    \
  "("      {dest}    # step 2
   |         |
 {dest}     ","
   |         |
 "),("    "(CDB)"
   | 
 {src}
   |
  ")"

The branches are always considered left to right. Right now, you cannot reverse the order of the branches in this case by switching the order of the definitions. This is due to plaintext tokens always being considered before parameter slots (as in step 2 above), which is an artifact of the optimization structure used for matching.

Since it doesn't appear LD (0xffff), (CDB) should mean something any different from LD 0xffff, (CDB), based on your current #cpudef, you can use the latter form without any further modifications, and it should work.

Other approaches would include using a different plaintext token before the unparenthesized parameter, like LD #{dest}, (CDB), to balance out the decision tree.

I'll have to look into ways to make the decision tree respect the definition order in this case. I'll let you know when I get around to doing it!

[ProxyPlayerHD]

actually now that i see it. i made a mistake. all Instructions that use addresses should have parentheses around them, so

LD {dest}, (CDB)

is supposed to be

LD ({dest}), (CDB)

this means the order is queal on both sides until it reaches CDB.

i will fix this and see if it works. maybe this was just casued by that typo

EDIT: it was, the program compiled. well now i feel stupid.

[ProxyPlayerHD]

well i think it's time to close this one, seeing as it has been solved byfixing a typo.

[hlorenzi]

Oh, sorry! I was actually waiting to close this after a fix to the unbalanced token decision tree I talked about in the previous comment. But I'm glad you were able to work around your issue!

[ProxyPlayerHD]

no problem.
though one question, can constants and specific variables be used in instruction definitions?
like if i want to impliment a relative jump

JR {dest} -> 0x0F @ dest - pc

example:

#addr 0x56A0
JR Test
NOP
NOP
Test:
NOP

would turn into:

0x56A0: 0x0F 0x04
0x56A2: 0x00
0x56A3: 0x00
0x56A4: 0x00

would this work to give me the relative address from the instruction's location to the address/label it should jump to? (and also stay within the bounds of a specific bit width)