Controlling DASM/Stella Variable Labels when variables overlap

[+splendidnut]

Currently I'm working on completely rewriting the burger logic code in Chaotic Grill.  I've run into an issue where the variable labels in Stella don't match the variables defined in a DASM  "SEG.U vars" set.  At first I thought it was a bug in Stella, but then I realized that my new title screen variables overlap with the main game variables and are defined later in the code base, which probably causes the issue. 

 

The main game variables are:

    - defined in a SEG.U vars segment

    - defined as:

        chefState ds 1

     OR

        enemyY  ds 4

 

The title screen variables are:

   - defined after the main game variables

   - defined outside the SEG.U segment

   - defined as

         chefState = $87

 

Now I realize I'm might be shooting myself in the foot by using two different methods to define variables... but I've only recently switched to using SEG.U with the main game variables and haven't gotten around to cleaning up the other areas of code that define their own variables.

 

What are my options for "forcing" Stella to use a certain set of variable labels?

 

Currently I'm just using the DASM built lst/sym files.

[Thomas Jentzsch]

There are no such options. Also, you should cleanup ASAP, the risk you already recognized is very high.

 

I suggest defining an area for temporary/local variables (e.g. tmpVar ds 10) and then do e.g. chefState = tmpVars + 2.

[+splendidnut]

Well, that's a bit disappointing.  That really limits the usefulness of the variable labels in the Stella debugger. 

 

Taking a closer look, I'm now noticing that I've lost a bunch of variable labels in Stella by using "ds" instead of "=".  So I'll have to move away from "enemyY ds 4" back to "enemyY1 = $88", "enemyY2 = $89"... and do my meticulous manual variable tracking again (not really that big of a deal).  At least then, all zeropage RAM locations will have a label, even if it's not the correct one.  Switching back to the old way of doing things will let me use the variable definition file itself as a reference as to where the variables reside in RAM.  For module local/temp variables, they're already defined in a specific area of memory.

 

This isn't too much of a big deal, as that's the way I was originally doing things. I was just hoping there was an easy way to tell Stella, "Here's the variable label list I want you to use".

 

As for cleanup of other code areas, I was looking to avoid that until I finished up with these rewrites.  For the most part, my code is not that much of a mess... that chef var name was just a quick and dirty example I could use... and it was the one that made me start to question things.  In the actual code, I have playerState (main game var) and chefState (title screen var) as the two labels.  So I just confused myself by not denoting that chefState is the name used only in the titlescreen (i.e.  named ts_chefState instead).  At the very least, I will go thru and change that stuff now.

 

 

Thanks for the quick response Thomas!

[Thomas Jentzsch]

9 minutes ago, splendidnut said:

Well, that's a bit disappointing.  That really limits the usefulness of the variable labels in the Stella debugger. 

How should that work?

[+stephena]

The parser that Stella uses for reading DASM symbol and list files is due for a rewrite.  There is already an issue created for this, and we hope to revisit it at some point.

 

Going forward, it might mean extending DASM itself to output those files in a more helpful manner (so emulators can make better use of the info), or perhaps integrating the parser from DASM directly into Stella.  As with everything else, the issue list is long, and time/help to do it is short.

[+splendidnut]

That's a good question.  I've just gotten thru converting my variables back to using "var = $80" style and now I've got back all the variable names I want showing in the Debugger.  So it seems Stella currently ONLY uses "=" labels for the RAM labels and generally the first ones it finds.  So I would start by adding support for "ds" style variables.  Then, being as variables should be defined in SEG.U name, couldn't you use the name to select which group of labels to show?

 

I know that's an overly simplified approach.  I'm not sure how others define their variables and constants.

 

Before I asked my question originally, I had some weird ideas about doing some "hacky" things like figuring out a way to assemble my variable definition file and then somehow import the resulting sym/lst into Stella separately... That didn't sound like a great idea so I started this thread instead.

[+splendidnut]

Thinking a bit more on this, I think this is a bit more complicated than I originally thought.  There seems to be no easy way to differentiate between variables and constants in DASM.  Unless, of course, I'm missing something...

 

...

 

