syntax highlighting for assembler

[jesari]

Hi,
Does anobody here know a syntax highlighting editor for the 6502 assembler? I'm trying to use gedit with the following language-specs file:

http://www.ele.uva.es/~jesus/6502/asm6502.lang

I modiffied this file from another example, but the results aren't satisfactory yet. The main problem is the rule set for hex. and binary numbers. It would be also interesting to have a different style for labels, directives and immediate operands. But, I must admit I don´t know much about regex...

[Ruud]

jesari wrote:

Does anobody here know a syntax highlighting editor for the 6502 assembler?

I'm using PSPad, http://www.pspad.com/en/. You have to make your own INI file for the text to be highlighted but you can have a copy of mine of course. Another nice feature of PSPad: with Ctrl/F9 you can start up a compiler during editing.

[jesari]

Ruud wrote:

I'm using PSPad, http://www.pspad.com/en/. You have to make your own INI file for the text to be highlighted but you can have a copy of mine of course. Another nice feature of PSPad: with Ctrl/F9 you can start up a compiler during editing.

Thanks, but I forgot to mention I wanted an editor for Linux. PSPad looks nice, but I don't think it is a good idea to switch to a Windows OS just for the sake of the editor. Meanwhile, I found a better language-specs example (for NASM) and after some mods I came with an usable syntax highlighting for gedit. The language-spec file for the 6502 assembler can be downloaded fom here:

http://www.ele.uva.es/~jesus/6502/asm6502.lang

This file has to be copied to the following directory:

/usr/share/gtksourceview-2.0/language-specs

Then select: "View -> Syntax Highlight -> Other -> ASM6502" on the gedit menus (english names for menus can be different. I got them in spanish). Here is how it looks:

[GARTHWILSON]

My MultiEdit 7.0 programmer's text editor that I use under DOS (in hi-res, so I can see 60 lines at a time on my monitor) does the syntax highlighting, but I don't have any recommendations for other OSs.

Your code however is very difficult to read, not because of lack of syntax highlighting, but because of lack of structure, appropriate blank space, indenting for loops and conditions, etc.. [Edit: See my correction further down.] Also, appropriate use of assembler macros effectively raises the level of the language and makes software faster to write and more bug-free, and easier to maintain—all without any penalty in runtime speed or memory or in keeping absolute control. I wish assemblers had assembler variable arrays and ways to index into them to synthesize stacks in the assembler itself as that would make it easier to do program structures, but I have found somewhat of a way around it and done these structures anyway, synthesizing standard Forth-like structures like BEGIN...WHILE...REPEAT, BEGIN...UNTIL, IF...ELSE...THEN, DO...LOOP, CASE statements, etc.. It gets rid of many of the labels and much of the spaghetti code.

