view docs/manual/x32.html @ 416:b4d0eafc5bfe

Fix code generation error in gcc6809 It turned out that under some circumstances, the gcc optimizer would select an instruction sequence that had the sense of a branch inverted. It seems this was due to a particular instruction pattern included in the machine description not being quite right with respect to how the condition codes were tracked. Removing that instruction pattern seems to fix things (subtraction with the arguments reversed). gcc seems to be smart enough to figure out how to reorganize code to work without this reversed sense subtraction and then do the right thing.
author William Astle <lost@l-w.ca>
date Thu, 24 Mar 2016 20:07:20 -0600
parents b30091890d62
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
>ASCII Hexadecimal</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="Output Formats"
HREF="c21.html"><LINK
REL="PREVIOUS"
TITLE="DECB Binaries"
HREF="x27.html"><LINK
REL="NEXT"
TITLE="Motorola S-Record"
HREF="x36.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="x27.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
>Chapter 2. Output Formats</TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="x36.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECTION"
><H1
CLASS="SECTION"
><A
NAME="AEN32"
>2.3. ASCII Hexadecimal</A
></H1
><P
>This human-readable ASCII hexadecimal format consists of CR+LF terminated 
lines of ASCII text. Each line has the following structure: a zero-padded 
four-digit ASCII hex address, a colon separator, and one or more zero-padded
two-digit hex values separated by commas. ASCII Hexadecimal format favors 
paragraph-aligned addresses (i.e. a least significant address nybble value
of zero). During output, the number of hex values on each line are adjusted
to align the address of the next line on a paragraph boundary. The sequence 
of addresses in the ASCII Hexadecimal file directly follows that of the source
file; multiple ORG directives in the source code may result in out-of-sequence
addresses in the ASCII Hexadecimal output.</P
><P
>LWASM can output this format since version 4.10.</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="x27.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="x36.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>DECB Binaries</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="c21.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Motorola S-Record</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>