This seems like a small update, but I solved a lot of the problems I was having with the asterisk character. The problem was that gas would eat the spaces around them, making it impossible to see if the asterisk was intended as an operator or a comment delimiter.

In looking through the parsing code, I found that if defined, tc_symbol_chars could be used to indicate which characters may start a symbol. If a symbol character is found, the surrounding whitespace is preserved. This list of characters is used to handle cases like mine for other machines. If not for the comments in the parser code, I would not have even considered using tc_symbol_chars for this.

By the time I found this I was fairly far down the road of performing a parallel parsing of the input files, but preserving all spaces. That would have been a long, error prone mess. This new approach is so much cleaner.

One down side of this approach is that I need to scan through the line to see if it's OK to collapse the surrounding spaces. Another problem is that I had to remove the asterisk from the list of comment characters, since that would override the "used as part of a symbol" option. I'll have to scan each line and handle all comments myself. Oh well. No matter what, this approach will be more correct and much easier to implement than what I was doing.