#immediate - 'error' in parser

[andrew-davie]

Although this does not generate an error, I think it should. I have a double-# in the immediate....

;   immediate

    processor 6502
    org $1000

    lda ##0             ; should be an error?

Does not seem to complain, and binary is as expected. I'd prefer to see this flagged - but at the very least perhaps worth a check of the code to make sure it's not doing anything unexpected with this strange format.

[neilsf]

I noticed the same within macros, eg:

MAC border
lda #{1}
sta $d020
ENDM

border #1

The above works, although this syntax is indeed weird. However if it's a bug and is going to be fixed, users will have to update their old assembly code as well.

[msaarna]

That's a great point. For that reason I'd really rather see this as a warning, instead of an error.

[andrew-davie]

I would rather see errors treated as errors. I don't believe in perpetuating bugs for the sake of backward compatibility. Legacy code will still assemble with legacy assemblers. We don't see Python, for example, worrying about this sort of stuff. In this case it's an extremely simple fix for anyone who sees this flagged as an error. So, my preference/request is to fix it properly and not worry about the (incredibly rare) case where someone has erroneous source code from the past.

[dionoid]

I agree with Andrew on this one, as I think all syntax errors should be flagged as errors (which is common/expected behavior for compilers). And in case these syntax errors were generated by compilers such as SpiceC or bB, it shouldn't be hard to fix, right?

[msaarna]

None of the higher language tools generate this. The problem case is ## results from using #value as a macro argument, and #{} again within the macro. And again, I'm not aware of any of the higher language tools doing this either, so I have no skin in the game.

But It's a common enough user pattern, because they assume the dasm macros handling has more nuance than it actually does. They're following the rule "I should always use # when I mean a literal value", which would seem to be a reasonable, but it's "incorrect" for the actual macro copy-and-paste implementation.

IMO this is an edge case of "syntax error", and the chance that someone uses "##" literally and the lack of resulting harm from that slipping through, doesn't justify breaking real-world assembly. But if you guys feel it's more important to be rigorous, then go for it.

[neilsf]

I think throwing an error is only acceptable if it's introduced in a major version where users shouldn't expect BC anyway. IMO if it's introduced in a minor version, a deprecation notice should warn users about the fact that compilation will fail in a later version.

[andrew-davie]

That is a reasonable position, with which I mostly agree. The only caveat I'd add is that BC is not a holy grail. Correct assembly is.

[neilsf]

I agree but there can be situations (like mine) when assembly code is not written by users but generated by a higher level compiler that requires a little longer time to be corrected, released and upgraded on user machines.

I know it's very much a personal interest of mine. I'd be happy to correct my legacy code fast if I knew the deadline.

[neilsf]

You may also take the following into consideration. Here is an example macro that pushes a word on the stack. Now the same macro is used for pushing an immediate word or an address as well:

  PROCESSOR 6502
  ORG $c000

 ; Push a word on stack
  MAC pword
  lda #<{1}
  pha
  lda #>{1}
  pha
  ENDM

  ; The same macro works with an intermediate
  pword #13450

  ; But it works with an address as well
  ; label equals $c006
label:  
  pword label

Now I may be misusing DASM but it works perfectly in the current version regardless whether the {1} parameter is an immediate value or an address. If I removed the # from lda #<{1} the output would be an LDA $06 when calling pword label which is undesirable.

I know it's kind of an obscure assembly code but it works.

[neilsf]

Damn, I just realized that I can call the macro like this as well:

pword #label

Please ignore my above comment :-)

[andrew-davie]

The issue with your example is not about removing the "#" from within the macro. It is about removing it from the call to the macro. I don't think your usage is doing what you think it is doing.

In both cases, you get the hi/lo bytes of the passed value, no?

[andrew-davie]

Perhaps it would help to think of the macro processor as purely a text-substitution engine. Wherever you have {1}, put whatever you like. It comes down to "is lda ##something" valid and is changing it going to change any resultant code. And the answer I have to those is "no".

[neilsf]

Yeah I know that it's only text substitution and I am aware that I have been using it the wrong way. But since it worked I didn't care too much. There's no question that the legacy assembly code must be corrected, all I'm saying is that there should be a smooth transition from one state to another. Big ships turn slowly.

[Rhialto]

On Mon 09 Mar 2020 at 01:37:24 -0700, Csaba Fekete wrote:

You may also take the following into consideration. Here is an example macro that pushes a word on the stack. Now the same macro is used for pushing an immediate word or an address as well:

  PROCESSOR 6502
  ORG $c000

 ; Push a word on stack
  MAC pword
  lda #<{1}
  pha
  lda #>{1}
  pha
  ENDM

  ; The same macro works with an intermediate
  pword #13450

Here you can/should of course use

    pword 13450

-Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG"