<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://community.arm.com/utility/feedstylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>unexpected results in integer arithmetics</title><link>https://community.arm.com/developer/tools-software/tools/f/keil-forum/15227/unexpected-results-in-integer-arithmetics</link><description> Hello experts, 
 
to avoid a division, I use integer arithmetics. The unsigned int x which is in the range of 2000 is first multiplied by a number s which is 2048 plus/minus 1000 and then shifted by 11 digits which should replace a division by 2048.</description><dc:language>en-US</dc:language><generator>Telligent Community 10</generator><item><title>RE: unexpected results in integer arithmetics</title><link>https://community.arm.com/thread/129729?ContentTypeID=1</link><pubDate>Mon, 18 Nov 2002 05:22:42 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:b7953440-3b86-4f7d-9fda-09d2444b10d8</guid><dc:creator>Guenter Nowinski</dc:creator><description>&lt;p&gt;yes, now finally it works.&lt;br /&gt;
The compiler worked correctly, and the type casting does what I expected, but...&lt;br /&gt;
one of the variables was at an address where there was no physical memory.&lt;br /&gt;
After that became clear, the solution was easy.&lt;br /&gt;
&lt;br /&gt;
Thanks to everyone for your comments on my problem.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: unexpected results in integer arithmetics</title><link>https://community.arm.com/thread/121834?ContentTypeID=1</link><pubDate>Fri, 11 Oct 2002 09:44:44 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:92467ebb-6335-4b4d-bdd4-8b0b8b4cdbef</guid><dc:creator>Scott deWolski</dc:creator><description>&lt;p&gt;Meanwhile, back at the ranch, did Guenter ever get his integer math to work?&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: unexpected results in integer arithmetics</title><link>https://community.arm.com/thread/110114?ContentTypeID=1</link><pubDate>Fri, 11 Oct 2002 09:25:14 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:cf75a49a-c3ad-4a6f-b34f-f9e9fbd203cd</guid><dc:creator>Graham Cole</dc:creator><description>&lt;p&gt;Brad, you are 100% right!&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: unexpected results in integer arithmetics</title><link>https://community.arm.com/thread/95193?ContentTypeID=1</link><pubDate>Fri, 11 Oct 2002 09:14:09 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:77791fb6-bdb6-43bb-94f0-fc5c0ae0355b</guid><dc:creator>Brad Holeman</dc:creator><description>&lt;p&gt;Mark and John,&lt;br /&gt;
&lt;br /&gt;
Thanks for a quite interesting discussion.  I guess this just goes to show that coding preferences once set will probably never change.  Once a path has been chosen, nobody likes to admit that it was the wrong one.&lt;br /&gt;
&lt;br /&gt;
My own view on this is to dumb down the code as much as humanly possible.  I always use parentheses for everything.  Since I occasionally work with other peoples code, I keep a printed list of operators and their precedence right above my monitor.  I don&amp;#39;t have the precedence memorized but I can find out in a second or two.  Basically, I want to use C as a tool, I don&amp;#39;t want to think about C... I want to think about the system I am implementing.  I try to make my code as readable as possible.  It is second only to functionality in importance to me.  Here is an example of how I use parentheses:&lt;br /&gt;
&lt;br /&gt;
&lt;pre&gt;   /* Update the current station button pressed from hardware if a comms
      device doesn&amp;#39;t have it pressed */
   if ( (m_bStatButtonPressed == NO_STATION)
        ||
        ( (m_bStatButtonPressed != NO_STATION) &amp;amp;&amp;amp;
          (m_bStatButtonSource == i_bCommAddress()) ) 
        &amp;amp;&amp;amp;
          (m_bStatButtonSlavesUpdated &amp;gt;= i_bTotalCommSlaves()) )
   {
      BYTE bIndex;
      BYTE bStatIndex;

&lt;/pre&gt;
&lt;br /&gt;
To be honest, I beleive that judicious use of white space is every bit as important as parentheses..... it tells the reader what the writer INTENDED to do.  I don&amp;#39;t consider myself the brightest programmer out there.  Because of my limitations, I do everything I can to simplify.  If a novice programmer can take over maintenance of my project without having to ask me many questions, I consider the project extremely successful.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: unexpected results in integer arithmetics</title><link>https://community.arm.com/thread/145806?ContentTypeID=1</link><pubDate>Wed, 09 Oct 2002 09:29:38 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:ca51ad16-d166-4c56-bc93-fb12f573700d</guid><dc:creator>John Donaldson</dc:creator><description>&lt;p&gt;&lt;i&gt;I only change the case to lower and add an &amp;#39;r_&amp;#39; prefix to indicate the SFRs are not regular variables (e.g. r_pcon vs PCON). ALL CAPS was a bad idea for the SFRs since most programmers use all caps for manifest constants.&lt;/i&gt;&lt;br /&gt;
&lt;br /&gt;
Indeed, I normally only use all caps for manifest constants, but when there is something of a standard in place I stick with it so that my code has a similar look to the majority of the available codebase. I gradually get used to it until it seems perfectly natural and presto! I can glance at third party code and read it easily, others can do the same with my code.  &lt;br /&gt;
&lt;br /&gt;
&lt;i&gt;Also, SFRs in a header file is somewhat like defining a bunch of global variables in a header file. True, hardware is actually globabl but the namespace to access it does not need to be. In my UART driver I only needed to type a few SRF and SBIT. There is also some semblance of attempting to limit scope by placing the SFR definitions in the .c file instead of in the .h file, admittedly a semblance.&lt;/i&gt;&lt;br /&gt;
 &lt;br /&gt;
As you say the hardware is global. What then is the point of trying to restrict scope or namespace? Bear in mind that we&amp;#39;re talking about code for an 8 bit microcontroller here rather than something like MS Office.&lt;br /&gt;
&lt;br /&gt;
&lt;i&gt;Do you find my code that hard to read? Easier than most? More difficult than most? I&amp;#39;ve yet to have anyone complain about my code either from a functional standpoint or a readability standpoint.&lt;/i&gt;&lt;br /&gt;
&lt;br /&gt;
I would find your code easy to read if you stuck to standard C data types and &amp;#39;standard&amp;#39; 8051 nomenclature. typedefs and enumerated types do have their uses but always have me flipping backwards and forwards to and from header files to find out what the actual data type and value is. This disturbs the flow when trying to follow a piece of code. Everybody seems to have different ideas about these things - uINT8, Uint8, uChar, U8, u8 etc - I know they&amp;#39;re all obvious but I&amp;#39;d rather have to deal with remembering that the Crayfish Vector 22B has a 13 bit unsigned char that all that.&lt;br /&gt;
&lt;br /&gt;
&lt;i&gt;This small change does add clarity since you get extra visual information that this r_pcon is somehow not the same as a regular variable and it won&amp;#39;t be confused with a manifest constant.&lt;/i&gt;&lt;br /&gt;
&lt;br /&gt;
It doesn&amp;#39;t add clarity to the bulk of the 8051 community: those who are used to PCON, SCON etc. &lt;br /&gt;
 &lt;br /&gt;
&lt;i&gt;Besides, I work with many CPUs (MIPS, PowerPC, ARM, PIC, MSP430, 8051, and Z80) and I do not remember all the registers for all of these, the r_ prefix helps me and is consistent with my coding standards, which I&amp;#39;m sure you&amp;#39;d hate, located on my website.&lt;/i&gt;&lt;br /&gt;
&lt;br /&gt;
That&amp;#39;s fine: if it helps you and you are going to be the maintainer of your code then do it. If you&amp;#39;re writing 8051 code for the consumption of others I think you would be better sticking to the &amp;#39;standard&amp;#39;.&lt;br /&gt;
&lt;br /&gt;
Your coding standards don&amp;#39;t mesh perfectly with my preferences but you definitely are right about curly brace placement.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: unexpected results in integer arithmetics</title><link>https://community.arm.com/thread/143849?ContentTypeID=1</link><pubDate>Wed, 09 Oct 2002 08:07:43 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:740ff136-1655-417d-8377-995e795a7a2f</guid><dc:creator>Mark Odell</dc:creator><description>&lt;p&gt;&lt;i&gt;Oh come on. Every 8051 programmer is familiar with the names of the commonly used special function registers: PCON, SCON etc. That is what they are called in the data sheets. Keil have very sensibly declared these in the device specific header files. Every Keil 8051 programmer will be familiar with using these - so what do you do? You ignore the Keil header file and give your own declarations. Please don&amp;#39;t tell me that aids clarity. The first thing I&amp;#39;d do asked to work on your code would be some global replacement!&lt;/i&gt;&lt;br /&gt;
&lt;br /&gt;
I only change the case to lower and add an &amp;#39;r_&amp;#39; prefix to indicate the SFRs are not regular variables (e.g. r_pcon vs PCON). ALL CAPS was a bad idea for the SFRs since most programmers use all caps for manifest constants. &lt;br /&gt;
&lt;br /&gt;
Also, SFRs in a header file is somewhat like defining a bunch of global variables in a header file. True, hardware is actually globabl but the namespace to access it does not need to be. In my UART driver I only needed to type a few SRF and SBIT. There is also some semblance of attempting to limit scope by placing the SFR definitions in the .c file instead of in the .h file, admittedly a semblance.&lt;br /&gt;
&lt;br /&gt;
Do you find my code that hard to read? Easier than most? More difficult than most? I&amp;#39;ve yet to have anyone complain about my code either from a functional standpoint or a readability standpoint.&lt;br /&gt;
&lt;br /&gt;
This small change &lt;b&gt;does&lt;/b&gt; add clarity since you get extra visual information that this r_pcon is somehow not the same as a regular variable and it won&amp;#39;t be confused with a manifest constant.&lt;br /&gt;
&lt;br /&gt;
Besides, I work with many CPUs (MIPS, PowerPC, ARM, PIC, MSP430, 8051, and Z80) and I do not remember all the registers for all of these, the r_ prefix helps me and is consistent with my coding standards, which I&amp;#39;m sure you&amp;#39;d hate, located on my website (ignore the confidential markers). &lt;a href="http://www.embeddedfw.com" target="_blank"&gt;http://www.embeddedfw.com&lt;/a&gt;&lt;br /&gt;
&lt;br /&gt;
Regards.&lt;br /&gt;
&lt;br /&gt;
- Mark&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: unexpected results in integer arithmetics</title><link>https://community.arm.com/thread/141192?ContentTypeID=1</link><pubDate>Wed, 09 Oct 2002 04:00:38 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:4561b712-8169-4c88-8bec-ee30fb0c723c</guid><dc:creator>John Donaldson</dc:creator><description>&lt;p&gt;&lt;i&gt;We are not C experts to write dumbed down code folks. We are C experts because we learn the language and continually strive to improve and augment our C skills.&lt;/i&gt;&lt;br /&gt;
&lt;br /&gt;
We are C experts when we write efficient, functional code that is clear and comprehensible to not only ourselves but those who will have to work on our code afterwards. This is one of the most important skills as a professional programmer.&lt;br /&gt;
&lt;br /&gt;
&lt;i&gt;I don&amp;#39;t believe in writing unclear, obfuscated code but I also do not believe in writing C for the lowest common denominator of programmers. How will they ever learn?&lt;/i&gt;&lt;br /&gt;
&lt;br /&gt;
Oh come on. Every 8051 programmer is familiar with the names of the commonly used special function registers: PCON, SCON etc. That is what they are called in the data sheets. Keil have very sensibly declared these in the device specific header files. Every Keil 8051 programmer will be familiar with using these - so what do you do? You ignore the Keil header file and give your own declarations. Please don&amp;#39;t tell me that aids clarity. The first thing I&amp;#39;d do asked to work on your code would be some global replacement!&lt;br /&gt;
&lt;br /&gt;
&lt;i&gt;Do you really want a bunch of programmer&amp;#39;s writing basic C code or do you want them to grow into the language? Where do you draw the line? No use of ?:, no use of +=, *=, -=, etc., no use of bit-fields? No use of switch blocks? Are these constructs simply to diffucult for a programmer to understand? Nay, I think not.&lt;/i&gt;&lt;br /&gt;
&lt;br /&gt;
I want a bunch of C programmers writing clear, working code that everybody understands. This discussion was about the use of parentheses to aid clarity and overcome the operator precedence rules. Nobody is suggesting not using basic C constructs, were suggesting &lt;b&gt;adding&lt;/b&gt;  code to clarify intention.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: unexpected results in integer arithmetics</title><link>https://community.arm.com/thread/137610?ContentTypeID=1</link><pubDate>Tue, 08 Oct 2002 16:27:48 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:b4e6a46f-b427-4c4a-99d4-210a77056f8f</guid><dc:creator>Mark Odell</dc:creator><description>&lt;p&gt;&lt;i&gt;I think the later is easier to read.&lt;/i&gt;&lt;br /&gt;
&lt;br /&gt;
I don&amp;#39;t. What can I say?&lt;br /&gt;
&lt;br /&gt;
&lt;i&gt;Another point is, that C programs have audiences other than people making their living programming C.&lt;/i&gt;&lt;br /&gt;
&lt;br /&gt;
They are by definition not the audience then. If non-programmers need to understand code they should either ask an experience programmer to summarize or learn C. &lt;br /&gt;
&lt;br /&gt;
We are not C experts to write dumbed down code folks. We are C experts because we learn the language and continually strive to improve and augment our C skills. I don&amp;#39;t believe in writing unclear, obfuscated code but I also do not believe in writing C for the lowest common denominator of programmers. How will they ever learn? &lt;br /&gt;
&lt;br /&gt;
I don&amp;#39;t use baby words with my 3 year old and she has a far better vocabulary than her peers who get spoken to as babies. &lt;br /&gt;
&lt;br /&gt;
Do you really want a bunch of programmer&amp;#39;s writing basic C code or do you want them to grow into the language? Where do you draw the line? No use of ?:, no use of +=, *=, -=, etc., no use of bit-fields? No use of switch blocks? Are these constructs simply to diffucult for a programmer to understand? Nay, I think not.&lt;br /&gt;
&lt;br /&gt;
End of rant.&lt;br /&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: unexpected results in integer arithmetics</title><link>https://community.arm.com/thread/129725?ContentTypeID=1</link><pubDate>Tue, 08 Oct 2002 13:46:32 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:4e3a1682-8a11-4dd2-975e-e929fed1472d</guid><dc:creator>Robert Berkey</dc:creator><description>&lt;p&gt;&lt;pre&gt;
y = SLOPE * x + INTERCEPT;
&lt;/pre&gt;
vs.&lt;br /&gt;
&lt;pre&gt;
y = (SLOPE * x) + INTERCEPT;
&lt;/pre&gt;
&lt;br /&gt;
I think the later is easier to read.  &lt;br /&gt;
&lt;br /&gt;
Another point is, that C programs have audiences other than people making their living programming C.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: unexpected results in integer arithmetics</title><link>https://community.arm.com/thread/121830?ContentTypeID=1</link><pubDate>Tue, 08 Oct 2002 08:02:31 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:82a53a5d-4d93-4a1d-8330-343939151e6b</guid><dc:creator>Mark Odell</dc:creator><description>&lt;p&gt;I guess we&amp;#39;ll have to disagree then. My intent was actually mis-represented by my misplacment of the parens. so I don&amp;#39;t see how they helped.&lt;br /&gt;
&lt;br /&gt;
I&amp;#39;ve yet to have a hard time understanding&lt;pre&gt;y = SLOPE * x + INTERCEPT;&lt;/pre&gt;I am confident that multiplication will occur before addition. I&amp;#39;m sure most programmers are too. I am quite sure that if I hired someone who didn&amp;#39;t know that &amp;amp;&amp;amp; and || were lower in precedence than checks on equality then they&amp;#39;d be learning it.&lt;br /&gt;
&lt;br /&gt;
As for grouping, I think it&amp;#39;s rather easy to allow operators to group for you. E.g.&lt;pre&gt;if (0 &amp;lt; a &amp;amp;&amp;amp; a &amp;lt; 100)&lt;/pre&gt; shows me two comparisons separated by &amp;amp;&amp;amp;. The &amp;amp;&amp;amp; and &amp;lt; symbols are so distinct that you naturally group them apart.&lt;br /&gt;
&lt;br /&gt;
Regards.&lt;br /&gt;
&lt;br /&gt;
- Mark&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: unexpected results in integer arithmetics</title><link>https://community.arm.com/thread/110117?ContentTypeID=1</link><pubDate>Tue, 08 Oct 2002 06:09:57 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:a1740977-ebea-478d-82b6-edd8d5f0c6b1</guid><dc:creator>John Donaldson</dc:creator><description>&lt;p&gt;&lt;i&gt;Extra parentheses can actually harm readability&lt;/i&gt;&lt;br /&gt;
&lt;br /&gt;
I really must disagree with this. The parentheses group expressions so that you can see at a glance the order of evaluation. C has something like 16 levels of operator precedence as well as a left or right associativity for each level.&lt;br /&gt;
&lt;br /&gt;
If parentheses really do make the code less readable then the expression is too complex and should be split up.&lt;br /&gt;
&lt;br /&gt;
Perhaps the most important point is this, however: parentheses show the programmers intention even if the code is incorrect. It helps a great deal when debugging code to understand what the chap was trying to do. Also, if you are in the habit of using parentheses to show the order of evaluation you are much less likely to make the sort of mistake shown in the above post.&lt;br /&gt;
&lt;br /&gt;
&lt;i&gt;this should be obvious to all C programmers&lt;/i&gt;&lt;br /&gt;
&lt;br /&gt;
All C programmers start out with no knowledge whatsoever of C operator precedence. They gradually remember more of the precedence rules as time passes but even when they reach the stage of being seasoned professionals they still have to get the book out once in a while.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: unexpected results in integer arithmetics</title><link>https://community.arm.com/thread/85141?ContentTypeID=1</link><pubDate>Mon, 07 Oct 2002 17:03:59 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:439ca0d2-33aa-4502-95c7-0f66b15ae91b</guid><dc:creator>Mark Odell</dc:creator><description>&lt;p&gt;Please let me amend my previous post. I &lt;b&gt;do&lt;/b&gt; believe in using parentheses &lt;b&gt;when required&lt;/b&gt;.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: unexpected results in integer arithmetics</title><link>https://community.arm.com/thread/84327?ContentTypeID=1</link><pubDate>Mon, 07 Oct 2002 17:00:19 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:5d7227bd-03b7-464b-a502-36af183ed2c8</guid><dc:creator>Mark Odell</dc:creator><description>&lt;p&gt;&lt;i&gt;x = (unsigned int) (x * s) / 2048UL;&lt;br /&gt;
&lt;br /&gt;
Unfortunately the above won&amp;#39;t work as the cast to unsigned int has higher precedence than the division. You need to use:&lt;br /&gt;
&lt;br /&gt;
x=(unsigned int)((x*s)/2048UL);&lt;/i&gt;&lt;br /&gt;
&lt;br /&gt;
Arg! Thanks. My bad. I certainly meant what you wrote.&lt;br /&gt;
&lt;br /&gt;
&lt;i&gt;I feel it is always better to use parentheses to make your intentions clearer even when not required.&lt;/i&gt;&lt;br /&gt;
&lt;br /&gt;
I don&amp;#39;t. Extra parentheses can actually harm readability in some cases. My mistake would not have been helped by parentheses since I put them in the wrong spot to begin with. My rule is, if the operators are on different levels of the precedence graph, don&amp;#39;t use parentheses, e.g. this should be obvious to all C programmers:&lt;pre&gt;if (0 &amp;lt; a &amp;amp;&amp;amp; a &amp;lt; 100) ...&lt;/pre&gt;Adding parens. like this does nothing to help the C programmer&lt;pre&gt;if ((0 &amp;lt; a) &amp;amp;&amp;amp; (a &amp;lt; 100))&lt;/pre&gt;
&lt;br /&gt;
Thanks for the correction.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: unexpected results in integer arithmetics</title><link>https://community.arm.com/thread/54723?ContentTypeID=1</link><pubDate>Mon, 07 Oct 2002 16:19:48 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:3eb7125d-dad4-427d-b60b-01dbee5263da</guid><dc:creator>Brad Holeman</dc:creator><description>&lt;p&gt;Guenther,&lt;br /&gt;
&lt;br /&gt;
The line looked ok to me.  &lt;br /&gt;
&lt;br /&gt;
I wonder if the fact that one variable is explicitly set as a near (and I presume the other is a far) is the problem.  Perhaps making all variables far would help.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: unexpected results in integer arithmetics</title><link>https://community.arm.com/thread/54715?ContentTypeID=1</link><pubDate>Mon, 07 Oct 2002 11:32:06 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:c6fbd39e-f209-4424-8754-c717238726ed</guid><dc:creator>John Donaldson</dc:creator><description>&lt;p&gt;Right shifting is not implementation defined if the operand is unsigned. In the signed case the implementor has the choice of either shifting in zero-bits or copies of the leftmost bit (usually the sign bit).&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: unexpected results in integer arithmetics</title><link>https://community.arm.com/thread/54716?ContentTypeID=1</link><pubDate>Mon, 07 Oct 2002 11:22:31 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:9a259f91-eef7-434e-b405-b46f7afd7dcf</guid><dc:creator>John Donaldson</dc:creator><description>&lt;p&gt;x = (unsigned int) (x * s) / 2048UL;&lt;br /&gt;
&lt;br /&gt;
Unfortunately the above won&amp;#39;t work as the cast to unsigned int has higher precedence than the division. You need to use:&lt;br /&gt;
&lt;br /&gt;
x=(unsigned int)((x*s)/2048UL);&lt;br /&gt;
&lt;br /&gt;
I feel it is always better to use parentheses to make your intentions clearer even when not required.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: unexpected results in integer arithmetics</title><link>https://community.arm.com/thread/50155?ContentTypeID=1</link><pubDate>Mon, 07 Oct 2002 11:10:46 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:d6c7452b-270c-40c2-a344-2b6398aa3121</guid><dc:creator>Scott deWolski</dc:creator><description>&lt;p&gt;Hello,&lt;br /&gt;
I tried this on my system and the results were fine.  The assembly code is;&lt;br /&gt;
&lt;pre&gt;

s is assigned to R5
x is assigned to R4

 MOV   R5, DPP2:s
 MOV   R4, DPP2:x

 MULU  R4, R5          ;x*s
 MOV   R5, MDH
 MOV   R4, MDL
 MOV   R6, R5
 SHR   R4, #0x0B       ;&amp;gt;&amp;gt;11 (32-bit)
 SHL   R6, #0x05
 OR    R4, R6
 MOV   DPP2:x, R4
&lt;/pre&gt;
&lt;br /&gt;
This is pretty good code except for the extraneous loading of R5 from MDH.  Turn on the assembly code option in the listing tab of the project settings and see what you get.&lt;br /&gt;
&lt;br /&gt;
Best Luck&lt;br /&gt;
Scott&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: unexpected results in integer arithmetics</title><link>https://community.arm.com/thread/39244?ContentTypeID=1</link><pubDate>Mon, 07 Oct 2002 10:53:55 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:f978dd19-75dd-4ed5-8052-917a8406bab2</guid><dc:creator>Mark Odell</dc:creator><description>&lt;p&gt;Oh, one other thing. If you must bit-shift, C only guarantees that you will pull in zeros when &lt;b&gt;left&lt;/b&gt; shifting. Right shifting is implementation defined. So, in your example, you should AND off the top 11 bits of the result before using it.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: unexpected results in integer arithmetics</title><link>https://community.arm.com/thread/39245?ContentTypeID=1</link><pubDate>Mon, 07 Oct 2002 10:52:06 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:f21c70ac-6d6c-458a-842f-8b9f23ef2863</guid><dc:creator>Mark Odell</dc:creator><description>&lt;p&gt;First, I am pretty sure any compiler written today will convert var / 2048 to a proper right shift of 11 bits so let the compiler do the work for you.&lt;br /&gt;
&lt;br /&gt;
Second, only one term in an expression need be a larger type to convert the entire expression to that type. E.g.&lt;pre&gt;x = (unsigned int) (x * s) / 2048UL;&lt;/pre&gt;
should give you the correct result (32 bits should always be able to contain 16 x 16 bits multiplies) with a compiler-warning-silencing final cast back to the smaller type of unsigned int. Try the above and see what assembler you get. See what result you get.&lt;br /&gt;
&lt;br /&gt;
HTH.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>