<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>P-Series中的主题 P1011 : simple precision floatting multiplication</title>
    <link>https://community.nxp.com/t5/P-Series/P1011-simple-precision-floatting-multiplication/m-p/811291#M4518</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hello,&lt;/P&gt;&lt;P&gt;in the E500CORERM, I can read the following for double floatting point operation:&lt;/P&gt;&lt;P&gt;&lt;SPAN style="font-size: 13.0pt;"&gt;"Additionally, an implementation may also signal overflow by comparing the exponents of the&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN style="font-size: 13.0pt;"&gt;operands. In this case, the hardware examines both exponents ignoring the fractional values. If it&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN style="font-size: 13.0pt;"&gt;is determined that the operation to be performed may overflow (ignoring the fractional values), an&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN style="font-size: 13.0pt;"&gt;overflow may be said to occur."&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN style="font-size: 13.0pt;"&gt;I'm using a simple floatting point operation (multiplication) but it seems I have the same behaviour as with double:&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN style="font-size: 13.0pt;"&gt;the assembly operation is efsmul r5,r0,r5&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN style="font-size: 13.0pt;"&gt;with r0=0x40A00000 and r5=0x7E05A364&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN style="font-size: 13.0pt;"&gt;the obtained result in target is r5=0x7F7FFFFF instead of 0x7F270C3D while it is correct in simulation&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN style="font-size: 13.0pt;"&gt;Does anyone knows if there is any errata/issue/known limitation that could explain this behaviour ?&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN style="font-size: 13.0pt;"&gt;Thanks&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN style="font-size: 13.0pt;"&gt;Paulo.&lt;/SPAN&gt;&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Fri, 13 Jul 2018 14:46:54 GMT</pubDate>
    <dc:creator>paulodasilvapin</dc:creator>
    <dc:date>2018-07-13T14:46:54Z</dc:date>
    <item>
      <title>P1011 : simple precision floatting multiplication</title>
      <link>https://community.nxp.com/t5/P-Series/P1011-simple-precision-floatting-multiplication/m-p/811291#M4518</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hello,&lt;/P&gt;&lt;P&gt;in the E500CORERM, I can read the following for double floatting point operation:&lt;/P&gt;&lt;P&gt;&lt;SPAN style="font-size: 13.0pt;"&gt;"Additionally, an implementation may also signal overflow by comparing the exponents of the&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN style="font-size: 13.0pt;"&gt;operands. In this case, the hardware examines both exponents ignoring the fractional values. If it&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN style="font-size: 13.0pt;"&gt;is determined that the operation to be performed may overflow (ignoring the fractional values), an&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN style="font-size: 13.0pt;"&gt;overflow may be said to occur."&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN style="font-size: 13.0pt;"&gt;I'm using a simple floatting point operation (multiplication) but it seems I have the same behaviour as with double:&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN style="font-size: 13.0pt;"&gt;the assembly operation is efsmul r5,r0,r5&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN style="font-size: 13.0pt;"&gt;with r0=0x40A00000 and r5=0x7E05A364&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN style="font-size: 13.0pt;"&gt;the obtained result in target is r5=0x7F7FFFFF instead of 0x7F270C3D while it is correct in simulation&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN style="font-size: 13.0pt;"&gt;Does anyone knows if there is any errata/issue/known limitation that could explain this behaviour ?&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN style="font-size: 13.0pt;"&gt;Thanks&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN style="font-size: 13.0pt;"&gt;Paulo.&lt;/SPAN&gt;&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 13 Jul 2018 14:46:54 GMT</pubDate>
      <guid>https://community.nxp.com/t5/P-Series/P1011-simple-precision-floatting-multiplication/m-p/811291#M4518</guid>
      <dc:creator>paulodasilvapin</dc:creator>
      <dc:date>2018-07-13T14:46:54Z</dc:date>
    </item>
    <item>
      <title>Re: P1011 : simple precision floatting multiplication</title>
      <link>https://community.nxp.com/t5/P-Series/P1011-simple-precision-floatting-multiplication/m-p/811292#M4519</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;&lt;SPAN style="font-size: 10.0pt; color: black;"&gt;Check the &lt;/SPAN&gt;&lt;SPAN style="font-size: 10.0pt;"&gt;SPEFSCR register. It looks like that the FINXS and FOVF bits are set after this operation.&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;BR /&gt;Have a great day,&lt;BR /&gt;Pavel Chubakov&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;-----------------------------------------------------------------------------------------------------------------------&lt;BR /&gt;Note: If this post answers your question, please click the Correct Answer button. Thank you!&lt;BR /&gt;-----------------------------------------------------------------------------------------------------------------------&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Mon, 23 Jul 2018 04:34:26 GMT</pubDate>
      <guid>https://community.nxp.com/t5/P-Series/P1011-simple-precision-floatting-multiplication/m-p/811292#M4519</guid>
      <dc:creator>Pavel</dc:creator>
      <dc:date>2018-07-23T04:34:26Z</dc:date>
    </item>
    <item>
      <title>Re: P1011 : simple precision floatting multiplication</title>
      <link>https://community.nxp.com/t5/P-Series/P1011-simple-precision-floatting-multiplication/m-p/811293#M4520</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Sorry to not have answer sooner.&lt;/P&gt;&lt;P&gt;I've checked the SPEFSCR register and when I configured it to generate an overflow exception, the exception is raised. And when I configure it to not generate the overflow exception, then no exception is raised and r5 is set with a result of&amp;nbsp;&lt;SPAN style="color: #51626f; background-color: #ffffff;"&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;r5=0x7F7FFFFF instead of r5=0x7F270C3D&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;I've tried with another evaluation board and I've reproduced the problem. As a matter of fact, I'm not surprised that an exception is raised when you perform an overflow operation by configuring correctly the SPEFSCR register. Where I am surprised is that it generates an exception for an operation and operands which result shall not lead to an overflow.&amp;nbsp;&lt;/P&gt;&lt;P&gt;Do you have any errata on this microcontroller that could explain the observed overflow when it should not happen ?&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Best regards&amp;nbsp;&lt;/P&gt;&lt;P&gt;Paulo&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 17 Aug 2018 07:40:50 GMT</pubDate>
      <guid>https://community.nxp.com/t5/P-Series/P1011-simple-precision-floatting-multiplication/m-p/811293#M4520</guid>
      <dc:creator>paulodasilvapin</dc:creator>
      <dc:date>2018-08-17T07:40:50Z</dc:date>
    </item>
  </channel>
</rss>