We had some discussion on macros at viewtopic.php?t=1586 . [Edit: Also, my article on program-flow structure macros at http://wilsonminesco.com/StructureMacros/ .]

[BigEd]

Hi Jesari
thanks for sharing your work. I use emacs and it usually syntax colours things (until I turn it off for better readability.) I'm not using more than 1% of what emacs offers, but my fingers know the basic commands so I continue to use it.

I think Garth's point in this case is that operations on 16bit data values can usefully be wrapped in macros, to be more readable and reliably correct. It would be interesting to see how a highlighter deals with macro definitions and usage.

Cheers
Ed

[jesari]

GARTHWILSON wrote:

Your code however is very difficult to read

... And that was only a tiny piece of code. Wait until you see the remaining 2800 lines...
Macros can help. You're right. But they have a different syntax on each assembler. Even the labels can have different syntaxes (colon suffix or not). So, at the end, I'm just writing plain assembler for ca65. ca65 is part of the C compiler cc65 and it could possibly use the cpp macros: #define DEC16(ptr) (lda.....)
Indentation is always possible. No excuses this time...

[GARTHWILSON]

I had written,

Quote:

Your code however is very difficult to read

My apologies— The quantity of code you have posted is not enough for me to say that with certainty. I was confusing you with someone else on the forum who has posted a lot of unreadable stuff.

[kc5tja]

I was beginning to wonder there, Garth.

I would like to offer this tip to aid code legibility though: try to prevent yourself from stating the obvious in your comments. For example,

Code: Select all

    inc ptr1
    bne op2b3
    inc ptr1+1
op2b3:

is pretty obviously incrementing a pointer. We know it's a pointer because of the operand labels, and we know it's incrementing because of the INC instructions.

A better technique for comments is to explain why you're doing what you're doing, not what. To help illustrate what I mean, consider this hypothetical piece:

Code: Select all

  inc ptr1+1 ; Incrementing high byte is same as adding 256, but faster.

or:

Code: Select all

  bcc     *+3  ; Skip next instruction if carry set by falling into BIT instruction.
  .byte   $2C
  ...

Depending on the experience level of the reader, though, he might find even these comments to be unhelpful, since these are such common 6502 idioms. But I hope they illustrate the qualitative difference in commenting style.

Just a friendly suggestion.

[BigDumbDinosaur]

Perhaps the topic would be better named "Syntax Highlighting for a 65xx-Aware Editor"

I do some work in the Kowalski simulator, which has a source code syntax highlighting capability, better described as field highlighting. I've found it to be only marginally useful, in that I already know 65xx assembly language and don't need an editor to tell me when I've made a boo-boo—the assembler will take care of that.

As for "colorizing" in editors such as EMACS or vi, I'd rather it be off by default. I'm blue-green color blind, and any attempt to spruce up text with color is usually annoying. I particularly find Linux's use of color in directory listings to be a pain, and immediately kill that feature.

[kc5tja]

One of the reasons why assembly language listings use columns dates back to the IBM punch-card days, where most languages (both high AND low level) placed various program terms on certain columns. They did this precisely because they had no means of indicating the type of construct at hand. For example, labels start in column 1, opcodes start at column 9, etc. In this way, it's perfectly legal to have a label LDA, and an opcode LDA, and they'd be fully disambiguated.

Code: Select all

         1         2
12345678901234567890 . . .

LDA     LDA      #15
        STA      PORTA
        LDA      #14
        STA      PORTA
        JMP      LDA

Today's low-level languages benefits from modern language research, including the field of LL and LR parsing techniques. It's now possible to write assembly language using more conventional program structure, though few people ever do so.

Code: Select all

lda #0; tax
begin
  sta buffer,x; inx
untileq

Syntax highlighting makes a lot more sense in this free-form, quasi-conversational approach. The cost is you lose potentially useful labels, and certain things become harder to see.

And then there is ColorForth[1], which kind of combines the two approaches. The editor doesn't highlight the source text, YOU highlight the source text based on how you want Forth to interpret your source code. Green code is compiled, yellow is executed immediately (e.g., compile-time), etc. This is singularly liberating! Unfortunately, it has its own trade-offs.

_______________
1. Chuck Moore doesn't care about any potential vision problems you might have; he wrote ColorForth for him. However, he does encourage folks who are color-blind to try that style of programming with, perhaps, different type-faces instead. The idea of tagging words at edit-time is universal; the choice of using colors to indicate this tagging is only an implementation-specific detail.

[BigDumbDinosaur]

kc5tja wrote:

_______________
1. Chuck Moore doesn't care about any potential vision problems you might have...

Color is fine and all that, but obviously is not going to help when displayed on a monochrome terminal, which device until relatively recently, dominated computer displays. I guess I'm just an old stick in the mud (or dinosaur in the swamp). I like my programming environment to keep color changes to a minimum. I also run my browser in monochrome, mostly because of sites like this with their pastel colors (hard for me to distinguish).

[kc5tja]

Hence the footnote. If all you have is monochrome displays, then you can substitute colors with typefaces. It does require a bitmapped terminal though.

[Procrastin8]

I know this post is pretty ancient but I've been building a full 65C02 IDE for macOS and recently tackled this very problem. Numbers were the most annoying so I thought I'd share my solution (though my stylistic choices might bother some or all of you) but you can tailor it a bit to your liking. I've included a screenshot that illustrates most of the relevant numerical situations that have arisen for me with comments describing them.

Here are the regexes I use for the various types of numbers in Swift.

Code: Select all

        // bc i know i will forget this, the following use look-behind `(?<=[asdf])` and look-ahead `(?=[asdf])`
        let hexNumberGenerator = regexGenerator("(?<=[\\s(#])\\$[[:xdigit:]]+(?=[\\s),])", tokenType: .number)
        let binNumberGenerator = regexGenerator("(?<=[\\s(#])\\%[01_]*(?=[\\s),])", tokenType: .number)
        let decNumberGenerator = regexGenerator("(?<=[\\s(#])[[:digit:]]+(?=[\\s),])", tokenType: .number)

Hope this help someone tidy up their IDE of choice.

[BigDumbDinosaur]

Procrastin8 wrote:

I know this post is pretty ancient but I've been building a full 65C02 IDE for macOS and recently tackled this very problem. Numbers were the most annoying so I thought I'd share my solution (though my stylistic choices might bother some or all of you) but you can tailor it a bit to your liking. I've included a screenshot that illustrates most of the relevant numerical situations that have arisen for me with comments describing them.

Here are the regexes I use for the various types of numbers in Swift.

Code: Select all

        // bc i know i will forget this, the following use look-behind `(?<=[asdf])` and look-ahead `(?=[asdf])`
        let hexNumberGenerator = regexGenerator("(?<=[\\s(#])\\$[[:xdigit:]]+(?=[\\s),])", tokenType: .number)
        let binNumberGenerator = regexGenerator("(?<=[\\s(#])\\%[01_]*(?=[\\s),])", tokenType: .number)
        let decNumberGenerator = regexGenerator("(?<=[\\s(#])[[:digit:]]+(?=[\\s),])", tokenType: .number)

Hope this help someone tidy up their IDE of choice.

I don't see any mnemonics in that source code display.

[BigEd]

Seems like you and I are both grumpy today BDD. Allow me to translate: BDD has vision problems, and prefers that people post high contrast monochrome images.

Edit: I do apologise for this outburst. There is indeed a potential accessibility problem with low contrast images, and a polite request to post a higher contrast version would not be out of place.