A MOS6502 assembler implemented as a Rust macro

https://play.rust-lang.org/?gist=a18d697454f9261b28ff&version=stable

by mmastrac • 10 years ago

111 55 10 years ago

play.rust-lang.org

vvanders• 10 years ago

Link appears to be broken, working one is:

https://play.rust-lang.org/?gist=a18d697454f9261b28ff

hathawsh• 10 years ago

Very cool. As a Rust newbie I'd like to understand what's going on here. Is this a "procedural" macro? Does Rust specifically target writing DSLs using its macro system? Can we expect macros like this to continue working for a long time? There's a blog post that suggests possible changes: https://internals.rust-lang.org/t/the-future-of-syntax-exten...

mcpherrinm• 10 years ago

This isn't a procedural macro: Procedural macros run Rust code to transform your program, and interact with the guts of the compiler (AST, etc). That's hopefully going to change to not be compiler-version specific, etc.

This is using a system known as "macro_rules" which are a system of "expanding" -- in some ways it's a fancier version of the C preprocessor, but also resembling the Lisp/Racket macro system to some degree too.

Let's take a random little piece of that code from the post and talk about it:

    macro_rules! codelen {
        () => { 0 };
        ( $($c:expr),+ ) => { [$($c),+].len() };
    }

This declares a new macro substitution rule called `codelen`. Without going into too much depth, that's defining rules (on the left hand of the `=>`) and saying what code to expand them into, on the other side. The first replaces `()` with `{0};`, just a simple substitution. In the second rule, the `$($variable),+ is the essential construct here, letting you operate on sequences of input stuff.

It's a little hard to read -- writing your own macros in Rust is a little bit complicated and I don't think it's actually something that should be done often. You can write little DSLs with it for sure. This variety is going to stick around and will keep working. It is called macro_rules! and not just macro! to leave that name free for a future, enhanced way to write macros, though.

steveklabnik• 10 years ago

  >  Is this a "procedural" macro?

This is not a procedural macro, it's a regular-old macro.

  > Does Rust specifically target writing DSLs using its macro system?

I would say that "specifically" is a bit strong, but they are one application of them, yes.

  > Can we expect macros like this to continue working for a long time?

This functionality runs on Rust stable, and therefore should continue working forever.

The post you're referring to is talking about procedural macros/syntax extensions/compiler plugins, which are not stable and will see lots of change.

We also may end up with a new macro system as well, but it will not conflict with the existing macro system if we do.

JustSomeNobody2• 10 years ago

That ... is ... f*ing ... ugly to look at.

vardump6• 10 years ago

Well, a creative abuse of the language. Programmer humor.

JustSomeNobody2• 10 years ago

Being a developer myself, I'm well aware of this. Still, it's ugly.

mcguire• 10 years ago

If your macros aren't ugly, you're doing it wrong.

sklogic4• 10 years ago

Macros should never be ugly. There are multiple ways of using compile-time metaprogramming in a nice and clean way.

Maybe even in Rust, although I have not tried it yet.

pcwalton5• 10 years ago

It's not the intended use case for declarative macros. Procedural macros are designed for this.

mc808• 10 years ago

You know that optical illusion where you can't tell whether you're looking at a cube from the top or the bottom, so your brain keeps flipping back and forth between them? This code is like that for me, but flipping between Perl and C.

GlitchMr• 10 years ago

It doesn't support explicit accumulator addressing mode (ASL A, LSR A, ROL A, ROR A), but otherwise quite neat. (from a quick look at it)

(also, 0x syntax is quite unusual, but I assume $ couldn't have been implemented for some reason)

pvg3• 10 years ago

You mean as syntax? Because the opcodes seem to be there.

vardump6• 10 years ago

Isn't A the only register those ops can use anyways? Although it's been a while, 25 years...

duskwuff• 10 years ago

You can't ASL X or Y, but you can ASL $0 or ASL $0, X. (Using either a zero-page address or an absolute address.)

to3m2• 10 years ago

This seems to be somewhat common - I've used a few assemblers that make you write ASL A as just ASL (and so on).

Benefit (?): you can now have a label called "A".

ddingus3• 10 years ago

The accumulator is the only register those work with. It was very common to not specify it.at all. I actually never have in all the 6502 assembly code I've ever written. Wasn't required.

pvg3• 10 years ago

I don't think that's true.

http://www.downloads.reactivemicro.com/Public/Users/David_Cr...

Code is straight from the Red Book listings. Search for ROR - accumulator (shown explicitly), indexed, you name it. 4 modes each.

CodeWriter23• 10 years ago

That's a new twist on the Macro Assembler.

mmastrac• 10 years ago

The author appears to have a crate for it as well: https://github.com/jonas-schievink/rustasm6502

monocasa• 10 years ago

Reminds me of this sweet paper

http://research.microsoft.com/en-us/um/people/nick/coqasm.pd...

nickpsecurity2• 10 years ago

That's the exact one I thought of. On top of it, there's typed assembler:

https://www.cs.cornell.edu/talc/

And Vx86 used in Microsoft hypervisor:

http://swt.informatik.uni-freiburg.de/staff/maus/dissemain.p...

Note: Microsoft also used a TAL, though can't recall if same as Cornell, in their VerveOS that was verified down to assembler. Combined with SLAM, it's safe to say their researchers are kicking serious behind on practical, cutting-edge verification. I wouldn't have believed it 10+ years ago if someone told me haha.

gamache• 10 years ago

No ORG, no deal. I can't use this in production unless it supports ORG.

ilurkedhere• 10 years ago

Lisp user here.

This reminded me of https://github.com/kingcons/cl-6502 where the opcodes are defined using a defasm macro https://github.com/kingcons/cl-6502/blob/master/src/cpu.lisp... and implemented here https://github.com/kingcons/cl-6502/blob/master/src/opcodes....

Are Lisp macros pretty much on par with Rust macros?

FreeFull• 10 years ago

I was under the impression Lisp macros are more powerful/flexible than Rust's macro_rules! macros, although I don't know enough about Lisp macros to be sure.

A MOS6502 assembler impleme​nted as a Rust macro

Related Stories

A MOS6502 assembler implemented as a Rust macro