RMasm, an upcoming assembler for demo coding?
category: general [glöplog]
Quote:
For the bracket thing, well, in RMasm, referencing address is going to be standardized as [] for all assemblers...
OK...and what do you do about dialects where a # is used to distinguish immediate values from memory addresses? You'd have to invent yet another non-standard replacement, don't you?
Btw, the sine table thing could be easily done using Ruby's ERB class. I've never used it so far, but next time I need a sine table I'll look into it.
Quote:
For the bracket thing, well, in RMasm, referencing address is going to be standardized as [] for all assemblers...
That'd be ok for x86. But for most other processors' assembly languages it's standard to use () when addressing memory, and changing a fundamental part of the syntax probably isn't going to be popular.
And there are cases where both [] and () are used, with different meanings. For example 65816.
Quote:
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.
I found the symbol type in Ruby quite close to the symbol term used in assemblers (a label is a symbol, a procedure name is a symbol... and so on). This is really interesting to use it because you are able also to distinguish them from procedures, methods...
Quote:
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
You are right, it's not going to be acceptable for the majority of "hardcore" coders. But some may find that the tradeoff is fine, since you get a "macro" language that is much more powerful than whatever assembler you have today... and well, RMasm is also not intended to be an universal assembler!
For the immediate #, yes, this is an issue. I'm currently working on the 6510 syntax and i have to use a workaround, something like prefix immediate value by letter "i" or "ix" (for hexa), like i125 ixFF , but again, it's not going to be everyone's taste, i agree.
At least, it's going to match almost perfectly x86 syntax and this is my main target.
Thanks for the feedback.
cool idea. make enough macros to support c syntax and optimization, and you've an integrated asm/compiler/macrosystem/ide.
syntax-wise, another way to get around the [] and # thigns is to try to preprocess the file before evaluating it with ruby. but that probably requires either a full-fledged ruby-plus-your-additions parser or a very ugly hack. but it would be nice :)
syntax-wise, another way to get around the [] and # thigns is to try to preprocess the file before evaluating it with ruby. but that probably requires either a full-fledged ruby-plus-your-additions parser or a very ugly hack. but it would be nice :)
