Mercurial > hg > index.cgi
view docs/manual/x227.html @ 418:3832a68d83ef
Fix internal compiler error on "var2 = var1 + 1" patterns
This appears to be the correct fix. It was provided by Tormod Volden
(debian.tormod@gmail.com). The final commit is substantially different from
Tormod's submission mostly due to housecleaning (removing the old patches
and updating the README). Tormod's comments follow.
The original addhi_mem_1 "insn" instruction pattern /matches/ two
memory operands, just with the /constraint/ that these are the same
location. A pattern match tells the compiler "you should be able to use
this, but you might have to work on it to meet the constraints". For
typical constraints on registers the compiler can add "reloads", moving
stuff between registers or from memory, until the constraints are met
and the instruction can be used. However, in this case, no amount of
reloads can make two memory locations the same if they already weren't,
so the compiler breaks down and cries "unable to generate reloads".
It seems this issue only appears if optimization is enabled. The proof
is in gcc's reload.c and is left as an exercise to the reader.
Limiting the matching pattern to identical memory operands avoids
these situations, while allowing the common "var++" cases.
References:
The pattern/constraints difference is explained in
https://gcc.gnu.org/onlinedocs/gccint/Simple-Constraints.html#index-other-register-constraints-3335
author | William Astle <lost@l-w.ca> |
---|---|
date | Tue, 29 Mar 2016 21:21:49 -0600 |
parents | fc166b3bbae3 |
children |
line wrap: on
line source
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd"> <HTML ><HEAD ><TITLE >Source Format</TITLE ><META NAME="GENERATOR" CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK REL="HOME" TITLE="LW Tool Chain" HREF="index.html"><LINK REL="UP" TITLE="LWASM" HREF="c62.html"><LINK REL="PREVIOUS" TITLE="Dialects" HREF="x218.html"><LINK REL="NEXT" TITLE="Symbols" HREF="x237.html"></HEAD ><BODY CLASS="SECTION" BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#840084" ALINK="#0000FF" ><DIV CLASS="NAVHEADER" ><TABLE SUMMARY="Header navigation table" WIDTH="100%" BORDER="0" CELLPADDING="0" CELLSPACING="0" ><TR ><TH COLSPAN="3" ALIGN="center" >LW Tool Chain</TH ></TR ><TR ><TD WIDTH="10%" ALIGN="left" VALIGN="bottom" ><A HREF="x218.html" ACCESSKEY="P" >Prev</A ></TD ><TD WIDTH="80%" ALIGN="center" VALIGN="bottom" >Chapter 3. LWASM</TD ><TD WIDTH="10%" ALIGN="right" VALIGN="bottom" ><A HREF="x237.html" ACCESSKEY="N" >Next</A ></TD ></TR ></TABLE ><HR ALIGN="LEFT" WIDTH="100%"></DIV ><DIV CLASS="SECTION" ><H1 CLASS="SECTION" ><A NAME="AEN227" >3.3. Source Format</A ></H1 ><P >LWASM accepts plain text files in a relatively free form. It can handle lines terminated with CR, LF, CRLF, or LFCR which means it should be able to assemble files on any platform on which it compiles.</P ><P >Each line may start with a symbol. If a symbol is present, there must not be any whitespace preceding it. It is legal for a line to contain nothing but a symbol.</P ><P >The op code is separated from the symbol by whitespace. If there is no symbol, there must be at least one white space character preceding it. If applicable, the operand follows separated by whitespace. Following the opcode and operand is an optional comment.</P ><P > It is important to note that operands cannot contain any whitespace except in the case of delimited strings. This is because the first whitespace character will be interpreted as the separator between the operand column and the comment. This behaviour is required for approximate source compatibility with other 6x09 assemblers. </P ><P >A comment can also be introduced with a * or a ;. The comment character is optional for end of statement comments. However, if a symbol is the only thing present on the line other than the comment, the comment character is mandatory to prevent the assembler from interpreting the comment as an opcode.</P ><P >For compatibility with the output generated by some C preprocessors, LWASM will also ignore lines that begin with a #. This should not be used as a general comment character, however.</P ><P >The opcode is not treated case sensitively. Neither are register names in the operand fields. Symbols, however, are case sensitive.</P ><P > As of version 2.6, LWASM supports files with line numbers. If line numbers are present, the line must start with a digit. The line number itself must consist only of digits. The line number must then be followed by either the end of the line or exactly one white space character. After that white space character, the lines are interpreted exactly as above. </P ></DIV ><DIV CLASS="NAVFOOTER" ><HR ALIGN="LEFT" WIDTH="100%"><TABLE SUMMARY="Footer navigation table" WIDTH="100%" BORDER="0" CELLPADDING="0" CELLSPACING="0" ><TR ><TD WIDTH="33%" ALIGN="left" VALIGN="top" ><A HREF="x218.html" ACCESSKEY="P" >Prev</A ></TD ><TD WIDTH="34%" ALIGN="center" VALIGN="top" ><A HREF="index.html" ACCESSKEY="H" >Home</A ></TD ><TD WIDTH="33%" ALIGN="right" VALIGN="top" ><A HREF="x237.html" ACCESSKEY="N" >Next</A ></TD ></TR ><TR ><TD WIDTH="33%" ALIGN="left" VALIGN="top" >Dialects</TD ><TD WIDTH="34%" ALIGN="center" VALIGN="top" ><A HREF="c62.html" ACCESSKEY="U" >Up</A ></TD ><TD WIDTH="33%" ALIGN="right" VALIGN="top" >Symbols</TD ></TR ></TABLE ></DIV ></BODY ></HTML >