Project symbol address values are now limited to positive 24-bit
integers, just as they are for platform symbols. Constants may
still be 32-bit values.
While disassembling some code I found that I wanted the ROM entry
points, but the zero page usage was significantly different and the
ROM labels were distracting. Splitting the symbol file in two was
a possibility, but I'm afraid this will lead to a very large
collection of very small files, and we'll lose any sense of relation
between the ROM entry points and the ZP addresses used to pass
arguments.
Platform symbols have the lowest priority when resolving by address,
but using that to hide the unwanted labels requires creating project
symbols or local variables for things that you might not know what
they do yet. It's possible to hide a platform symbol by adding
another symbol with the same label and an invalid value.
This change formalizes and extends the "hiding" of platform symbols
to full erasure, so that they don't clutter up the symbol table.
This also tightens up the platform symbol parser to only accept
values in the range 0 <= value <= 0x00ffffff (24-bit positive
integers).
An "F8-ROM-nozp" symbol file is now part of the standard set. A
project can include that to erase the zero-page definitions.
(I'm not entirely convinced this is the right approach, so I'm not
doing this treatment on other symbol files... consider this an
experiment. Another approach would be some sort of conditional
inclusion, or perhaps erase-by-tag, but that requires some UI work
in the app to define what you want included or excluded.)
Memory-mapped I/O locations can have different behavior when read
vs. written. This is part 1 of a change to allow two different
symbols to represent the same address, based on I/O direction.
This also adds a set of address masks for systems like the Atari
2600 that map hardware addresses to multiple locations.
This change updates the data structures, .sym65 file reader,
project serialization, and DefSymbol editor.
Test case:
1. create a label FOO
(can be referenced or unreferenced)
2. add a platform symbol file that also defines FOO
(the platform symbol will be masked by the user label)
3. rename FOO to BAR
(platform symbol should appear)
4. hit "undo"
(platform symbol should disappear)
5. delete label FOO
(platform symbol should appear)
6. hit "undo"
(platform symbol should disappear)
This will fail to update the display list properly, and/or crash
when we try to add FOO to a symbol table that already has a
symbol with that label.
The problem is the optimization that tries to avoid running the
data analysis pass if we're just renaming a user label. We need to
check to see if the rename overlaps with project/platform symbols,
because we need to update the active def symbol set in that case.
To avoid the crash, we just need to use table[key]=value syntax
instead of table.Add(key,value).
Implement multi-byte project/platform symbols by filling out a table
of addresses. Each symbol is "painted" into the table, replacing
an existing entry if the new entry has higher priority. This allows
us to handle overlapping entries, giving boosted priority to platform
symbols that are defined in .sym65 files loaded later.
The bounds on project/platform symbols are now rigidly defined. If
the "nearby" feature is enabled, references to SYM-1 will be picked
up, but we won't go hunting for SYM+1 unless the symbol is at least
two bytes wide.
The cost of adding a symbol to the symbol table is about the same,
but we don't have a quick way to remove a symbol.
Previously, if two platform symbols had the same value, the symbol
with the alphabetically lowest label would win. Now, the symbol
defined in the most-recently-loaded file wins. (If you define two
symbols with the same value in the same file, it's still resolved
alphabetically.) This allows the user to pick the winner by
arranging the load order of the platform symbol files.
Platform symbols now keep a reference to the file ident of the
symbol file that defined them, so we can show the symbols's source
in the Info panel.
These changes altered the behavior of test 2008-address-changes,
which includes some tests on external addresses that are close to
labeled internal addresses. The previous behavior essentially
treated user labels as being 3 bytes wide and extending outside the
file bounds, which was mildly convenient on occasion but felt a
little skanky. (We could do with a way to define external symbols
relative to internal symbols, for things like the source address of
code that gets relocated.)
Also, re-enabled some unit tests.
Also, added a bit of identifying stuff to CrashLog.txt.
The ability to give explicit widths to local variables worked out
pretty well, so we're going to try adding the same thing to project
and platform symbols.
The first step is to allow widths to be specified in platform files,
and set with the project symbol editor. The DefSymbol editor is
also used for local variables, so a bit of dancing is required.
For platform/project symbols the width is optional, and is totally
ignored for constants. (For variables, constants are used for the
StackRel args, so the width is meaningful and required.)
We also now show the symbol's type (address or constant) and width
in the listing. This gets really distracting when overused, so we
only show it when the width is explicitly set. The default width
is 1, which most things will be, so users can make an aesthetic
choice there. (The place where widths make very little sense is when
the symbol represents a code entry point, rather than a data item.)
The maximum width of a local variable is now 256, but it's not
allowed to overlap with other variables or run of the end of the
direct page. The maximum width of a platform/project symbol is
65536, with bank-wrap behavior TBD.
The local variable table editor now refers to stack-relative
constants as such, rather than simply "constant", to make it clear
that it's not just defining an 8-bit constant.
Widths have been added to a handful of Apple II platform defs.
