DASM weird label syntax

[RevEng]

I was running through the dasm label parsing code, as part of my update for dynamic-label generation, when I noticed that this is an alternate valid dasm label syntax...

    ^     mylabel

...you can put any number of spaces before or after the ^ character.

 

Anybody know the historic lineage of this label syntax? Just curious about this oddity. I expect it's from from one of the other supported targets, but perhaps it was inspired from some other source.

[RevEng]

Can't seem to find evidence that this label convention was used historically with any of the supported target CPUs, or anywhere else for that matter. Very strange.

[+splendidnut]

I found that syntax a while ago too... when I was looking at the DASM source code to see what it would take to:

  * Fix the issue that labels can't have whitespace at the start of the line

  * Fix the issue that cpu instructions and psuedo ops REQUIRE space at the beginning of the line (not that much of an issue)

 

If there is no need/historical use for the '^' trick, my personal opinion is that it should be removed.  I think it would help alleviate some of the weirdness of the line parser.

[RevEng]

I agree that if there's no actual usage or need for any particular feature, it should go away. I don't think this syntax is interfering with any parsing presently, so I'd need to know there's no historic context, or some body of existing source that relies on it. Despite being one of the main hands in the current dasm source, I don't have a lot of visibility into usage by non-6502-target and non-atari platforms, so I try to have a very light hand.

 

Your reply inspired me to do some archaeology. It looks like this wasn't a part of Dillon dasm, but was added by Olaf Seibert. (aka Rhialto) Originally it was conditional code, if "OlafHashFormat" was defined. In some later version, the conditions were stripped away and the code was incorporated officially.

 

My understanding is the main thrust of OlafHashFormat was to add support for hash marks in front of dasm conditionals, so they could be used without whitespace. That's clearly been adopted and used. I'm not so sure about the "^" labels, which apparently came in the same door. I'll reach out to Rhialto, and share what I find here.

[RevEng]

I sent out a feeler to Rhialto.

 

I did a bit more archaeology, this time on the dasm.txt doc. This label syntax was documented in Rhialto's tree, and I see the same in Andrew's tree too. I'm guessing after that someone merged trees, but missed merging the updates to dasm.txt.

[+splendidnut]

 

1 hour ago, RevEng said:

I don't think this syntax is interfering with any parsing presently, so I'd need to know there's no historic context, or some body of existing source that relies on it. Despite being one of the main hands in the current dasm source, I don't have a lot of visibility into usage by non-6502-target and non-atari platforms, so I try to have a very light hand.

 

Your reply inspired me to do some archaeology. It looks like this wasn't a part of Dillon dasm, but was added by Olaf Seibert. (aka Rhialto) Originally it was conditional code, if "OlafHashFormat" was defined. In some later version, the conditions were stripped away and the code was incorporated officially.

 

My understanding is the main thrust of OlafHashFormat was to add support for hash marks in front of dasm conditionals, so they could be used without whitespace. That's clearly been adopted and used. I'm not so sure about the "^" labels, which apparently came in the same door. I'll reach out to Rhialto, and share what I find here.

 

Yeah, it doesn't really interfere with the current parsing... but it did seem to interfere when I started playing around with simplifying the parser to take care of the whitespace issue.  I kind of dropped playing around with the DASM source code because of this.  I feared I wouldn't use a light hand and would have ended up with my own separate fork or my own personal version.  I figured that I was used to working around the whitespace issue so in the end it's really not a big deal.

 

Always interesting to dig into the history of projects like this.  I'm wondering if he (Olaf) had a specific use for it, like maybe interfacing to some external piece of software.  I'm also wondering if he'll point to this as more of a reason to have merged the code bases in his suggested way:  https://github.com/dasm-assembler/dasm/issues/20

 

Thanks for looking into this.  It'll be interesting to see if/when/how Olaf responds.

 

 

[Rhialto]

Ha! You're asking me to remember something from decades ago!

I have been pondering it a bit. My best current guess at my reasoning about the "^ label" syntax is that it forms some sort of symmetry with the "#directive" syntax. There is a possibility that somebody suggested that such symmetry was lacking, but it could have been my own idea. I am totally not sure on that point.

I am fairly certain that I didn't invent this to conform to some sort of external existing source files or anything like that. I also don't think I used it much myself other than test cases.

As to why in particular I chose the "^" symbol, I would currently guess that the "^" in regular expressions indicated "match only at the beginning of a line", and here it has the similar meaning "pretend that the next thing is at the beginning of the line" (being the opposite of "pretend that the next thing is NOT at the beginning of the line").

[RevEng]

Decades ago, but the information you've provided is completely satisfying for me; it clears up that it was an invention, rather than something historic. The speculation for using "^" is the cherry on top.

 

Thanks for illuminating this for us!

 

[edit] I said it privately when I reached out, but it bears repeating publicly - thanks for your historic contributions to dasm!

[+Andrew Davie]

On 4/26/2020 at 2:50 AM, RevEng said:

I sent out a feeler to Rhialto.

 

I did a bit more archaeology, this time on the dasm.txt doc. This label syntax was documented in Rhialto's tree, and I see the same in Andrew's tree too. I'm guessing after that someone merged trees, but missed merging the updates to dasm.txt.

 

Thank god for that. I have a bit of a complex with the changes I adopted/made, and the modifications in my curation of the assembler.

 

[RevEng]

1 hour ago, Andrew Davie said:

Thank god for that. I have a bit of a complex with the changes I adopted/made, and the modifications in my curation of the assembler.

I understand (hence the light-hand discussion) but missing the doc update in a tree merge is completely understandable, whoever's watch it happened under. Any oopses or bugs that may have been introduced along the way are overwhelmingly outweighed by the good the historic maintainers brought to the tool. Gotta break a few eggs to make an omelette.

[+Andrew Davie]

Just now, RevEng said:

I understand (hence the light-hand discussion) but missing the doc update in a merge is completely understandable, whoever's watch it happened under. Any oopses or bugs that may have been introduced along the way are completely outweighed by the good the historic maintainers brought to the tool. Gotta break a few eggs to make an omelette.

... and I'm loving the care and attention begin given to the tool by the new generation.