Autoamtically resolve "multiple matches with the same output size" errors about customasm HOT 2 OPEN

Hmm, I think it's important that the assembler doesn't choose any one rule based on order -- in the future it would allow for new optimizations.

Do you have an example of an instruction set where such a pair of instructions came up? Identical in function and mnemonic? It feels like whenever there's a pair like that, you could simplify it down to a single instruction without conflicts. Or maybe there's something I'm not anticipating.

from customasm.

68k assembly is a good example for an Instruction set that has a lot of different instructions doing the same exact thing.

various Arimethic/Logic Instructions have 2 operands, one of which is "hardwired" for the specific instruction, while the 2nd Operand can be choosen from a list of aviable addressing modes.
for example, ADD has 3 different basic instructions:

one where 1 operand is always a Data Register, one where 1 Operand is always an Address Register, and one where 1 Operand is always an Immediate Value.
but the available addressing modes also include Data/Address Registers, and Immediate Data.
take the first ADD Instruction for example, as its possible Addressing modes for the second Operand you can choose an Address Register or an Immediate Value (among other actual Memory accessing modes)
so it's immosible to know if ADD D0, #42 is a Data ADD using the Immediate Addressing Mode, or an Immediate ADD using the Data Register Addressing Mode, as both are equally valid in this case.

this kind of overlap is everywhere in the 68k.
obviously they thought of that and technically ADD is always uses Data Registers, ADDA always usesAddress Registers, and ADDI always uses Immediate Data, etc.
but pretty much any 68k Assembler will accept you just using "ADD" for everything and does the actual choosing of which instruction to use on it's own.
so i wanted to do the same in CustomASM as well.

Hmm, I think it's important that the assembler doesn't choose any one rule based on order -- in the future it would allow for new optimizations.

even if it's a fully optional commandline parameter or a #prioritze top/bottom/random directive you throw into your CPU definition?

from customasm.