On Wed, Mar 7, 2012 at 9:43 PM, Conrado P. L. Gouvêa
wrote:
> Hi,
>
> I've decided to update my mspgcc and I have compiled the 20120224
> version (using Ubuntu 8.04). But I've noticed something strange, it
> appears that the compiler is generating incorrect assembly code. This
> is simple example:
- Ursprüngliche Nachricht -
Von: conrado...@gmail.com
Gesendet am: 08 Mrz 2012 17:40:34
> I understand your reasoning, but I really think it should jump to the
> dummy label rather then executing unrelated code.
I totally agree. And that is what MSPGCC 3.23 did ( I just checked):
22
On Thu, Mar 8, 2012 at 7:25 PM, William "Chops" Westfield
wrote:
>
> On Mar 7, 2012, at 9:06 PM, David Relson wrote:
>
>> On the other hand, after changing the "int main(void)" statement to "int
>> test(void)", compile, and disassemble then the expected "ret"
>> statements appear. It seems that t
On Mar 7, 2012, at 9:06 PM, David Relson wrote:
> On the other hand, after changing the "int main(void)" statement to "int
> test(void)", compile, and disassemble then the expected "ret"
> statements appear. It seems that the "main" function gets special
> handling.
Hmm. There was a very simil
On Thu, Mar 8, 2012 at 9:35 AM, JMGross wrote:
>
>
>
>
> - Ursprüngliche Nachricht -
> Von: Peter Bigot
> An: Conrado P. L. Gouvêa
> Gesendet am: 08 Mrz 2012 13:35:56
> Betreff: Re: [Mspgcc-users] Incorrect generated code
>
>> Yes, unless it is marked a
On Thu, Mar 8, 2012 at 10:29 AM, Conrado P. L. Gouvêa
wrote:
> On Thu, Mar 8, 2012 at 09:35, Peter Bigot wrote:
>> Yes, unless it is marked as "hosted" main is handled specially; there
>> has been recent discussion about why in a thread about creating
>> archives that contain the main routine. S
On Thu, Mar 8, 2012 at 12:35, JMGross wrote:
> Well, I must admit I had expected some jump to a dummy
> 'end of main' label or such. But thinking over it, it is obvious, that
> on a naked function you're responsible for exiting the function properly
> A return statement sets the return value, but
On Thu, Mar 8, 2012 at 09:35, Peter Bigot wrote:
> Yes, unless it is marked as "hosted" main is handled specially; there
> has been recent discussion about why in a thread about creating
> archives that contain the main routine. See also
> http://www.mail-archive.com/mspgcc-users@lists.sourceforg
- Ursprüngliche Nachricht -
Von: Peter Bigot
An: Conrado P. L. Gouvêa
Gesendet am: 08 Mrz 2012 13:35:56
Betreff: Re: [Mspgcc-users] Incorrect generated code
> Yes, unless it is marked as "hosted" main is handled specially; there
> has been recent discussion about why i
Yes, unless it is marked as "hosted" main is handled specially; there
has been recent discussion about why in a thread about creating
archives that contain the main routine. See also
http://www.mail-archive.com/mspgcc-users@lists.sourceforge.net/msg09750.html.
At a quick glance does appear that t
On Thu, 8 Mar 2012 00:43:31 -0300
Conrado P. L. Gouvêa wrote:
> Hi,
>
> I've decided to update my mspgcc and I have compiled the 20120224
> version (using Ubuntu 8.04). But I've noticed something strange, it
> appears that the compiler is generating incorrect assembly code. This
> is simple examp
Hi,
I've decided to update my mspgcc and I have compiled the 20120224
version (using Ubuntu 8.04). But I've noticed something strange, it
appears that the compiler is generating incorrect assembly code. This
is simple example:
void foo() {
volatile int y = 1;
}
int dummy() {
volatile int x =
Thanks,
I'll check this out.
~d
On Thursday 12 December 2002 11:45, David Brown wrote:
> > > not possible to optomise the 7 "rla" instructions as a "swapb" then an
> > > "rra" ?
> >
> > You'll loose 1 bit then. I thought about it...
>
> I see what you mean. But what about the sequence:
> rrc
>
> > But m2 should be 16-bit, and yet is generated as 8-bit.
>
> you're right...
> I'll fix it in a minute... (already in cvs. :)
Thanks - I'll download later today.
>
>
> > Incidently, is the inline multiply code faster than using the hardware
> > multiply? I can see it would be for small cons
> But m2 should be 16-bit, and yet is generated as 8-bit.
you're right...
I'll fix it in a minute... (already in cvs. :)
> Incidently, is the inline multiply code faster than using the hardware
> multiply? I can see it would be for small constants, but do you switch
> over automatically for con
Hi,
I think I have found a bug in the way mspgcc generates in-line multiply code
when using typecasts. In a particular bit of code, I want to multiply a
byte-sized variable with a constant. The result should be 16-bit, since it
could well be over 255. I was under the impression that normal C in
16 matches
Mail list logo
