#994 Support for Ophis 65xx assembler

Completed
open
nobody
None
5
2013-05-28
2013-05-25
Sasha of 9
No

Greetings,

I have created or modified the necessary files in my SciTE331 to provide syntax highlighting for 6502/6510/65C02 assembly language, for the Ophis cross-Assembler syntax; files include Lex65xx.cxx, Scintilla.iface, 65xx.properties, and if you want, my SciTEGlobal.properties and a sample 6502 assembly program (and any other files you want or need).
Is the project interested in adding this stuff to itself?
Thanks for your feedback and any advice or suggestions on the subject, and thanks for SciTE!

Discussion

  • Neil Hodgson

    Neil Hodgson - 2013-05-26

    Why aren't the existing LexAsm or LexA68k lexers adequate? If possible I'd like to avoid having a separate lexer for every instruction set.

     
    • Sasha of 9

      Sasha of 9 - 2013-05-28

      Ugh!
      I posted a long detailed reply to you just now, and sourceforge gave me some "404 Method Not Allowed" error, followed by "Document Expired" -- and my reply is gone. #$%&*

      Well, suffice it to say, a separate lexer is not absolutely required, to incorporate the changes/features I'd like for Ophis, though the code would be less convoluted if it were separate.

      I'm going to keep working on it as a separate lexer for now, until it's perfect, and then I'll consider integrating it into the existing LexAsm or LexA68k; now that I'm a bit familiar with the lexer code, I believe it should not be too big an issue-- toss in some conditional statements to lex differently depending on what filetype is being edited, and presto. Though I believe separate properties files would keep the clutter to a minimum.

      My main problems with LexAsm and Lex68k were the lack of folding (though I do have assembler directive syntax folding working in my 65xx code, so it may have been partly a PEBKAC error of my own that I couldn't get it working in LexAsm-- I may have just not configured it correctly). Also, Ophis syntax is similar to more common assemblers, but differs enough that highlighting isn't right, and I can't compensate with style adjustments alone, the code needs adjustment. One example is single-quotes: in Ophis they are not used for strings, but can be used like underscores in macro names (macro'name'here), or for passing an ascii char as a numeric argument (adc #'A rather than adc #65)-- so as it is now, the lexer treats this stuff as STRINGEOL, which looks annoying; even if I compensate by adjusting the STRINGEOL style, and arguments given after the single quote are considered part of a string by the lexer.

      I have a few other small ideas that anyone with already enough to do might call frivolous (some input-error highlighting, additional styling tweaks..), but I'm enjoying this little project of getting SciTE and Ophis to cooperate fully. If I end up with something you like, that'd be groovy. If not, no problem :)

      Well, I'm thankful for your having taken the time to read this, and for any thoughts you have to add!

      Thanks.

       
  • Neil Hodgson

    Neil Hodgson - 2013-05-28

    Changing the set of chars accepted in an identifier can be implemented fairly simply. Look at LexCPP for an example with lexer.cpp.allow.dollars. For a larger language difference see how a second cppnocase lexer is implemented in that file.

     

Log in to post a comment.