Cleanup for the da65 code base #2728
Conversation
|
One thing I forgot to mention: I have changed output for labels and hex numbers > 16 bits. Previously they always had 6 hex digits, now they have as many digits as required (5 or 6 depending on the value). This means that probably most of the far addresses the disassembler will ever see will have 5 hex digits. The reason for the change was that it saves a few lines of code and in addition allows a space between most long labels and the following code which makes it easier to read in my eyes. Example, new implementation: instead of, before: This change might be controversial, I can revert it if requested. |
|
Mmmh. I find numbers (in particular addresses) much easier/quicker to read, when they are in some "natural size", ie 8,16 or 32 bits (even 24bits is weird to me) Perhaps increase the indention one level, and make them either use 4 or 8 digits? (But i honestly don't care much) |
…cial casing of "long addresses" and prepares the code base for use with the full address range of the 65816. Use fixed size data types for addresses and target data words of known size. Many other minor improvements.
cb81771 to
e949fbd
Compare
I'm pretty sure people will complain if you have every number > 16 bit starting with two unused zeroes.
Not really necessary since the disassembler will start a new line if the label is too long to fit on the left side. So you will get for each far address. |
Oh someone will complain, no matter what :) Srsly though, fine with me this way |
|
thanks! |
This is a large cleanup of the da65 code base removing some of the hacks introduced earlier.
The most important change is the use of hash tables for all data tables that contained one entry per address before. This allows to remove the ugly special casing of "long addresses". In addition to that, I have also introduced fixed size integers for addresses and known target data types. For range errors in the info file, the attribute that contains the invalid value is now printed, so one has no longer to guess which of the attributes is out of range.
The changes do NOT include opening the address space to more than 64KB for the 65816 - this has to be done in a later change.
I wasn't bold enough to remove one other hack since I don't know how often it is actually used: The end of a range may optionally be specified with a '+' sign in front in which case it means an offset to the start. This is not in line with all other groups where a
SIZEattribute is used and is quite unexpected since a '-' sign in front doesn't designate an offset.