cj7hawk
Veteran Member
I would suggest that you want macros to take preference over internal mnemonics. There can be good reasons for wanting to "replace" a mnemonic, and allowing the user to do that does not remove other functionality, since doing so is completely optional.
It would be very inefficient on a z80 based system to search up to 50K of label space before decoding opcodes but could be done with a command line switch... Can you give me an example where you would want to replace an existing functional opcode with a macro, yet still have it look the same? If I can understand the context, I might be able to improve on the concept.
This sounds awkward and unnecessary. Unless I've missed something about Z80 assembly language you can always tell from context whether an instruction, location or a register name is required for any particular value, so there's no need to have instruction mnemonics or register names taking up label space or interfering with user labels.
Because when I am looking for the pattern, it's easy to remember, eg;
; Opcodes;
LD: DB 2,'LD'
PUSH: DB 4,'PUSH'
POP: DB 3,'POP'
EX: DB 2,'EX'
EXX: DB 3,'EXX'
LDI: DB 3,'LDI'
LDIR: DB 4,'LDIR'
LDD: DB 3,'LDD'
LDDR: DB 4,'LDDR'
CPI: DB 3,'CPI'
CPIR: DB 4,'CPIR'
CPD: DB 3,'CPD'
CPDR: DB 4,'CPDR'
ADD: DB 3,'ADD'
ADC: DB 3,'ADC'
SUB: DB 3,'SUB'
SBC: DB 3,'SBC'
AND: DB 3,'AND'
OR: DB 2,'OR'
XOR: DB 3,'XOR'
CP: DB 2,'CP'
INC: DB 3,'INC'
DEC: DB 3,'DEC'
DAA: DB 3,'DAA'
CPL: DB 3,'CPL'
NEG: DB 3,'NEG'
CCF: DB 3,'CCF'
SCF: DB 3,'SCF'
NOP: DB 3,'NOP'
HALT: DB 4,'HALT'
DI: DB 2,'DI'
EI: DB 2,'EI'
IM: DB 2,'IM
'It's just how I wrote the decoder in my case. Not the most efficient way in retrospect, but works well enough and is easy to edit and read back in my code.
Decimal numbers are evaluated before label values. There's a precedental order.How do you distinguish between 12 as a number indicating a location and as a label defined as, e.g., 12 equ 456?
But 12_ and _12 would be valid. ( As examples ). And some invalid decimal numbers would be legitimate.
There are few assemblers out there that do not allow any non-alphanumerics, and I doubt that there are any for microprocessors that do not allow underscore and several others
Have you defined character sets for your assemblers. In particular, I would expect a cross assembler running on a modern system to accept Unicode (typically UTF-8) input, and correctly determine which non-ASCII characters are alphabetic. I don't know if I've ever used accented characters in labels (e.g., ârret), but I've definitely used Greek letters, and have regularly wanted to use the prime characters.
It's intended for 8 bit systems circa 1985, so unicode isn't relevant to my project. I hadn't considered other character sets, but limit the code to 7 bit ASCII common to CP/M, though of course it handles data as data. The cross-assembler won't be any different since 8 bit systems don't handle unicode, but IIRC most programmers in those cases use romanized expressions. The character set supports some greek letters, but generally I wouldn't count on that for US-ASCII systems or cp/m systems.
This sounds overly complex and confusing compared to just having scopes and simple scoping rules.
The user *can* do that - I just don't enforce it. And translatory labels is a convenient medium. Besides, the example you list is over 100 times larger than my assembler - even without the graphics interface, and runs on computers more than a million times faster than my target architecture. I still have to be mindful that I intend this to run as a CP/M application primarily.
Not older ones. Not even for Macro Assembler, which couldn't even chain them.Nesting macros is pretty much a basic requirement of any modern macro-assembler.
However I really liked the arguments presented about why they *should* and I can't disagree, so I'm adding the functionality.
As I mentioned, that's entirely possible. You just declare them with EQUs or SETs in the MACRO - which is only syntactically different from declaring them elsewhere. I do it that way for memory and performance reasons.That sounds confusing, too. Why not just do what any sensible programming language does and have the user provide a formal parameter list for the macro or function, and to these symbols bind the argument values supplied at the call site?
And as mentioned, I don't enforce it, so you can just reference it directy, and you face the same risks as you do in other languages when you choose to do it that way.
The programmer can decide which way they prefer. Both are supported. Are there examples you can think of where both ways shouldn't be supported?
As we all said: if you're writing two separate versions of the assembler, they will be different assemblers.
Well, yes, they are a native assembler and a cross assembler. With a common syntax, and paired releases. And can reasonably be expected to produce the same binaries, at least as well as multiple revisions of the same assembler should.
Yes, this is a very common thing to do. It's also normal in these files to use conditional assembly to allow the client (the program including SYSTEM.ASM or whatever) to configure exactly what the included file will generate.
I've honestly never seen that before - with a set of the assembly routines and an assembler and editor included on the boot disk for exactly that purpose. I'd love to hear about other systems that did the same to find out how well used it was and how the users perceived it -I can't imagine it was a particularly common architecture and I wouldn't do it either if I didn't plan on having a ROM based bootdisk.
The BBC BASIC was the closest I could find to that previously, where you could type in assembly from the OS or in basic.
If the included file creates macros, then there is no need for conditional assembly outside of memory management. If the macro isn't called, the code isn't generated. Though I'd definitely use conditional assembly flags on library files if included.