yacc conflicts about rgbds HOT 7 CLOSED

I would add:

charmap:
T_POP_CHARMAP string ',' string
| T_POP_CHARMAP string ',' const
;

(const produces string)

Cases 2 and 3 cause reduce/reduce conflicts that are correctly handled but reduce/reduce conflicts should really be solved explictly.

This could be done by detaching the string productions like this:

const:
const_n { $$ = $1; }
| string { $$ = str2int($1); }
;

const_n:
(original const without string production)
;

Then, use const_n instead of const in charmap.

Do the same for relocconst and const_8bit.

Case 1 causes a shift/reduced conflict that is correctly solved. This conflict is controlled and could be left as is.

We could solve cases 1, 2 and 3 by associating a struct value to const and relocconst instead of a numeric value to allow ids, strings and numerical values to be "returned" and then use function calls to convert this struct to int where required.

from rgbds.

Here are two other conflicts - at first sight - due to grammar ambiguities:

• T_Z80_LD T_MODE_SP comma const_16bit is produced by z80_ld_ss and z80_ld_sp
  (and generate the same code of course)
• T_Z80_LD T_MODE_HL comma const_16bit is produced by z80_ld_ss and z80_ld_hl

z80_ld_ss:
    T_Z80_LD reg_ss comma const_16bit
    ;

z80_ld_sp:
    T_Z80_LD T_MODE_SP comma T_MODE_HL
    | T_Z80_LD T_MODE_SP comma const_16bit
    ;

z80_ld_hl:
    T_Z80_LD T_MODE_HL comma '[' T_MODE_SP const_8bit ']'
    | T_Z80_LD T_MODE_HL comma T_MODE_SP const_8bit
    | T_Z80_LD T_MODE_HL comma const_16bit
    ;

reg_ss:
    T_MODE_BC
    |   T_MODE_DE
    |   T_MODE_HL
    |   T_MODE_SP
    ;

Removing the redundant rules won't solve the conflicts because in fact this part
of the grammar is not LALR(1) (and not even LR(1)):

e.g.: for z80_ld_sp:
shift/reduce conflict on ','

  324 z80_ld_sp: T_Z80_LD T_MODE_SP . comma T_MODE_HL
  393 reg_ss: T_MODE_SP .

There is no enough lookahead information to determine if the parser are recognizing the generic productions (T_Z80_LD reg_ss comma...)
or the specific ones (T_Z80_LD T_MODE_SP comma ...).
Note that replacing the 'comma' non-terminals by terminal tokens (',') would not change anything.

A solution is to use reg_ss in the specific rules and test if reg_ss is well a T_MODE_SP or T_MODE_HL.
Or let it as is as these conflicts are controlled.

from rgbds.

The last one mentioned by @chastai has been fixed in 362aea2

from rgbds.

There is only one conflict not mentioned here.

line		: label
		| label cpu_command
		| label macro
		| label simple_pseudoop
		| pseudoop
;

label		: /* empty */
		| T_LABEL
		| T_LABEL ':'
		| T_LABEL ':' ':'
;

pseudoop	: equ
		| set
		| rb
		| rw
		| rl
		| equs
		| macrodef
;

set		: T_LABEL T_POP_SET const
;

cpu_command	: 
		/* ... */
		z80_set
		/* ... */
;

z80_set		: T_POP_SET const_3bit comma reg_r
;

If the parser encounters T_LABEL T_POP_SET at the beginning of a line, it's ambiguous whether it should use line -> label cpu_command -> label z80_set or line -> pseudoop -> set. Bison resolves it as the latter.

This means that x set 5 works, but label1 set 1, a doesn't. That is preferable to the other way around, since the set pseudo-op would not be usable in that case. It would be nice if it could parse both, but that would require extra look-ahead. The workaround is to use a colon after the label (label1: set 1, a).

from rgbds.

I have no experience in YACC, but there appears to be one more shift/reduce in asmy.y:

Terminals unused in grammar

   T_POP_ENDM
   T_POP_ENDR


State 5 conflicts: 1 shift/reduce

from rgbds.

Yeah, there are a couple more. Here are the two problems we currently have:
sym rl N can either be the RL instruction, or the pseudo-op from the _RS group. (This causes #322.)
Then there is sym set N, which can similarly be either creating the read-write constant sym, or the beginning of instruction set. (Discussed by @dbrotz's above message)

Both are technically not ambiguous, but require two (RL) or three (SET) tokens of lookahead, when yacc only has one. This is intended to be fixed by #457, since the ambiguity is caused by colon-less labels.

Also, the two unused terminals are intended, the lexer doesn't read them (macro/rept management is whack) but they're still reserved keywords.

from rgbds.

Since colon-less labels have been removed (removing the set ambiguity) and rl as a declarator has been reinstated (closing #322), we no longer have any conflicts or grammar issues.

from rgbds.