|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| sachinc (2) | |
|
Hi, i have started working on writing a assembler and need to write Lex/YACC grammar for the same. i was looking for some already existing grammar for any assembly language so that i can take some help from it. Thanks sachin | |
|
|
|
| helios (9408) | |
| Come on, it's not like Assembly is that hard to parse. It'd probably take you longer to look for the grammar file than to write it yourself. | |
|
|
|
| Abramus (170) | |||||||
|
Since I was a little bored, I decided to write a simple parser, with a few instructions only. I hope it will help you. scanner (flex):
parser (bison):
example source file:
EDIT: I agree with helios, I took me like 5 minutes to write this parser. | |||||||
|
Last edited on
|
|||||||
| PanGalactic (1558) | |
| GNU as supports Z-80 assembler which is a close relative of the 8085. I'd bet you could lift it from there as long as you don't mind licensing your code under the GPL. | |
|
|
|
| helios (9408) | |
| Don't you think it'd be better to condense all instruction_* into a single non-terminal instruction that holds the string? | |
|
|
|
| Abramus (170) | |
|
I'm not sure I understood you helios, but if you suggests that scanner shouldn't detect the exact type of instruction then I don't agree because then: 1) I will have to use IDENTIFIER for both instructions and labels, which is ugly, 2) I will have to verify that arguments of every instruction are correct, and it's better when parser does it, 3) most probably scanner would detect type of instruction much faster than me. Basically I think that it's best to do as much work as possible in scanner/parser. I know that a huge list of instruction doesn't look nice, but you must place this list somwhere. | |
|
|
|
| helios (9408) | |
|
I guess we just have different opinions on how to write our languages. I prefer to leave the parser as little responsibility as possible. 1. If you think about it, they both are identifiers. I only need to change the syntax to demonstrate it: mov(eax,10) 2. I think the parser should only resolve the structure of the code. Checking that the structure makes sense should be left for whatever comes next. There's also the problem that changes such as adding a new instruction or adding more operands to an instruction don't (or shouldn't) constitute a language change. For example, you don't need to rebuild a C compiler if you decide to change memset(). | |
|
|
|
| Abramus (170) | |
|
1) OK, I agree. 2) But the parser resolves the structure of the code only. I think of assembler instructions as of something similar to C++ keywords/operators. When an instruction doesn't have one of operands, it's like a C++ operator wouldn't have one of operands. It's a syntax error which should be detected by the parser. I agree that the compiler needs to be re-compiled (haha) every time you want to add or change an instruction. But seriously, would you really make an assembler compiler to use an external definition of available instructions? I think that both approaches have their advantages and disadvantages. I just tend to like mine a little more... | |
|
|
|
| helios (9408) | |||
| |||
|
|
|||
| Abramus (170) | |||
| |||
|
|
|||
| helios (9408) | |
|
Yes, but I don't need to regenerate the parser, which is what I meant when I said "language" earlier. The syntax. Although now that you mention it, an external instruction table doesn't sound so bad. Think about it. You could use the same assembler to generate code for any processor. | |
|
|
|
| Abramus (170) | |
|
Yes, you're right. This actually could work pretty well. Of course, nothing comes without a price. In this case it would be a need to implement the second parser, which processes the provided table, and creates the appropriate rules for instructions. Simple in theory, but probably a lot of work to really support all processors. I think for example about addressing modes in x86 - a lot of different combinations, which must be handled. However, the idea seems to be interesting. | |
|
|
|