search

Arakula / dasmfw

The DisASseMbler FrameWork
GNU General Public License v2.0
13 stars 4 forks source link

Disassembling 6520 code, I seem to be getting lots of undefined labels #7

Closed phillipeaton closed 2 years ago

phillipeaton commented 2 years ago

I'm not sure this is a bug, but it just doesn't seem right.

When assembling using as65, it's complaining about multiple undefined labels: image until image

If I search for e.g. m2a32 as shown in the picture, the only place I find it in the file is: image

There are lots of other labels defined at the start of of the file, but not m2a32: image

In the nfo file, these are defined as below, but it doesn't look like there is an overlap of the addresss in question, so it shouldn't effect it: image

Arakula commented 2 years ago

That m2a32 call looks like a data area interpreted as code (see the following fcb $04?).

phillipeaton commented 2 years ago

Agreed, but would dasmfw know that? And why would it care? It's going to be there for a while until I work out what it is in the source binary code. Like I said, I'm not sure if it's a bug, maybe dasm is working as intended, but it didn't seem right to me at first sight.

Arakula commented 2 years ago

No, it wouldn't. dasmfw doesn't perform any intricate flow analysis to separate code from data (which can be a very hard thing to do if, for example, indirect addressing using jump tables is used). It relies on the user to provide correct information in the form of proper code and data statements. By default, everything is code (except, of course, for those processors which clearly separate code and data).

It can give subtle hints, however - if an address is used in an instruction that clearly indicates it's referencing data (LDA, as a simple example) and there's no label in place for that address, it uses a "M" prefix for generated labels; if the referenced address is clearly code (JMP, for example), it uses a "Z" prefix.

phillipeaton commented 2 years ago

Ok, if it's expected behaviour, I can manually put some labels in the info file until I have really confirmed that they're data statements.

I suppose you could see it as a good thing because it forces you to look at these addresses and confirm manually that they are data, something you'd eventually need to do anyway.

phillipeaton commented 2 years ago

The M and Z prefixes are news to me. I assumed the Z prefix was for a one byte offset, as they often appear in simple loops. It might be worth putting this information in the help file, I couldn't find an explanation for M/Z when I looked previously.