"Unknown Variable" error on Instruction names which are not meant to be variables about customasm HOT 7 CLOSED

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!

from customasm.

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:

from customasm.

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!

from customasm.

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.

from customasm.

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

from customasm.

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!

from customasm.

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)

from customasm.