I've thought about helping out with Stella, but I would first need to figure out how to get it to compile on Windows using CLion (JetBrains product for C/C++ development).   I started playing around with that a bit this weekend, but it looks like I would have to dedicate quite a bit of time to get Stella to compile with my preferred toolchain (mingw/cmake).  I'd like to avoid having to setup another IDE/build environment. 

[RevEng]

2 hours ago, splendidnut said:

Thinking a bit more on this, I think this is a bit more complicated than I originally thought.  There seems to be no easy way to differentiate between variables and constants in DASM.  Unless, of course, I'm missing something...

They're all just symbols to dasm, no difference.

 

The only way I see this being done in a useful fashion, is for Stella to parse dasm list files instead, but that's a lot more complicated.

[Thomas Jentzsch]

1 hour ago, RevEng said:

They're all just symbols to dasm, no difference.

Correct. Even the TIA register names are just symbols. But since they are known, they are handled separately in DiStella and Stella.

Edited August 10, 2020 by Thomas Jentzsch

[+splendidnut]

2 hours ago, RevEng said:

 

The only way I see this being done in a useful fashion, is for Stella to parse dasm list files instead, but that's a lot more complicated.

 

Hmmm... an idea comes to mind:  Wouldn't the better approach would be to have DASM itself analyze the use cases and create a more robust symbol file that can denote const vs var?  For starters, labels could be considered constants if they are only used in immediate mode instructions.

 

...

 

I have a big interest in getting this all figured out... I have a compiler I've been developing that outputs DASM-based assembly files and also it's own version of a symbol map file.  It'd be cool if I could find a way to interface that nicely with Stella.

[RevEng]

1 hour ago, splendidnut said:

Hmmm... an idea comes to mind:  Wouldn't the better approach would be to have DASM itself analyze the use cases and create a more robust symbol file that can denote const vs var?  For starters, labels could be considered constants if they are only used in immediate mode instructions.

I don't think adding inherent types to the symbols would make dasm generally robust, except for this specific purpose. In the case of symbol addition for an address, it becomes very fuzzy which component is a constant vs var. Then consider the case of reusing memory with different names, in different scopes of your program. I'm sure there are other cases I'm not considering here.

 

I'm in the camp that the dev tools should be kept as simple as possible, but no simpler. If "const vs var" distinction is really required, the dev can stick to a naming convention. But it would still be superior to interpret the list file, because assemble-time calculations like "lda SYMBOL+4" would be preserved, and where memory is reused it would capture which name you used for a particular scope.

[+splendidnut]

I kind of knew coming here with this problem that I'd be opening a can of worms. 

 

My original goal of this thread was to be able to have Stella use the appropriate labels for memory locations in the debugger.  Currently, some of the locations end up with the names of constants instead of vars.  I'm not sure why that is.... Eventhough I've defined all variables first, I have at least one memory location that is labeled with the name of a CONSTANT that's not even defined until the middle of the ChaoticGrill code base.  It things like that which cause problems when trying to debug things.  So I've tried to change the way I define variables to something which seems more appropriate, but that ended up exasperating the problem.  So instead of doing things smarter, I had to revert to a "hacky" way of defining variables:  one by one using specifically assigned memory locations.

 

I understand the point of view that dev tools should be kept as simple as possible/no simpler than that.  They also should serve the developer and also interface nicely with the rest of the world where/when possible.  I already use naming conventions to differentiate between constants and variables, but that doesn't solve the problem that Stella doesn't know which is which.  My personal feeling on this is that type information should be in the symbol file.  Stella really isn't the one who should be figuring out that information, it should just need to understand an input file.... Unless, of course, you want to turn Stella into a complete development environment.... which I'm not opposed to since I currently have to bounce between three different windows to develop, build, and run.

 

For right now, the best solution seems to be:  physically make and print out a memory map of the variables if I want them to be completely correct.

[RevEng]

Just adding my 2 cents. I'm by no means a gatekeeper, nor would I pretend to be, and there are other dasm developers here.

 

Ultimately if I thought the additional complexity was worth the trade-off in benefit, I'd be in your camp. But I really only see this as befitting one use case, and for that one use case it seems that it would do the job badly. It would certainly fail on a high percentage of my code, because I often use address expressions, I use repeats for unrolled loops, and when I'm not being lazy I like to rename temp variables for local scope.

[+splendidnut]

Ok, fair enough.  I'll have to explore my ideas on my own.  Thank you.

