[CSDb] - User Forums - Kickassembler

You are not logged in - nap

CSDb User Forums

Forums > C64 Coding > Kickassembler - Parsing issue

2023-01-05 12:39

TWW

Registered: Jul 2009
Posts: 541

Kickassembler - Parsing issue

Kickass V5.25;

This:

    .function reldist(val1,val2) {
	.return val1-val2
    }

    :BasicUpstart2(Main)

    .pc = $1000 "Main"
Main:
    .print reldist(Main,BranchTo)
    nop
BranchTo:
    rts

Produces:

Output pass
  -1

Once I try to do this within a pseudo:

    .pseudocommand bra val1:val2 {
        .if(val1.getValue()<val2.getValue()) {
            .print "abc"
        }
    }

    :BasicUpstart2(Main)

    .pc = $1000 "Main"
Main:
    bra reldist(Main,BranchTo)
    nop
BranchTo:
    rts

Produces:

flex pass 1
    //-----------------------------------------------------

    .pseudocommand bra val1:val2 {
  .if(val1.getValue()<val2.getValue()) {
  ^

Error: The condition must be able to evaluate in first parse
at line 6, column 3 in Testing.asm
called at line 20, column 2 in Testing.asm

Any suggestions on how I can get around this?

2023-01-05 19:58

Oswald

Registered: Apr 2002
Posts: 5017

bra reldist(Main,BranchTo)

in 2nd case you dont have the reldist function? shouldnt it be just bra (Main,BranchTo) ?

edit: also once you use val.getvalue and once just val to get the value. (no idea if it should be different because of pseudocommand or not)

2023-01-05 22:13

CyberBrain
Administrator

Posts: 392

There is actually one more difference between your two examples. Your second example uses an ".if" statement with a forward-referenced label in its expression (indirectly), and that's what's causing the error.
So a simplified example causing the same error would be:

    label1:

    .if (label1 < label2)
        .print "abc"

    label2:

As i understand it: Kickass's scripting language executes the code in the file(s) from top to bottom, like a normal programming language.
It does multiple passes, to account for forward-referenced labels, but all variables used in .if/.for/etc-expressions must have been resolved in the first pass, at the point the scripting engine encounters the .if/.for/etc.
In the example above, the value of "label2" is still unresolved in pass 1, when the ".if" is executed. (Label2 has the value "unresolved"/"undefined" at this point (*) - it's not assigned its real value until after the ".if". You can use .printnow to see its value at a certain point in each pass.)

So to solve it, you have to restructure the code so that both labels are before the .if:

    label1:
    label2:

    .if (label1 < label2)
        .print "abc"

I think this is the only solution. (Apart from solving the problem in another way)

I guess, loosely speaking, you can think of it as statements which CAN (but not necessarily do!) generate a different number of bytes based on some expression, must have all variables used in that expression resolved in the first pass (this is the case for .if/.for/etc). But otherwise, it's fine to use variables that aren't resolved until a later pass. (Like in "lda #label2 - label1" which always generates 2 bytes).

It would of course be very nice if it was possible - but i guess the assembler could end up doing infinite number of passes, in some cases, if some labels never stabilized but kept changing their value in every pass, for example due to multiple .if-statements working against eachother... In some situations i think it would be nice to be able to have a built-in isUnresolved(exp)-function, or something like that, to check if a value is unresolved in pass 1, though.

(This is only directly an issue for labels, as they are the only variables (well, constants really) that can be used before they're declared - but if you use labels in expressions or assign labels to normal variables, those will be affected too (they'll also get the "unresolved" value in early passes). Like in your second example, where the pseudocommand-parameter's value is "unresolved" in pass 1 - which would have been fine, if it hadn't been used in an ".if")

(*) Much like "undefined" in JS. Well, the "unresolved" value, is actually called "<<Invalid Number>>" in kickass but you get the point.

</end of spam>

2023-01-06 07:30

TWW

Registered: Jul 2009
Posts: 541

@ Oswald: The funtion was just to show what I was trying to do and was not supposed to be used in the .pseudo (although I did try it to see if it could be a workaround but alas). The .getValue() is how you fetch values from command arguments passed to a pseudo (you could also get type (immediate, abs. etc.).

@Cyberbrain: Yes, this is how it works and the ".if" vs. unresolved labels is the issue.

I have the same challenge with segments and labels.

The only way I found thus far to get around it is to instead of using labels, use relative distanse by:

    bne *+3

However it would be nice if there was a way to force the assembler to run a pass or two to resolve labels...

2023-01-06 09:11

tlr

Registered: Sep 2003
Posts: 1714

Quoting CyberBrain

It would of course be very nice if it was possible - but i guess the assembler could end up doing infinite number of passes, in some cases, if some labels never stabilized but kept changing their value in every pass, for example due to multiple .if-statements working against eachother...

This probably already needs to be handled for instructions automatically switching between zp vs abs addressing if placed near the end of zp.

In my view forward references is something the assembler should allow liberally and if it doesn't converge it will error out on the iteration limit. It's the programmers responsibility to make it converge in a stable manner. Iterations will be quite quick in a modern AST based assembler anyway.

2023-01-06 12:24

Oswald

Registered: Apr 2002
Posts: 5017

my bad, I dont know kickass, just tried to look for problems in the syntax :)

2023-01-06 15:03

Frantic

Registered: Mar 2003
Posts: 1627

Quote: Quoting CyberBrain
It would of course be very nice if it was possible - but i guess the assembler could end up doing infinite number of passes, in some cases, if some labels never stabilized but kept changing their value in every pass, for example due to multiple .if-statements working against eachother...

This probably already needs to be handled for instructions automatically switching between zp vs abs addressing if placed near the end of zp.

In my view forward references is something the assembler should allow liberally and if it doesn't converge it will error out on the iteration limit. It's the programmers responsibility to make it converge in a stable manner. Iterations will be quite quick in a modern AST based assembler anyway.

Yes, absolutely. My favourite in this regard was some gameboy assembler that I forgot the name of (RGBDS?). It felt like it would just go ahead and resolve any crazy script/label construction that was resolvable. Maybe I romanticize, but at least that is how I remember it. Assemblers that are picky in this regard end up at the opposite end of the spectrum for me. Instant turn off.

Refresh

Subscribe to this thread: