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
>