This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Best way to organize labels, references, data groups, etc.?

Best way to organize labels, references, data groups, etc.?
by on (#62268)
Basically, this is an idea I have been floating around in my head for a while. A user through a GUI will be able to organize all the labels, equates, references, strings, data groups, data types, etc., used in a project into informational lists and when the time comes to disassemble, will be able to use the CDL file obtained from FCEUXD to do a disassembly, while entering all the labels and equates at proper places, entering the proper references, grouping together data in a manner defined by the user, etc.

It will work in a linear fashion, where the program will start at the beginning of the PRG, and will move along by PRG address, with the sorted by PRG address of insertion of lists of references, labels, etc., and doing the text file output line by line, moving from address to address.

I implemented this in a couple of C programs using a data storage type of INF0 called INF0EDIT (which edits the informational files to be used in the disassembly) and CDLDIS2 (named after CDLDIS from http://sm2.beneficii.net/ ). Unfortunately, I had to use different types with each type of data and there was no good way of organizing it, so I used a whole bunch of macros to come up with stock functions for each type and I had to treat each kind separately. I came up with a rudimentary way of of sorting, for example, 2 labels being put at the same address, but I'm not satisfied with that, especially with making the ordering at the same address user friendly in INF0EDIT.

Also, INF0EDIT was used with the command-line. You could construct an entire informational file with it, but it was better to create a tab-delimited text file with something like Excel to input it and create the informational file which would then be used with the disassembly.

I'm considering starting from scratch in C++, using templates and function overloading to dealing with the basic types; using inheritence to create a base type with features every type shares and derive the types from it; and using the STL to organize the informational lists.

What are some tips for implementing this? Also, what kind of STL list should I use to organize the informational lists? I'm leaning toward map, but I'm wondering what others think.

by on (#62355)
What exactly are you trying to do? There were so many implementation details in your post I didn't quite understand what your goals are.

by on (#62378)
Gradualore wrote:
What exactly are you trying to do? There were so many implementation details in your post I didn't quite understand what your goals are.


Seconded. The post reeks of merging two development models/methods (low-level assembly development and high-level object-oriented/GUI-based development) together. That never works. Yes, I said never, and I do mean never. :-)

I guess I'm old-fashioned.

by on (#62381)
For some reason, this reminds me of that Z80 Disassembler I made a while ago. Every time it needed a 16-bit number, it displayed it as a number relative to a label. It followed the code, taking the jumps, calls, and branches to map out the code, then treated anything else as data. You could also add addresses to look for code to get stuff it missed.
But the Z80 isn't a 6502. There is no "ld hl,xxxx" instruction on the 6502, so you can't easily discover 16-bit labels other than jumps and calls.

by on (#62402)
koitsu wrote:
Gradualore wrote:
What exactly are you trying to do? There were so many implementation details in your post I didn't quite understand what your goals are.


Seconded. The post reeks of merging two development models/methods (low-level assembly development and high-level object-oriented/GUI-based development) together. That never works. Yes, I said never, and I do mean never. :-)

I guess I'm old-fashioned.


It would disassemble it to 6502. Basically, it would disassemble using information from the code/data logger as used in some variants of FCEU and then would put labels, put equates, put references*, organize data into groups/strings as specified by the user+, and insert comments where specified.

I plan to use C++ for this, as there would be a need for informational maps that keep track of everything and would be accessed by the machine code file address. The disassembler would, each time it moves to the next address, check for the next item in each of the lists, and would implement them in a specified order (if there is more than 1 for a specific file address).

I plan to also create a GUI that would be a WYSIWYG editor, and would let you go to a line for example and select "Insert label" or "Put as reference" or, perhaps, select several lines of data and select "Organize into data group" (and you could still put references there). The GUI would create and organize the informational maps and let you load/save them.

It does seem ambitious, but I think that it can be implemented, and I did implement it, without the GUI, already in a project called INF0EDIT/CDLDIS2. But the project is written in GNU C and I had to do a lot of tricks with macros to deal with the different types I used. This is why I want to move onto C++ and use STL maps, classes, etc., to implement this. I am trying to work on how I will be implementing it now, and was wondering if anyone had any advice.

*It would also check that the reference/string actually matches what is in the binary. To do this for references, it would organize all labels and equates into a Names map specifying the value and location of the labels/equates; this will be accessible to a parser that will check the references. So, you could make clearer, for example, that

Code:
lda $55


is actually an implementation of

Code:
lda dungeonlevel >> 1


Basically, the parser would go through, use the reference to the label/equate dungeonlevel, and then check to make sure the whole statement comes out to the value of $55 in the implemented code. If not, it would return an error. Basically, this allows you to put in the labels, equates, and references at the time the disassembly is made, and to check to make sure your use actually matches what is implemented in the binary.

By keeping track of location, I also plan to add support for the insertion of +/- labels.

+For example, instead of
Code:
.db $14
.db $55
.db $ae
.db $55

It would let you specified that it needs to be organized like either
Code:
.db $14, $55, $ae, $55


or like

Code:
.dw $5514, $55ae


You would be able to specify base (bin, dec, hex, etc.), the length of the data group, and the number of entries per line. It would still check for the use of references or strings within the group, and would implement them when it comes across their file address.

by on (#62403)
So sort of like da65?

by on (#62404)
tepples wrote:
So sort of like da65?


*Looks at the file.*

Right, something like that, but which would produce output assembleable with something closer to ASM6.

*Downloads DA65 to study their implementation.*