4 ms·

A macro-assembler in 96 lines (1300 bytes of object code)

19 points by gnosis 15y ago

kabdib 15y ago
Maybe I'm an old fart, but "uses only 1300 bytes of object code" isn't important to me if the input is virtually unreadable. It might make sense in an embedded environment. I don't see this as being attractive in the production assembly environments I've used (games, the 68K-based Macintosh ROMs, etc.). "Another victory like that and we're done for, sir." :-)
- kragen 15y ago
  For context, Bill Ragsdale (note the "s"!) wrote this article for Forth Dimensions in 1981; it was published in the January/February 1982 issue. Might it have been more important to you if you were doing self-hosted development on a 6502? I guess you're saying you don't like the reverse polish syntax: .A ROL, --> ROL A 1 # LDY, --> LDY #1 DATA ,X STA, --> STA DATA,X DATA ,Y CMP, --> CMP DATA,Y 6 X) ADC, --> ADC (06,X) POINT )Y STA, --> STA (POINT),Y VECTOR ) JMP, --> JMP (VECTOR) That's understandable, although I think it's not too hard to learn to read that. It would probably take another page or two for a conventional parser. On the other hand, I think the environment he's describing has some big advantages over a conventional assembler, other than just code size: 1. The macro system is a full-fledged Turing-complete programming language, not some crippled text-substitution thing kludged onto the side of the assembler. 2. You can write loops and conditionals in it without labels, which makes it a little closer to C than to assembly in the language level, in my book. To me, that makes it more readable, rather than less. 3. You can test your assembly-language routines interactively as you write them, as if you were programming in DDT, but without losing the ability to go back to your source code. In the long run, though, these potential advantages lost out to more traditional IBM-punched-card-style assembly languages, and mostly to C. I don't really understand why. Maybe because the successful companies already weren't doing their 6502 development self-hosted?
  - justincormack 15y ago
    Makes more sense with the date! Perhaps an ARM port would be useful...
    - KGRGreer 15y ago
      How about a Forth Arm Assembler and Disassembler: http://yxit.co.uk/source/#ARM%20Assembler http://yxit.co.uk/source/#ARM%20Assembler
      - kragen 15y ago
        I imagine that could be very useful, but the code is pretty bad. Take a look at the REGISTER word in http://yxit.co.uk/source/forth/arm-asm.f http://yxit.co.uk/source/forth/arm-asm.f. It contains 25 lines of code! And they're full of magic numbers and stack operations!
- abecedarius 15y ago
  I did have a recent-ish use for something like this. The 2006 ICFP contest, which was awesome, took the form of a virtual-machine image you had to write an emulator for in order to get at the problems. The image was a self-extracting compressed executable. After the contest, we had to submit our source code. For kicks, I made a self-extracting compressed executable generator at the last minute so we could submit our stuff in the same form as the contest image itself. To make this, I needed an assembler for their VM; I made a Forth DSL just like the OP here. Russell O'Connor was working separately on a DOS-like shell to wrap around my compressor. He needed an assembler too, and wrote his as a Haskell DSL which he later expanded and wrote up in http://www.haskell.org/wikiupload/1/14/TMR-Issue6.pdf http://www.haskell.org/wikiupload/1/14/TMR-Issue6.pdf (Just one assembler might have been sensible, but we had to make this submission in a few hours overnight after 3 days of contest hacking and weren't up to more than minimal effort on coordinating.) For assembler coding Forth syntax really is no worse than Lisp-syntax assembler -- I got pretty comfortable using it in practice back in the day. And as Kragen notes, the underlying Forth system is more powerful than a macro assembler. (I'd agree that Forth is not a comfy general-purpose language by modern standards.)

19 points by gnosis 15y ago

Maybe I'm an old fart, but "uses only 1300 bytes of object code" isn't important to me if the input is virtually unreadable. It might make sense in an embedded environment. I don't see this as being attractive in the production assembly environments I've used (games, the 68K-based Macintosh ROMs, etc.). "Another victory like that and we're done for, sir." :-)

kragen 15y ago
For context, Bill Ragsdale (note the "s"!) wrote this article for Forth Dimensions in 1981; it was published in the January/February 1982 issue. Might it have been more important to you if you were doing self-hosted development on a 6502? I guess you're saying you don't like the reverse polish syntax: .A ROL, --> ROL A 1 # LDY, --> LDY #1 DATA ,X STA, --> STA DATA,X DATA ,Y CMP, --> CMP DATA,Y 6 X) ADC, --> ADC (06,X) POINT )Y STA, --> STA (POINT),Y VECTOR ) JMP, --> JMP (VECTOR) That's understandable, although I think it's not too hard to learn to read that. It would probably take another page or two for a conventional parser. On the other hand, I think the environment he's describing has some big advantages over a conventional assembler, other than just code size: 1. The macro system is a full-fledged Turing-complete programming language, not some crippled text-substitution thing kludged onto the side of the assembler. 2. You can write loops and conditionals in it without labels, which makes it a little closer to C than to assembly in the language level, in my book. To me, that makes it more readable, rather than less. 3. You can test your assembly-language routines interactively as you write them, as if you were programming in DDT, but without losing the ability to go back to your source code. In the long run, though, these potential advantages lost out to more traditional IBM-punched-card-style assembly languages, and mostly to C. I don't really understand why. Maybe because the successful companies already weren't doing their 6502 development self-hosted?
- justincormack 15y ago
  Makes more sense with the date! Perhaps an ARM port would be useful...
  - KGRGreer 15y ago
    How about a Forth Arm Assembler and Disassembler: http://yxit.co.uk/source/#ARM%20Assembler http://yxit.co.uk/source/#ARM%20Assembler
    - kragen 15y ago
      I imagine that could be very useful, but the code is pretty bad. Take a look at the REGISTER word in http://yxit.co.uk/source/forth/arm-asm.f http://yxit.co.uk/source/forth/arm-asm.f. It contains 25 lines of code! And they're full of magic numbers and stack operations!
abecedarius 15y ago
I did have a recent-ish use for something like this. The 2006 ICFP contest, which was awesome, took the form of a virtual-machine image you had to write an emulator for in order to get at the problems. The image was a self-extracting compressed executable. After the contest, we had to submit our source code. For kicks, I made a self-extracting compressed executable generator at the last minute so we could submit our stuff in the same form as the contest image itself. To make this, I needed an assembler for their VM; I made a Forth DSL just like the OP here. Russell O'Connor was working separately on a DOS-like shell to wrap around my compressor. He needed an assembler too, and wrote his as a Haskell DSL which he later expanded and wrote up in http://www.haskell.org/wikiupload/1/14/TMR-Issue6.pdf http://www.haskell.org/wikiupload/1/14/TMR-Issue6.pdf (Just one assembler might have been sensible, but we had to make this submission in a few hours overnight after 3 days of contest hacking and weren't up to more than minimal effort on coordinating.) For assembler coding Forth syntax really is no worse than Lisp-syntax assembler -- I got pretty comfortable using it in practice back in the day. And as Kragen notes, the underlying Forth system is more powerful than a macro assembler. (I'd agree that Forth is not a comfy general-purpose language by modern standards.)