[+stephena]

This has already been mentioned above.  Stella already does read symbol and list files from DASM; it's just that it could do it a little better.  And in the longer term, maybe DASM could also be extended to output more metadata to make it easier for Stella to use that info.

[RevEng]

Totally missed your mention of list files the first time around. Thanks for the correction. ?

[RevEng]

13 hours ago, stephena said:

 And in the longer term, maybe DASM could also be extended to output more metadata to make it easier for Stella to use that info.

I had a look at the list file generation routine. Generally speaking, the format could be easily tweaked, though it obviously depends on what metadata you're talking about. Depending on what you have in mind, a "listfile format" argument could be added, with options for traditional format (default) or a new machine parsable format (e.g. with field separators, rather than relying on character column positions) and whatever other stuff you may have in mind.

 

When you're next taking on this problem space in Stella, let me know what your wish list for the list format would be.

[Thomas Jentzsch]

We already requested a pseudo op which defines a new bank.

[RevEng]

The "bank" pseudo-op proposed was literally just to generate a symbol, the same as your asm code could, with the only distinction between the two methods being the bank pseudo-op would generate a "standardized" name. I don't agree that pseudo ops are the right place to enforce use-case specific symbol names. If you extrapolate, we will start to have 7800 specific pseudo-ops, c64 specific pseudo ops, etc., ... . When the alternative is to just make your own standard by saying "hey, you need to define bank symbols this way to get more benefit from stella's distella" it doesn't seem like a win to have platform-specific narrow use-case pseudo-ops added to dasm.

 

If your manually generated bank symbols are integrated into some wip version of stella and it's giving you all of the syntax you desire to solve this problem, I'll put the new pseudo-op to a vote with the dasm team, and be happy to be overridden. (well, maybe not happy, but fine with it) If this request isn't the end of the wish list, it might be better to look at all of your requirements together, rather than piecemeal. It could well be than an improved list format is the only requirement, and we don't need to add psuedo-ops. Or not. But I'm just asking for the solution to planned and thought-out, instead of ad-hoc and incremental.

[+Karl G]

Poking my head in this discussion ... I've also had issues with debugging due to overlapping symbol names. Given the way dasm / Stella work now, what is the best way to go about defining symbols that act as my variable names so that Stella uses them in preference to constants or other labels? I need a better understanding of how it picks which symbol to display in the debugger. What do the rest of you do, or do you even do anything differently to allow for easier debugging in Stella?

[Thomas Jentzsch]

Stella takes the labels from the .sym file. They are either sorted by DASM either alphabetically or by value.

 

Stella it knows the TIA and RIOT values, so these should be always used. I haven't looked into the code, but it seems that Stella uses the first match for all other values.

 

I never tried to optimize my code for Stella. Maybe the alphabetically sorting can be used to improve here, but this is only a work around.

[+stephena]

On 8/11/2020 at 1:45 PM, RevEng said:

But I'm just asking for the solution to planned and thought-out, instead of ad-hoc and incremental.

Yes, I agree.  And that's why we haven't had time to revisit it yet.  I want to do it once, and do it right, and not come back to it by doing it in pieces.  And that requires dedicating time and communication to the issue that I don't have right now.

14 minutes ago, Thomas Jentzsch said:

I never tried to optimize my code for Stella. Maybe the alphabetically sorting can be used to improve here, but this is only a work around.

I agree.  Optimizing your code for Stella is not the right thing to do, since the tools are supposed to work for you, not the other way around.  We will hopefully fix this eventually, properly, in Stella and DASM.

[+splendidnut]

Since someone else has run into a similar issue, I figured I would share an idea I had:

 

DASM could be changed to allow the programmer to differentiate between symbols that are variables, constants, or code labels with the 'segments' feature.  The name of the segment could be added as a column to the symbol file.  Stella could then use that information and have a couple of dropdowns to select which segment symbol lists to use for labels in the RAM and ROM areas.

 

This could potentially be a nice solution for:

  - differentiating between consts and variables.

  - multiple banks of variables

  - multiple ROM banks

 

I'd look into doing the work myself, but I've got too many other things going on right now.

[Thomas Jentzsch]

That's a good idea. If this would be added to DASM, Stella would be updated immediately.

Edited January 17, 2022 by Thomas Jentzsch