Most tests pass, but 2007-labels-and-symbols fails because the
expressions recognized by 64tass don't match up with either of the
other assemblers.
This is currently using a workaround for the local label syntax.
64tass uses '_' as the prefix, which is unfortunate since SourceGen
explicitly allowed underscores in labels. (So does 64tass for that
matter, but it treats labels specially when the '_' comes first.)
We will need to rename any non-local user labels that start with '_'.
(issue #16)
We were using \u23e9, BLACK RIGHT-POINTING DOUBLE TRIANGLE, but
neither Win7 SP1 nor Linux was able to display the glyph. It also
gets all puffy in web browsers. We now use \u25bc, BLACK
DOWN-POINTING TRIANGLE, which seems to work everywhere. It also
feels more appropriate, because it appears next to the "containing"
opcode, with the embedded instruction appearing on the following
line.
Changed the "quick config" buttons for the asm config and pseudo-op
tabs into a drop-list and "set" button. The default values for
each assembler are now defined in the Asm*.cs file, rather than in
the settings code.
Rather than have each assembler get its own app config string for
the cross-assembler executable, we now have a collection of per-
assembler config items, of which the executable path name is one
member. The Asm Config tab has an auto-generated pop-up to select
the assembler.
The per-assembler settings block is serialized with the rather
unpleasant JSON-in-JSON approach, but nobody should have to look
at it.
This also adds assembler-specific column widths to the settings
dialog, though they aren't actually used yet.
Each supported assembler has an IGenerator interface and an
IAssembler interface. They're still two separate classes, but now
both are implemented in the same source file. (They'll probably
stay separate classes, since the two have little interaction.)
I'm keeping the "Asm*" filename. Seems the more natural fit.
Also, changed AssemblerInfo to try to get all assembler-specific
stuff into a single table.
Most of the decorative items associated with a file offset are
placed before the item in the display list, and given a span of
zero. This yields the correct behavior in a binary search: an
exact match finds the decorative item (e.g. a blank line), while a
match partway into the instruction or multi-byte data item causes
the binary search to move on to the next line, where it's resolved.
The problem is that we were adding a blank line *after* instructions
in the no-continue case. If the binary search found the blank line
before it found the instruction, it would guess "too high" rather
than "too low", and miss the actual instruction line.
We now set a flag and add the blank line as part of the following
item. We do a little dance at the start to ensure that the blank
line doesn't disappear during a partial update.
There's a common convention for using one of the thumb buttons on
the side of the mouse to mean "back", notably in web browsers. I
keep hitting it without thinking about it, so let's just make it
official.
When you edit the operand of an instruction that targets an in-file
address, you're given the opportunity to specify a shortcut that
applies the symbol to the instruction's target address in addition
to or instead of defining a weak symbol reference on the instruction
being edited.
This didn't work right for operands with adjustments, e.g. the store
instructions in self-modifying code. It put the label at the
unadjusted offset, which does nothing useful.
We now correctly back up to the start of the instruction or multi-
byte data area.
Change acf19870 fixed one bug but introduced another: the call to
update the highlight happened before the selection was restored, so
it could potentially refer to a line that no longer existed.
Worked around two crashes in Mono 5.16's WinForms implementation.
(See mono/mono#11070 for the details.)
Still very unstable, but it no longer crashes on startup.
Also, tweaked the "about" box title.
There are some useful interactions between C/N and maybe Z. Added
a quick test to 1003-flags-and-branches.
Also, updated the 2008-address-changes tests. Change b37d3dba
extended the nearby-target range of out-of-file symbols by one, so
one line that didn't get an operand label now does.
Once upon a time, symbol files and extension scripts could only be
defined in the RuntimeData directory, so having the documentation
there made sense. Since both of these things can now be defined in
project directories, the documentation belongs in the manual.
(issue #27)
If PTR is defined as an external symbol, we were automatically
symbol-ifying PTR+1. Now we also symbolify PTR+2. This helps with
24-bit pointers on the 65816, and 16-bit "jump vectors", where the
address is preceded by a JMP opcode.
Removed the "AMPERV_" symbol I added to make the tutorial look
right.
The instruction operand editor and data operand editor are very
different, but there's no need to impose that distinction on the
user. They want to edit the operand either way. We now provide a
single "edit operand" menu item, and open the appropriate dialog
based on what they have selected.
This uses Ctrl+O as the keyboard shortcut, stealing it from
File > Open.
(issue #11)
Two changes:
(1) Code and data hints are now only applied to the first byte on
each selected line. This allows you to slap a code hint on a
string without lighting up the whole string. Inline-data hints
and hint removal work as before.
(2) Added a menu item (with Ctrl+D as shortcut) to toggle the state
of the uncategorized data analyzer. This makes it easy to turn
off the feature that put the code into a string in the first
place.
Every once in a while, SourceGen will become unresponsive when it
tries to show a MessageBox. In the debugger you can see the GC
running frantically, but the stack trace is just sitting on the
MessageBox show call. Apparently, if you don't specify a parent
window argument, the MessageBox will occasionally end up behind
everything else, and you can get stuck.
I'm not sure what the GC frenzy is about, or whether this will fix
what I'm seeing, but it's easy to do and might solve the problem.
cf. https://stackoverflow.com/q/3467403/294248
