12 comments

[ 3.3 ms ] story [ 39.5 ms ] thread
This actually looks surprisingly nice... I thought it would appear overly verbose.

Is this mostly "renaming instructions" and adding macros in the same style? A big struggle with assembly for me is simply grepping the syntax (which can also varies wildly across architectures) - this makes it incredibly understandable.

I don't use assembly daily, how well does this work across different instruction sets? Does this fall apart with more complex usages or does it all look relatively sane like this?

I have used macro assembler to generate 4 different targets from the same source - powerpc, micro blaze, x86, and C and it worked wonderfully. a caveat being that the projected language was specifically for this one piece of firmware and would likely not generalize. for example the firmware used the ppc cache management instructions and they weren't available on the other platforms, so they were nops there.
And I always thought there is already a set of macros that makes assembler more readable and portable. It is called C.
This project targets the CLR (the runtime for C#), not a CPU.
It’s pretty bad at this.
It combines the performance of assembly with the readability of assembly.
I see it's said in a jest, but an optimizing C compiler does so much more than macro expansion that it's not even funny (when looking at the resulting assembly).
Probably, the title needs adding "for .NET"
Ok, added. Thanks!
I did something similar when I needed to make an assembler for a web based IDE.

Since I was writing an assembler anyway, and I had no particular requirement to be compatible with existing assemblers, I got to play around with the mechanics of macros.

I created a directives

    .snip <name> 
    .endsnip

 and 

    .use <name>
to create a kind of inline module mechanism where snippits of code could be included if the code contained a .use with the same name. Multiple instances of .use would cause the snip to only be included once.

Combining snips with macros meant you could have a macro available and it could add supporting code on demand via .use.

Here's a gist loaded into the IDE https://k8.fingswotidun.com/static/ide/?gist=ad96329670965dc...

The three Lines after init: Are all macros doing quite a bit of behind the scenes work.

    init:
      set_stack_pointer RAMEND
      load_let_values  
      print_rom "Mode0 Text"
print_rom needs to reserve a space in the ROM for the text, and call a print routine with the pointer to the text.

The print routine has variables to indicate where the current cursor position is, where in memory the text buffer is etc. These are set up with macros

    letw mode0_Page,$8000
    letb mode0_Width,80
    letb  mode0_Height,60
    letb  mode0_CursorX,0
    letb  mode0_CursorY,0
    letb  mode0_Color,$20
Which allocate ROM space for the initial values and set the symbols to indicate their RAM position. The macro load_let_values inserts the code required to transfer the ROM initial values into their ram locations.

In hindsight, I probably shouldn't have made an assembler a line-by-line processor, there are a bunch of nesting things that I think would have some tough jobs easier.

Anyway, if anyone wants a idiosyncratic AVR macroassembler that no one asked for it's on github https://github.com/Lerc/AvrAsm

Can I use this to convert clr bytecode if a .NET binary and disassemble it? If so, I asked for this.

Obfuscated shellcode loading .NET that can't be disassembled all the disassemblers like jetbrains or ilspy are frustrating because you can't just run them in a native debugger.