RMasm, an upcoming assembler for demo coding?
category: general [glöplog]
Hi all!
I have been working for one month now on a new kind of assembler called RMasm. You can check a little introduction here on my blog.
Before going further (the project is in a... pre-alpha stage ;) ) I would like to get some feedback from the democoding scene.
I'm mainly targeting this assembler to ease the development of small-to-medium intros... what do you think about this kind of assembler? As an assembler programmer, what you would expect from it?
I have been working for one month now on a new kind of assembler called RMasm. You can check a little introduction here on my blog.
Before going further (the project is in a... pre-alpha stage ;) ) I would like to get some feedback from the democoding scene.
I'm mainly targeting this assembler to ease the development of small-to-medium intros... what do you think about this kind of assembler? As an assembler programmer, what you would expect from it?
that's pretty cool in one sense but i'm not sure what it really helps with :o
i mean during optimizing you have to break out of these sort of templates anyway
i mean during optimizing you have to break out of these sort of templates anyway
a great example is the source of Puls which starts with a label on the code segment so he can read the code as data... that's something you can't really make more intuitive i guess
im quite happy with Ikea thank you very much.
so in your estimation, about how large is the intersection of sceners, asm coders and ruby programmers? (or isn't that your target audience?)
I doubt that he meant 256-byte intros when he said his target was small-to-medium intros. For a 256B the amount of code will be so small and will generally lack repeating patterns, so that macros serve no practical purpose.
I don't need yet another x86 assembler. But if you'd make a WLA-DX clone with better error messages, better macro handling and some bugfixes then I'd be quite happy ;)
I don't need yet another x86 assembler. But if you'd make a WLA-DX clone with better error messages, better macro handling and some bugfixes then I'd be quite happy ;)
Quote:
so in your estimation, about how large is the intersection of sceners, asm coders and ruby programmers?
It very definitely contains me. (Although I'm firmly a Z80 guy - I've never written a line of x86 in my life.)
For my Spectrum stuff I've become a bit of a build tool fetishist, and I've come up with my own bunch of Ruby scripts to do that job. More and more, I'm finding that having to fork off to external tools is a major annoyance - especially if it's just to do something simple like put a 256-byte sine table in the middle of my code - and I've actually been thinking that an uber-hackable assembler like this might be the logical progression.
My only concern is that this approach might not generalise well to other dialects of assembler - for example, I'm guessing that stuff like "mov [esi],eax" works by recognising that the 'mov' method has been passed an array containing esi. In Z80 assembler, you'd normally do indirection with round brackets - e.g. "ld (hl),a", and if you tried to evaluate that as a Ruby expression those brackets would fall out.
Still, I'm really excited about this, and I intend to have a play with it next time I get a chance.
@mic: thanks for the WLA-DX link, worth to know about it!
@gasman: woo, that's cool. Indeed, if you are using scripts to generate sin table, this is fairly easy in RMasm, like this:
For the bracket thing, well, in RMasm, referencing address is going to be standardized as [] for all assemblers...
@gasman: woo, that's cool. Indeed, if you are using scripts to generate sin table, this is fairly easy in RMasm, like this:
Code:
dw :my_sin_table[SIN_TABLE_SIZE] << (0..(SIN_TABLE_SIZE-1)).inject([]) { |array,item| array << (Math.sin(item * 2.0 * Math::PI/SIN_TABLE_SIZE)*32767).to_i }
For the bracket thing, well, in RMasm, referencing address is going to be standardized as [] for all assemblers...
so, an OO and interpreted assembler language, or what?
whynot200: More like an OO and interpreted preprocessor for ye oldie assembler if I understand it right.
@gasman: by the way, It might be worth for RMasm to try to work first on a processor like z80 that is much easier to develop than x86. Working from a PC, what would the easiest z80 platform to target and to test with an emulator?
@masterm: yep, it's a kind of OO preprocessor and an assembler, all together.
@masterm: yep, it's a kind of OO preprocessor and an assembler, all together.
@@lx: Amstrad CPC!
hey rouq! Well, go for amstrad cpc, i worked 20 years ago coding some z80 asm in hexa in basic... that would be a great revenge! ;)
The concept reminds me a bit of Kick Assembler (6502 assembler with Java preprocessor macros). I'm no x86 coder, but it could definitely be very useful!
6510 that is
Woo, thanks linde, this is a useful information here, the doc from kick assembler is impressive, and 6510 seems to be even more simpler then z80. seems that I'm gonna have to look at c64 emulators as well....
Me thinks the _offset_ keyword turns me down. :)
@lx: easy-to-dev-for z80 platforms: SEGA Master System / Game Gear.
gasman: For things like "put a 256-byte sine table in the middle of my code", I think SjASMPlus allows you to do just that, albeit with Lua
@lx As for best Z80 platform for targeting and testing with an emulator on a PC, your best bet would probably be MSX. I would say ZX Spectrum for easiest to develop for, but most of the emulators I've been able to come across are pretty much shit. (Feel free to point me to a good one I may have missed, anyone)
iconoclaST: ZXSpin is pretty damn good. It's got some quirks and the debugger can be a real pain sometimes, but it's better than nothing. Emuzwin is another good one with a very impressive debugger. I use ZXSpin myself. Both are Windows btw.. I cannot recommend anything for OSX (some exist, but I cannot say that they are any good) and I have no experience of other platforms.
btw, a somewhat similar (but in many aspect pretty different) thing is harpy, which is x86 assembly embedded into haskell as a DSL. It is a JIT compiler, but anyway you can use the full power of the haskell language to generate machine code, so in this sense it is pretty close.
make sure you have builtin functionality to display/convert number formats (floating-/fixed-point bin/hex/oct.. bla)
Quote:
so in your estimation, about how large is the intersection of sceners, asm coders and ruby programmers? (or isn't that your target audience?)
I guess the target audience is simply "asm coders".
I've been tinkering with selfmade assemblers aswell, and have thought about doing it in Ruby in a similar way. I gave up for reasons such as the "ld (hl),a" problem mentioned by gasman above.
You could of course go and use brackets instead of parentheses, but anybody who knows the Z80 is used to parentheses and isn't going to use an assembler where he has to use brackets instead :D
And while I like Ruby I'd refuse to use an assembler where I have to write colons in front of symbol names because you're really referring to a Ruby symbol.