Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Autoamtically resolve "multiple matches with the same output size" errors #121

Open
ProxyPlayerHD opened this issue Oct 18, 2021 · 2 comments

Comments

@ProxyPlayerHD
Copy link

Title says it, some Instruction Sets just happen to have different instructions that do the same thing and can potentially share the same mnemonic.

so i feel like the Assembler should have an option to simply pick one matching instruction (for example, the last match encountered) and just print these errors out as warning instead.

@hlorenzi
Copy link
Owner

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.

@ProxyPlayerHD
Copy link
Author

ProxyPlayerHD commented Oct 21, 2021

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants