[Mspgcc-users] Why do the compiler not use bitc for P1OUT = ~0x80;
Hello, I have a little issue with bitc. If I use P1OUT = ~0x08; I got bic.b #8, 0x0021 but if I use P1OUT = ~0x80; I got mov.b #127, r15 and.b r15, 0x0021 with P1OUT = (uint8_t)~0x80; I got and.b #127, 0x0021 P1OUT = ~0x40-- and.b #-65, 0x0021 which is better but not the expected result. It looks like it depends on the value( high nibble doesn't work). - why is it - how I can get the bic (not using inline assembler) Any ideas? regards, Dirk
Re: [Mspgcc-users] Why do the compiler not use bitc for P1OUT = ~0x80;
Dirk Rapp wrote: Hello, I have a little issue with bitc. If I use P1OUT= ~0x08; I got bic.b #8,0x0021 but if I use P1OUT= ~0x80; I got mov.b #127, r15 and.b r15,0x0021 with P1OUT= (uint8_t)~0x80; I got and.b #127,0x0021 P1OUT= ~0x40-- and.b #-65,0x0021 which is better but not the expected result. It looks like it depends on the value( high nibble doesn't work). - why is it - how I can get the bic (not using inline assembler) Any ideas? You didn't say what -Ox you where using. But if -O0, I would expect the compiler to take the longest route possible. Longer than anyone doing assembly would think. But this works great for debugging. Is that the case? Best, Dan.
Re: [Mspgcc-users] Why do the compiler not use bitc for P1OUT = ~0x80;
I'd say it depends on optimisation level and the other code. bic.b x is technically the same as and.b ~x. If x is known at compile time, both instructions are identically. But if ~x (maybe as pure coincidence) is required later down in the code again, using a mov and and instruction is shorter and faster than a bic instruction with immediate operand. This isn't true if the constant generator can be used for the bic operation. BIC.B #8,x is a 4-byte instruction, as #8 can be derived from the constant generator and does not need two additional bytes for loading the constant. BIC.B #0x80, x would be a 6 byte instruction and 1 cycle longer, so there is no difference to AND.B #0x7f, x. And if 0x7f is required in future anyway, putting it into a register saves 2 bytes and a cycle on the long run. This optimisation is less obvious, if you explicitely do a typecast. I think the compiler doesn't 'see' there anymore that it is the same 0x7f value. Actually using BIC for a C AND operation is an optimization that makes the code less readable (because of the inverted operand, even if this is the 'real' operand and had already been inverted in the source to allow usage of the AND operator where a BIC was intended). So this optimization is only used when the operand is available through the constant generator and therefore the BIC command is shorter and faster than a normal AND. If the operand is unkown at compiletime, an XOR operation would be needed to invert the AND value for BIC, and therefore BIC has no advantage anymore over AND. So it's effectively only used when the bits to clear are known at compile-time and only if it are the bits 0..2, which are available as constant generator values. Anythign else or a combination will result in the AND operation as it is written in the C code. JMGross - Ursprüngliche Nachricht - Von: Dirk Rapp An: mspgcc-users@lists.sourceforge.net Gesendet am: 26 Aug 2010 07:58:00 Betreff: [Mspgcc-users] Why do the compiler not use bitc for P1OUT = ~0x80; Hello, I have a little issue with bitc. If I use P1OUT = ~0x08; I got bic.b #8, 0x0021 but if I use P1OUT = ~0x80; I got mov.b #127, r15 and.b r15, 0x0021 with P1OUT = (uint8_t)~0x80; I got and.b #127, 0x0021 P1OUT = ~0x40-- and.b #-65, 0x0021 which is better but not the expected result. It looks like it depends on the value( high nibble doesn't work). - why is it - how I can get the bic (not using inline assembler) Any ideas? regards, Dirk
[Mspgcc-users] Trying to add msp430f5529 to mspgcc4
Hello, I unsuccessfully modified the binutils patch and the msp430 port source to add support for msp430f5529. On a previous thread (Re: mspgcc or mspgcc4 for a msp430f552), Peter Bigot said to try on the compile line to use -mmcu=msp430x5418. The problem is the start address dont match (There may be something else). For MMCU = msp430x5529 ARCH=msp:55 *ROM_START=0x4400 ROM_SIZE=0x2 INFO_START=0x1800 INFO_SIZE=512 BOOT_START=0x1000 BOOT_SIZE=2048 *RAM_START=0x2400 RAM_SIZE=8192 VECTORS_START=0xff80 For MMCU = msp430x5418 ARCH=msp:54 *ROM_START=0x5c00 ROM_SIZE=0x2 INFO_START=0x1800 INFO_SIZE=512 BOOT_START=0x1000 BOOT_SIZE=2048 *RAM_START=0x1c00 RAM_SIZE=16384 VECTORS_START=0xff80 I added quite some line in the binutils-2.20.1.patch to add the target msp430x5529 and alos the ARCH=msp:55.. I added the support in the msp430 gcc port source (since there is no patch used there). I modified msp430.c, msp430.h, t-msp and generate=chip-data.py. I successfully made all the mspgcc tools compile. I can now compile and link using -mmcu=msp430x5529. Here what's the objdump gives: -- leds: file format elf32-msp430 leds architecture: msp:55, flags 0x0112: EXEC_P, HAS_SYMS, D_PAGED start address 0x4400 Program Header: LOAD off0x vaddr 0x43ac paddr 0x43ac align 2**0 filesz 0x00b2 memsz 0x00b2 flags r-x Sections: Idx Name Size VMA LMA File off Algn 0 .text 005e 4400 4400 0054 2**1 CONTENTS, ALLOC, LOAD, READONLY, CODE SYMBOL TABLE: 4400 ld .text .text ldf *ABS* main.c 04c0 l *ABS* __MPY 04c2 l *ABS* __MPYS 04c4 l *ABS* __MAC 04c6 l *ABS* __MACS 04c8 l *ABS* __OP2 04ca l *ABS* __RESLO 04cc l *ABS* __RESHI 04ce l *ABS* __SUMEXT 04d0 l *ABS* __MPY32L 04d2 l *ABS* __MPY32H 04d4 l *ABS* __MPYS32L 04d6 l *ABS* __MPYS32H 04d8 l *ABS* __MAC32L 04da l *ABS* __MAC32H 04dc l *ABS* __MACS32L 04de l *ABS* __MACS32H 04e0 l *ABS* __OP2L 04e2 l *ABS* __OP2H 04e4 l *ABS* __RES0 04e6 l *ABS* __RES1 04e8 l *ABS* __RES2 04ea l *ABS* __RES3 04ec l *ABS* __MPY32CTL0 0001 g .text _efartext 445e g .text _etext 4400 g .text __dtors_end 4400 g .text __ctors_start 4400 g F .text 005e main ff80 g .text _vectors_end 4400 g .text __dtors_start 4400 g .text __ctors_end 4400 g *ABS* __stack 2400 g .text _edata 2400 g .text _end -- Is there a formal way to add a new mmcu to the tools? I hack'd the patch and source and that may not be the right way hehe. Thanks for any queue! Alexandre Malo
Re: [Mspgcc-users] Trying to add msp430f5529 to mspgcc4
Sorry; my suggestion was meant to trick the compiler into defining some relevant CPU and MPY flags, and work around an include file limitation. I'd neglected to look into the binutils issues. Unfortunately, there are no existing supported chips that match the layout of the 55xx chips. I can add the twenty-four chips in the 55xx sub-family to the existing mspgcc4 support list while continuing to rework the infrastructure so this won't be quite so painful in the future. Before I go through all that, are there other chips that people need added? Peter 2010/8/26 Alexandre Malo alexandre.m...@usherbrooke.ca Hello, I unsuccessfully modified the binutils patch and the msp430 port source to add support for msp430f5529. On a previous thread (Re: mspgcc or mspgcc4 for a msp430f552), Peter Bigot said to try on the compile line to use -mmcu=msp430x5418. The problem is the start address dont match (There may be something else). For MMCU = msp430x5529 ARCH=msp:55 *ROM_START=0x4400 ROM_SIZE=0x2 INFO_START=0x1800 INFO_SIZE=512 BOOT_START=0x1000 BOOT_SIZE=2048 *RAM_START=0x2400 RAM_SIZE=8192 VECTORS_START=0xff80 For MMCU = msp430x5418 ARCH=msp:54 *ROM_START=0x5c00 ROM_SIZE=0x2 INFO_START=0x1800 INFO_SIZE=512 BOOT_START=0x1000 BOOT_SIZE=2048 *RAM_START=0x1c00 RAM_SIZE=16384 VECTORS_START=0xff80 I added quite some line in the binutils-2.20.1.patch to add the target msp430x5529 and alos the ARCH=msp:55.. I added the support in the msp430 gcc port source (since there is no patch used there). I modified msp430.c, msp430.h, t-msp and generate=chip-data.py. I successfully made all the mspgcc tools compile. I can now compile and link using -mmcu=msp430x5529. Here what's the objdump gives: -- leds: file format elf32-msp430 leds architecture: msp:55, flags 0x0112: EXEC_P, HAS_SYMS, D_PAGED start address 0x4400 Program Header: LOAD off0x vaddr 0x43ac paddr 0x43ac align 2**0 filesz 0x00b2 memsz 0x00b2 flags r-x Sections: Idx Name Size VMA LMA File off Algn 0 .text 005e 4400 4400 0054 2**1 CONTENTS, ALLOC, LOAD, READONLY, CODE SYMBOL TABLE: 4400 ld .text .text ldf *ABS* main.c 04c0 l *ABS* __MPY 04c2 l *ABS* __MPYS 04c4 l *ABS* __MAC 04c6 l *ABS* __MACS 04c8 l *ABS* __OP2 04ca l *ABS* __RESLO 04cc l *ABS* __RESHI 04ce l *ABS* __SUMEXT 04d0 l *ABS* __MPY32L 04d2 l *ABS* __MPY32H 04d4 l *ABS* __MPYS32L 04d6 l *ABS* __MPYS32H 04d8 l *ABS* __MAC32L 04da l *ABS* __MAC32H 04dc l *ABS* __MACS32L 04de l *ABS* __MACS32H 04e0 l *ABS* __OP2L 04e2 l *ABS* __OP2H 04e4 l *ABS* __RES0 04e6 l *ABS* __RES1 04e8 l *ABS* __RES2 04ea l *ABS* __RES3 04ec l *ABS* __MPY32CTL0 0001 g .text _efartext 445e g .text _etext 4400 g .text __dtors_end 4400 g .text __ctors_start 4400 g F .text 005e main ff80 g .text _vectors_end 4400 g .text __dtors_start 4400 g .text __ctors_end 4400 g *ABS* __stack 2400 g .text _edata 2400 g .text _end -- Is there a formal way to add a new mmcu to the tools? I hack'd the patch and source and that may not be the right way hehe. Thanks for any queue! Alexandre Malo -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Trying to add msp430f5529 to mspgcc4
Thanks for the quick reply and the work you do! I guess you are better than I to do this. ps: I forgot to say in my mail that the mspgcc tools did compile and then my msp code, but it still does not execute. I found http://sourceforge.net/apps/mediawiki/mspgcc/index.php?title=AddingNewDevice on mspgcc wiki. Thats what I tried to follow :) Thanks again and have a good day! Alex On 10-08-26 10:14 AM, Peter Bigot wrote: Sorry; my suggestion was meant to trick the compiler into defining some relevant CPU and MPY flags, and work around an include file limitation. I'd neglected to look into the binutils issues. Unfortunately, there are no existing supported chips that match the layout of the 55xx chips. I can add the twenty-four chips in the 55xx sub-family to the existing mspgcc4 support list while continuing to rework the infrastructure so this won't be quite so painful in the future. Before I go through all that, are there other chips that people need added? Peter 2010/8/26 Alexandre Maloalexandre.m...@usherbrooke.ca Hello, I unsuccessfully modified the binutils patch and the msp430 port source to add support for msp430f5529. On a previous thread (Re: mspgcc or mspgcc4 for a msp430f552), Peter Bigot said to try on the compile line to use -mmcu=msp430x5418. The problem is the start address dont match (There may be something else). For MMCU = msp430x5529 ARCH=msp:55 *ROM_START=0x4400 ROM_SIZE=0x2 INFO_START=0x1800 INFO_SIZE=512 BOOT_START=0x1000 BOOT_SIZE=2048 *RAM_START=0x2400 RAM_SIZE=8192 VECTORS_START=0xff80 For MMCU = msp430x5418 ARCH=msp:54 *ROM_START=0x5c00 ROM_SIZE=0x2 INFO_START=0x1800 INFO_SIZE=512 BOOT_START=0x1000 BOOT_SIZE=2048 *RAM_START=0x1c00 RAM_SIZE=16384 VECTORS_START=0xff80 I added quite some line in the binutils-2.20.1.patch to add the target msp430x5529 and alos the ARCH=msp:55.. I added the support in the msp430 gcc port source (since there is no patch used there). I modified msp430.c, msp430.h, t-msp and generate=chip-data.py. I successfully made all the mspgcc tools compile. I can now compile and link using -mmcu=msp430x5529. Here what's the objdump gives: -- leds: file format elf32-msp430 leds architecture: msp:55, flags 0x0112: EXEC_P, HAS_SYMS, D_PAGED start address 0x4400 Program Header: LOAD off0x vaddr 0x43ac paddr 0x43ac align 2**0 filesz 0x00b2 memsz 0x00b2 flags r-x Sections: Idx Name Size VMA LMA File off Algn 0 .text 005e 4400 4400 0054 2**1 CONTENTS, ALLOC, LOAD, READONLY, CODE SYMBOL TABLE: 4400 ld .text .text ldf *ABS* main.c 04c0 l *ABS* __MPY 04c2 l *ABS* __MPYS 04c4 l *ABS* __MAC 04c6 l *ABS* __MACS 04c8 l *ABS* __OP2 04ca l *ABS* __RESLO 04cc l *ABS* __RESHI 04ce l *ABS* __SUMEXT 04d0 l *ABS* __MPY32L 04d2 l *ABS* __MPY32H 04d4 l *ABS* __MPYS32L 04d6 l *ABS* __MPYS32H 04d8 l *ABS* __MAC32L 04da l *ABS* __MAC32H 04dc l *ABS* __MACS32L 04de l *ABS* __MACS32H 04e0 l *ABS* __OP2L 04e2 l *ABS* __OP2H 04e4 l *ABS* __RES0 04e6 l *ABS* __RES1 04e8 l *ABS* __RES2 04ea l *ABS* __RES3 04ec l *ABS* __MPY32CTL0 0001 g .text _efartext 445e g .text _etext 4400 g .text __dtors_end 4400 g .text __ctors_start 4400 g F .text 005e main ff80 g .text _vectors_end 4400 g .text __dtors_start 4400 g .text __ctors_end 4400 g *ABS* __stack 2400 g .text _edata 2400 g .text _end -- Is there a formal way to add a new mmcu to the tools? I hack'd the patch and source and that may not be the right way hehe. Thanks for any queue! Alexandre Malo -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future.
Re: [Mspgcc-users] Trying to add msp430f5529 to mspgcc4
Those patches are generated by diffs from development repositories that include gcc/binutils/gdb, so it's generally easier to do them in that context. Someday those repositories will be available on SF so other folks can do it the easy way too; I'm still working out the maintainer infrastructure. (The wiki page you followed is right, it's just a really unpleasant process that encourages unintentional inconsistencies.) I can't say why the program doesn't work. Only suggestion is: are you using the TI-provided header for the 5529? The addresses of peripherals might not be right with the older msp430-libc sources. (I do not intend to back-port the non-TI msp430-libc to the new chips. If somebody wants to contribute and provide support for such a port, I'll undertake to add it, but I think the time would be better spent validating and improving the TI headers.) Peter 2010/8/26 Alexandre Malo alexandre.m...@usherbrooke.ca Thanks for the quick reply and the work you do! I guess you are better than I to do this. ps: I forgot to say in my mail that the mspgcc tools did compile and then my msp code, but it still does not execute. I found http://sourceforge.net/apps/mediawiki/mspgcc/index.php?title=AddingNewDeviceon mspgcc wiki. Thats what I tried to follow :) Thanks again and have a good day! Alex On 10-08-26 10:14 AM, Peter Bigot wrote: Sorry; my suggestion was meant to trick the compiler into defining some relevant CPU and MPY flags, and work around an include file limitation. I'd neglected to look into the binutils issues. Unfortunately, there are no existing supported chips that match the layout of the 55xx chips. I can add the twenty-four chips in the 55xx sub-family to the existing mspgcc4 support list while continuing to rework the infrastructure so this won't be quite so painful in the future. Before I go through all that, are there other chips that people need added? Peter 2010/8/26 Alexandre Maloalexandre.m...@usherbrooke.ca Hello, I unsuccessfully modified the binutils patch and the msp430 port source to add support for msp430f5529. On a previous thread (Re: mspgcc or mspgcc4 for a msp430f552), Peter Bigot said to try on the compile line to use -mmcu=msp430x5418. The problem is the start address dont match (There may be something else). For MMCU = msp430x5529 ARCH=msp:55 *ROM_START=0x4400 ROM_SIZE=0x2 INFO_START=0x1800 INFO_SIZE=512 BOOT_START=0x1000 BOOT_SIZE=2048 *RAM_START=0x2400 RAM_SIZE=8192 VECTORS_START=0xff80 For MMCU = msp430x5418 ARCH=msp:54 *ROM_START=0x5c00 ROM_SIZE=0x2 INFO_START=0x1800 INFO_SIZE=512 BOOT_START=0x1000 BOOT_SIZE=2048 *RAM_START=0x1c00 RAM_SIZE=16384 VECTORS_START=0xff80 I added quite some line in the binutils-2.20.1.patch to add the target msp430x5529 and alos the ARCH=msp:55.. I added the support in the msp430 gcc port source (since there is no patch used there). I modified msp430.c, msp430.h, t-msp and generate=chip-data.py. I successfully made all the mspgcc tools compile. I can now compile and link using -mmcu=msp430x5529. Here what's the objdump gives: -- leds: file format elf32-msp430 leds architecture: msp:55, flags 0x0112: EXEC_P, HAS_SYMS, D_PAGED start address 0x4400 Program Header: LOAD off0x vaddr 0x43ac paddr 0x43ac align 2**0 filesz 0x00b2 memsz 0x00b2 flags r-x Sections: Idx Name Size VMA LMA File off Algn 0 .text 005e 4400 4400 0054 2**1 CONTENTS, ALLOC, LOAD, READONLY, CODE SYMBOL TABLE: 4400 ld .text .text ldf *ABS* main.c 04c0 l *ABS* __MPY 04c2 l *ABS* __MPYS 04c4 l *ABS* __MAC 04c6 l *ABS* __MACS 04c8 l *ABS* __OP2 04ca l *ABS* __RESLO 04cc l *ABS* __RESHI 04ce l *ABS* __SUMEXT 04d0 l *ABS* __MPY32L 04d2 l *ABS* __MPY32H 04d4 l *ABS* __MPYS32L 04d6 l *ABS* __MPYS32H 04d8 l *ABS* __MAC32L 04da l *ABS* __MAC32H 04dc l *ABS* __MACS32L 04de l *ABS* __MACS32H 04e0 l *ABS* __OP2L 04e2 l *ABS* __OP2H 04e4 l *ABS* __RES0 04e6 l *ABS* __RES1 04e8 l *ABS* __RES2 04ea l *ABS* __RES3 04ec l *ABS* __MPY32CTL0 0001 g .text _efartext 445e g .text _etext
Re: [Mspgcc-users] Trying to add msp430f5529 to mspgcc4
Hello Peter, just for information, I built mspgcc with these options: Select GCC version to build: 2) gcc-4.4.3 Select GDB version to build: 1) gdb-7.1 Select Insight version to build: 2) none Select libc version to build: 2) ti_20100815 So I did used the ti headers as you suggested. One thing I see is I did not made any change in msp430-libc. Alex mspgcc-4 On 10-08-26 10:58 AM, Peter Bigot wrote: Those patches are generated by diffs from development repositories that include gcc/binutils/gdb, so it's generally easier to do them in that context. Someday those repositories will be available on SF so other folks can do it the easy way too; I'm still working out the maintainer infrastructure. (The wiki page you followed is right, it's just a really unpleasant process that encourages unintentional inconsistencies.) I can't say why the program doesn't work. Only suggestion is: are you using the TI-provided header for the 5529? The addresses of peripherals might not be right with the older msp430-libc sources. (I do not intend to back-port the non-TI msp430-libc to the new chips. If somebody wants to contribute and provide support for such a port, I'll undertake to add it, but I think the time would be better spent validating and improving the TI headers.) Peter 2010/8/26 Alexandre Maloalexandre.m...@usherbrooke.ca Thanks for the quick reply and the work you do! I guess you are better than I to do this. ps: I forgot to say in my mail that the mspgcc tools did compile and then my msp code, but it still does not execute. I found http://sourceforge.net/apps/mediawiki/mspgcc/index.php?title=AddingNewDeviceon mspgcc wiki. Thats what I tried to follow :) Thanks again and have a good day! Alex On 10-08-26 10:14 AM, Peter Bigot wrote: Sorry; my suggestion was meant to trick the compiler into defining some relevant CPU and MPY flags, and work around an include file limitation. I'd neglected to look into the binutils issues. Unfortunately, there are no existing supported chips that match the layout of the 55xx chips. I can add the twenty-four chips in the 55xx sub-family to the existing mspgcc4 support list while continuing to rework the infrastructure so this won't be quite so painful in the future. Before I go through all that, are there other chips that people need added? Peter 2010/8/26 Alexandre Maloalexandre.m...@usherbrooke.ca Hello, I unsuccessfully modified the binutils patch and the msp430 port source to add support for msp430f5529. On a previous thread (Re: mspgcc or mspgcc4 for a msp430f552), Peter Bigot said to try on the compile line to use -mmcu=msp430x5418. The problem is the start address dont match (There may be something else). For MMCU = msp430x5529 ARCH=msp:55 *ROM_START=0x4400 ROM_SIZE=0x2 INFO_START=0x1800 INFO_SIZE=512 BOOT_START=0x1000 BOOT_SIZE=2048 *RAM_START=0x2400 RAM_SIZE=8192 VECTORS_START=0xff80 For MMCU = msp430x5418 ARCH=msp:54 *ROM_START=0x5c00 ROM_SIZE=0x2 INFO_START=0x1800 INFO_SIZE=512 BOOT_START=0x1000 BOOT_SIZE=2048 *RAM_START=0x1c00 RAM_SIZE=16384 VECTORS_START=0xff80 I added quite some line in the binutils-2.20.1.patch to add the target msp430x5529 and alos the ARCH=msp:55.. I added the support in the msp430 gcc port source (since there is no patch used there). I modified msp430.c, msp430.h, t-msp and generate=chip-data.py. I successfully made all the mspgcc tools compile. I can now compile and link using -mmcu=msp430x5529. Here what's the objdump gives: -- leds: file format elf32-msp430 leds architecture: msp:55, flags 0x0112: EXEC_P, HAS_SYMS, D_PAGED start address 0x4400 Program Header: LOAD off0x vaddr 0x43ac paddr 0x43ac align 2**0 filesz 0x00b2 memsz 0x00b2 flags r-x Sections: Idx Name Size VMA LMA File off Algn 0 .text 005e 4400 4400 0054 2**1 CONTENTS, ALLOC, LOAD, READONLY, CODE SYMBOL TABLE: 4400 ld .text .text ldf *ABS* main.c 04c0 l *ABS* __MPY 04c2 l *ABS* __MPYS 04c4 l *ABS* __MAC 04c6 l *ABS* __MACS 04c8 l *ABS* __OP2 04ca l *ABS* __RESLO 04cc l *ABS* __RESHI 04ce l *ABS* __SUMEXT 04d0 l *ABS* __MPY32L 04d2 l *ABS* __MPY32H 04d4 l *ABS* __MPYS32L 04d6 l *ABS* __MPYS32H 04d8 l *ABS* __MAC32L 04da l *ABS* __MAC32H 04dc l *ABS* __MACS32L 04de l *ABS* __MACS32H 04e0 l
[Mspgcc-users] quad (long long) issues
Hello,
I am having some issues returning a long long from a function of mine. I found
somewhere on the mspgcc website that when returning a quad word, the msp430
loads r15, r14, r13, and r12.
I am seeing some odd behavior on the other hand.
My function looks like this:
---
static long long TickCounter;
long long StartTimer (ushort delay)
{
long long temp;
temp = TickCounter + delay - 1;
if( temp == RESERVED_FOR_EXPIRATION)
temp++;
return temp;
}
static long long ledtimer;
void someFunction()
{
...
ledtimer = StartTimer(LED_FTC);
...
}
---
When called, temp will equal the correct value (which in this case, happens
to be 0x1DF), and r12-114 = 0, while r15 = 0x1DF. However, ledtimer winds up
being equal to 0x01DF01DF01DF01DF, and r12-r15 all have a value of 0x01DF.
Now here's the interesting part: when I wrap everything up in this struct, it
WORKS:
---
typedef struct {
union {
struct{
long lo;
long hi;
};
long long q;
};
} QUAD;
---
Any insight into this would be great, as I would much rather not have to resort
to this awkward struct everywhere.
Regards,
Nate Bragg
Re: [Mspgcc-users] quad (long long) issues
At 13:36 26-8-2010 -0400, you wrote: Hello, I am having some issues returning a long long from a function of mine. I found somewhere on the mspgcc website that when returning a quad word, the msp430 loads r15, r14, r13, and r12. I am seeing some odd behavior on the other hand. My function looks like this: Which version are you using? long long is broken on GCC3.x on multiple platforms. Nico
Re: [Mspgcc-users] quad (long long) issues
I'm using the windows release mspgcc-20081230.exe, from the sourceforge download area. Also, as a follow on - after reading the assembly listings, I realized that putting long longs on the heap (in this case by making 'temp' static) this problem wouldn't happen. It appears that it has something to do with register overwrites. (i.e., mov r11, r12; mov r12, r13; etc.) Regards, Nate Bragg Re: [Mspgcc-users] quad (long long) issues From: N. Coesel n...@nc... - 2010-08-26 17:56 At 13:36 26-8-2010 -0400, you wrote: Hello, I am having some issues returning a long long from a function of mine. I found somewhere on the mspgcc website that when returning a quad word, the msp430 loads r15, r14, r13, and r12. I am seeing some odd behavior on the other hand. My function looks like this: Which version are you using? long long is broken on GCC3.x on multiple platforms. Nico
