-2
$\begingroup$

Suppose somebody completely misunderstands how assembly language works and, instead of writing:

load s1, s2
load s0, s1

He writes:

load (load s0, s1), s2

How do you output a proper error message in that case?

For this invalid program:

address 0
load (load s0, s1), s2

The assembler in my PicoBlaze Assembler and Emulator in JavaScript outputs this error message:

Internal compiler error: The assembly-lanaguage expression in line 2 doesn't end with a new-line token!

The user is unlikely to understand what his error was from that error message. So, how can I detect such situations (where somebody tries to embed one assembly language instruction into another) in the parser and warn about them?

$\endgroup$
5
  • 4
    $\begingroup$ This seems to be asking two questions: "How do I warn about this situtation?" and "How do I detect this situation?" You'll get better answers if you refine it to just one of the two. (I think the second one's more interesting, but that's just me.) $\endgroup$
    – Ginger
    Commented Oct 27, 2023 at 13:03
  • $\begingroup$ Also, what do you mean by a "proper error message"? I believe specifying that would help refine the scope of the question. $\endgroup$
    – lyxal ♦
    Commented Oct 27, 2023 at 13:05
  • 1
    $\begingroup$ If you're looking for a register or addressing mode as the first operand for load, you can say that as the error message, i.e. first operand must be a register. $\endgroup$
    – Erik Eidt
    Commented Oct 27, 2023 at 14:24
  • $\begingroup$ It seems like you could have a parser production that recognizes recursive statements, and leads to error code that has a message specific to this. $\endgroup$
    – Barmar
    Commented Oct 31, 2023 at 20:32
  • $\begingroup$ "Suppose somebody completely misunderstands how assembly language works" - that's the thing: it doesn't inherently work in one specific way. For example, there could be different conventions for the order of source and destination arguments. If you simply mean that a bracketed expression like (load s0, s1) shouldn't be permissible as an argument for load - think carefully about why not. For example, would you allow other parenthesized expressions in this position? Would you allow parenthesized expressions anywhere in the assembly? $\endgroup$
    – Karl Knechtel
    Commented Nov 2, 2023 at 15:14

1 Answer 1

Reset to default
3
$\begingroup$

It does not make sense to treat a compiler for assembly language any different from compilers for languages with more and other means of abstraction. Hence, all answers for arbitrary compilers apply.

Depending on the regularity of your assembly language, you could choose between parse errors and semantic errors in a syntax category. Based on my experience with assembly, I would use the parse errors, i.e. I would define the grammar in a way that will make the generated parser reject it. The pro about this approach is that it usually results in nice errors for very regular languages with little to none usage of nesting and context sensitive parse rules. It is also the least effort wrt. to implementation time.

The second option is to make the Parser and AST generation accept code like in your example. This obviously did not happen in your reference implementation, because doing so results in a valid AST. The error is then produced by some semantic analysis phase done on the AST; likely some sort of parameter checking that is equivalent to type checking of function parameters.

EDIT: What might not be apparent if nobodoy told you is that grammars often have multiple forms of expression that encoding nesting rules. Tyr, for instance, has simple expressions and expressions. It could be that your assembly language's grammar should have at least a statement concept if nesting of statements is not allowed.

$\endgroup$

Not the answer you're looking for? Browse other questions tagged .