6502.org

I meant state internal to the macro expansion process, during assembly time. For instance, consider a macro (or even pseudo-op loop statement) that just generates the bytes $00-xx based on a parameter. The loop counter that would count up would be part of the internal state during assembly time that has no presence during runtime.

I am also insane in having done ridiculous amounts of processing with macro systems, hitting the limits on every 6502 assembler I've used. Beyond regular code-generation insanity, I even build the documentation for Acheron's bytecodes from the inline instruction definition macros, by expanding to ASCII .byte directives that fill segments that the linker puts into .txt/.html files instead as part of the main program binary.

Only slightly OT, WhiteFlame, what assembler do you prefer, given your macro tastes?

I use ca65 the most. I've hit its limits multiple times, but it's the richest I've tried out so far. Granted, I haven't tested out all the 6502 assemblers out there, just mostly the ones related to the Commodore 64 community.

Outside assembly language, Lisp is my preferred macro taste, as code and data are equivalent and ridiculously easy to generate and modify, and doing so at compile-time or runtime are exactly the same.

A ca65 macro that allows one to enter a line (no length limit) of data as space seperated hex values (as in a hex editor).
Untested.
Example:

Thanks!

I'm surprised nobody mentioned m4 for use as a macro processor for bare minimal assemblers, which was it's original intent I believe.

I'm also learning Scheme, and that also is a good candidate for macro generation (anyone know if a Lisp interpreter exists for a 6502 system?).

However, I would prefer to have Scheme be a wrapper around the assembler, and not have the assembler opcodes written in Scheme (well, Common Lisp anyway), as is the case for the NES Lisp demo. I have not yet figured out the best way to run an input assembly file through a Scheme REPL or compiled program, that looks for lines with a specific signature and then EVALs them as Lisp expressions. Scheme's IO leaves much to be desired, but while I'm reading through SICP, it's what I've gotten used to.

An example I can think of that's well suited to Lisp is local variable generation. For the 6502 specifically, this would involve, figuring out how much memory locals need to use (given a list of variable names), allocating memory somewhere outside the direct page, place a pointer to this memory region inside the direct page, and then use Direct-Indirect addressing to access the variables, creating a str substitution for each variable name that converts it to the proper addressing mode.

I know very little about Lisp, but a quick search found this.

http://web.archive.org/web/200901061843 ... p-6502.asm

It's difficult for me to believe that it's a full main-frame implementation, but it is proof that there are some brave individuals out there willing to try.

Mike B.

Thanks for that link Mike! David Wheeler's 6502 Languages page has a few Lisp pointers:
http://www.dwheeler.com/6502/
although I haven't checked them out.
Edit: see also the earlier thread at viewtopic.php?f=2&t=1427

Lisp is a great language for manipulating source code, as that's how the language itself is built up. Its source code is structured as a list-based AST, so the idea would be to read assembly statements into such a format, and perform manipulations from there. e.g.: then search through those lists and convert them as needed, with good language support for that style of representation.

I wouldn't expect a 6502 native Lisp to have the memory or speed to perform such a compilation of real source code, though on x86 most Common Lisps are native code compilers. I don't know much about Scheme, but I assume that the bigger implementations compile natively as well.

Having spent some time (since starting this topic) with Common Lisp, I am sufficiently humbled. Yes, Lisp is clearly the way to do this - and probably everything else. I came against Greenspun's tenth rule https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule ... I suggest that anyone interested in the subject of macros take the time to at least familiarize themselves with Common Lisp...

Interesting, because my long-term plan is to take a long look at Lisp once I've had my fill of Forth, including the pie-in-the-sky idea of writing my own implementation for the 65816. And it will be interesting to see which language, Forth or Lisp, turns out to be better for assemblers, as Forth allows you to use the complete language for macros out of the box. Please keep us up to date on your progress!

The thing with Lisp is that both data and the program are lists, so it's (apparently) natural for programs to operate on programs, which makes the language a great deal more expressive. It's true that there are lots of parentheses - the form of Lisp we're familiar with was intended as an intermediate form, not the final form for humans. But here we are. If you use an editor which helps to match and to skip between the front and back of a matched pair, it shouldn't be a big deal.

We've discussed Lisp many times before. See
search.php?keywords=lisp&sc=1&sf=firstp ... mit=Search
for major mentions and
search.php?keywords=lisp&submit=Search
for all mentions.

(I've had a tab open for a while on a Lisp article, which I suspect I've read before, and am only part way through reading again. It aims to help the reader achieve the Lisp enlightenment. Here it is:
http://www.defmacro.org/ramblings/lisp.html
)

It's been said before, but the parentheses look annoying only for a couple of days. After that they are a blessing. Emacs with paredit surfs parenthesized expressions, and allows you to copy/paste entire expressions. Also rainbow parens colors different nesting levels. But I honestly never have to think too much about parens.