<p>Suppose somebody completely misunderstands how assembly language works and, instead of writing:</p>
<pre><code>load s1, s2
load s0, s1
</code></pre>
<p>He writes:</p>
<pre><code>load (load s0, s1), s2
</code></pre>
<p>How do you output a proper error message in that case?</p>
<p>For this invalid program:</p>
<pre><code>address 0
load (load s0, s1), s2
</code></pre>
<p>The assembler in my <a href="https://picoblaze-simulator.sourceforge.io/" rel="nofollow noreferrer">PicoBlaze Assembler and Emulator in JavaScript</a> outputs this error message:</p>
<pre><code>Internal compiler error: The assembly-lanaguage expression in line 2 doesn't end with a new-line token!
</code></pre>
<p>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?</p>

<parsing><assembly>
How to provide a sensible error message for `load (load s0, s1), s2` when parsing assembly?
CC BY-SA 4.0
2023-10-27T13:03:27.867Z
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.)
Ginger
CC BY-SA 4.0
2023-10-27T13:05:09.950Z
Also, what do you mean by a "proper error message"? I believe specifying that would help refine the scope of the question.
lyxal
CC BY-SA 4.0
2023-10-27T14:24:59.350Z
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.
Erik Eidt
CC BY-SA 4.0
2023-10-31T20:32:04.897Z
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.
Barmar
CC BY-SA 4.0
2023-11-02T15:14:42.263Z
"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*?
Karl Knechtel
<p>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.</p>
<p>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 <em>usually</em> 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.</p>
<p>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.</p>
<p>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.</p>

CC BY-SA 4.0
2023-10-27T15:00:23.947Z
2023-10-27T15:00:23.947Z
feldentm
# How to provide a sensible error message for `load (load s0, s1), s2` when parsing assembly?
Posted by: username_0 on 2023-10-27
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?
**Tags:** parsing assembly
> **Comments:**
> **username_1**: 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.)  
> **username_2**: Also, what do you mean by a "proper error message"? I believe specifying that would help refine the scope of the question.  
> **username_3**: 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.  
> **username_4**: 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.  
> **username_5**: "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*?  
---
## 1 answers
### Answer by username_6 on 2023-10-27. Score: 3
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.
---
