Re: [Mspgcc-users] msp430x1612 header
On 03/30/2017 06:38 PM, Norrathep Rattanavipanon wrote: > Thank you so much for your help, David. Now it compiles perfectly past > that point but I run into another issue (I'm not sure if this is the > right place to post please let me know if its not): > > /usr/lib/gcc/msp430/4.6.3/../../../../msp430/bin/ld: cannot represent > machine `msp:110' > There should be a linker script available as well in the same location. If you have given the compiler the path to that directory it should find it. -I /usr/ti/gcc/include Is what I use. TI moved a lot of information, like device register addresses, from the .h files into the linker scripts some time ago. You should use the provided linker scripts and they will resolve symbols like WDTCTL. -- David W. Schultz http://home.earthlink.net/~david.schultz "Life without stock is barely worth living..." - Anthony Bourdain -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] msp430x1612 header
On 03/30/2017 04:43 PM, Norrathep Rattanavipanon wrote: > Hello, > > I have an old code that compiles with " msp430-gcc -mmcu=msp430x1612 ...". > However, I'm very new and dont have any prior experience in msp430 so I > tried to compile it but it said "warning unable to identify and include MCU > header". So I looked into msp430.h and it does not have any msp430x1612.h. > Is there anyway to run this code with the latest version of mspgcc? Identify a specific part: -mmcu=msp430f1612 -- David W. Schultz http://home.earthlink.net/~david.schultz "Life without stock is barely worth living..." - Anthony Bourdain -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] TI compiler
On 03/23/2017 06:13 AM, Bob von Knobloch wrote: > Do you know where there is proper documentation of their instruction > set? What I have from TI is scant, to say the least. The family guides have complete descriptions. In this case slau144. -- David W. Schultz http://home.earthlink.net/~david.schultz "Life without stock is barely worth living..." - Anthony Bourdain -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] TI compiler
While you didn't explicitly call a function in your interrupt routine, the compiler did for the right shift of TXByte. Making TXByte a signed int makes this go away. (The MSP430 doesn't have a single instruction to do the unsigned right shift.) You don't need for it to be unsigned because you don't care about those bits. A minor nit: Making TXByte and BitCnt volatile buys you nothing except slower code. Their values can't change while the interrupt is being serviced so it doesn't help there. They also can't change while you aren't looking in put_char() because it waits for the timer to finish. -- David W. Schultz http://home.earthlink.net/~david.schultz "Life without stock is barely worth living..." - Anthony Bourdain -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] TI compiler
On 03/22/2017 10:43 AM, Bob von Knobloch wrote: > On 22/03/17 16:24, David W. Schultz wrote: >> Calling another function from the ISR was what triggers this bad >> behaviour. Especially if the called function is in another file. > Hi David, > my code doesn't call a function in the interrupt, it merely decrements a > count, tests it for zero and, if not, sets a port bit hi or low, then > exits. This uses only R13 which is why I'm surprised that all the others > are 'push-pulled'. Your description also depicts not the best behaviour. > > Bob > I just took a look at some generated code for a simple timer interrupt and it only saves 5 registers. Just what it used and nothing else. Compiler version is: msp430-elf-gcc (SOMNIUM Technologies Limited - msp430-gcc 5.3.0.219) 5.3.0 Not quite the latest. -- David W. Schultz http://home.earthlink.net/~david.schultz "Life without stock is barely worth living..." - Anthony Bourdain -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] TI compiler
On 03/22/2017 09:54 AM, Bob von Knobloch wrote: > Inspecting the assembly, I found that the interrupt was suspect. > The 'old' code pushed the registers that it needed, the 'new' TI > compiler pushes (and, of course, later pulls) all of the registers from > r4 - r15 inclusive. I complained about the failure to follow the EABI (which registers a called function is required to preserve) to the TI forums some time ago. (April 2015) Apparently it still isn't fixed. Calling another function from the ISR was what triggers this bad behaviour. Especially if the called function is in another file. -- David W. Schultz http://home.earthlink.net/~david.schultz "Life without stock is barely worth living..." - Anthony Bourdain -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] TI compiler
On 03/06/2017 02:19 PM, Bob von Knobloch wrote: > Hi David, > How have you extracted these from the .elf file? I didn't. You were talking about the .hex file so that is where I looked. The ISRs start out like this: __attribute__((wakeup, interrupt(USCI_A1_VECTOR))) void rxISR(void) -- David W. Schultz http://home.earthlink.net/~david.schultz "Life without stock is barely worth living..." - Anthony Bourdain -- Announcing the Oxford Dictionaries API! The API offers world-renowned dictionary content that is easy and intuitive to access. Sign up for an account today to start using our lexical data to power your apps and projects. Get started today and enter our developer competition. http://sdm.link/oxford ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] TI compiler
On 03/06/2017 10:25 AM, Bob von Knobloch wrote: > Now I have to find out where the vectors have gone - they are missing > from the .hex file. Maybe a different name from the old mspgcc? > TI moved a lot of things into the linker scripts a while back. Each vector now gets its own section and as near as I can tell, these will not appear in the output unless you have an actual ISR defined. I have three interrupt service routines in the program I am using as an example and the hex file includes this: :02FFE6001259AE :02FFEA00A883EA :02FFF400EE55C8 :02FFFE006A5245 I count three interrupt vectors plus reset. -- David W. Schultz http://home.earthlink.net/~david.schultz "Life without stock is barely worth living..." - Anthony Bourdain -- Announcing the Oxford Dictionaries API! The API offers world-renowned dictionary content that is easy and intuitive to access. Sign up for an account today to start using our lexical data to power your apps and projects. Get started today and enter our developer competition. http://sdm.link/oxford ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] TI compiler
On 03/06/2017 09:42 AM, Bob von Knobloch wrote: > Now the linker doesn't want to play with me - it cannot find the > "msp430g2231.ld" link file. Curious because the compiler fids "msp430.h" > in the same directory. I include -Wl,-L$(SUPPORT_FILE_DIRECTORY) in the flags for gcc when linking. SUPPORT_FILE_DIRECTORY having previously been set to /usr/ti/gcc/include -- David W. Schultz http://home.earthlink.net/~david.schultz "Life without stock is barely worth living..." - Anthony Bourdain -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] TI compiler
On 03/03/2017 05:20 AM, Bob von Knobloch wrote: > As far as I can see, the 'bloat' is in library funcs (newlib?). > Why the 50% increase and can I mitigate this somehow? > Regards, > Bob von Knobloch. > Hard to say without seeing the code. Have you looked at the resulting file using objdump? If not, that can disassemble the code into something readable so you can see just what is going on. -- David W. Schultz http://home.earthlink.net/~david.schultz "Life without stock is barely worth living..." - Anthony Bourdain -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Using XIN pin as port or timer output
On 11/28/2016 02:54 AM, Marko Cebokli wrote:
> Any idea what I am doing wrong here?
I suspect that you haven't configured the pin correctly. This simple
program causes P2.6 to toggle along with the LED:
#include
int main()
{
WDTCTL = WDTPW + WDTHOLD;// stop watchdog timer
P1DIR = P2DIR = 0xff;
P2DIR &= ~BIT7;
P2SEL &= ~BIT6;
P2SEL2 &= ~BIT6;
while(1)
{
P1OUT ^= BIT0;
P2OUT ^= BIT6;
__delay_cycles(100L);
}
}
XIN and XOUT connect to the pin headers via 0 Ohm resistors R28 and R29.
If those resistors are not present, then no signal will reach those pins.
--
David W. Schultz
http://home.earthlink.net/~david.schultz
"Life without stock is barely worth living..." - Anthony Bourdain
--
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Mspdebug: "prog" programs vectors, not program code
It has been a while but I seem to remember having a similar problem. Too long ago to remember details but I think it was a problem with the section flags. You can check the flags using msp430-elf-readelf -S XX.elf -- David W. Schultz http://home.earthlink.net/~david.schultz "Life without stock is barely worth living..." - Anthony Bourdain -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://sdm.link/zohodev2dev ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] assembler vs extension words
On 02/03/2016 06:29 AM, Nick Clifton wrote:
>> directives. objdump produced:
>>
>> rpt r15 { rrcx.wr6
>>
>> Which is almost but not quite correct because it ignores the little
>> detail of the extension word having the ZC bit set.
>
> True - this is really the same bug. GAS is not encoding RRUX correctly,
> so it is not being decoded correctly either.
I didn't phrase that well. The code executes as expected for all the
shift counts I tested but objdump doesn't decode and display the ZC flag.
As for the synthetic instruction thing, there is a table of extended
emulated instructions but rrcx isn't included. When I look at the
instruction encoding, rrcx.w has the same encoding as the non-extended
rrc.w instruction but has a register mode extension word in front of it:
52aa: cf 19 06 10 rpt r15 { rrcx.wr6
52ae: 06 10 rrc r6 ;
52b0: 40 18 06 10 rrcx.w r6
On the other hand, rrux.w gets encoded as a single word instruction from
the new extended instruction group:
52b4: 56 03 rrum#1, r6
I can't find any hint of these details in the documentation. I wonder
where someone writing an assembler is supposed to find this stuff.
(I forgot to include the as version before: 2.24.51.20140505)
The patch might have been of some use to me if I had built as from
sources. It has been a long time since I have done that.
--
David W. Schultz
http://home.earthlink.net/~david.schultz
Returned for Regrooving
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
[Mspgcc-users] GNU assembler problem with jump target address
Some of my assembler code is suddenly afflicted with a strange bug. Jump instructions have an offset to the start of the code area rather than their intended target. To make it even more mysterious, it doesn't always happen. The key appears to be that the target symbol has been declared as global: 49e4 : 49e4: a2 b3 6c 06 bit #2, &0x066c ;r3 As==10 49e8: 0b 27 jz $-488 ;abs 0x4800 49ea: c2 4f 4e 06 mov.b r15,&0x064e ; 49ee : 49ee: 92 b3 6c 06 bit #1, &0x066c ;r3 As==01 49f2: fd 27 jz $-4 ;abs 0x49ee 49f4: 5f 42 4c 06 mov.b &0x064c,r15 ;0x064c 49f8: 30 41 ret ucb0rw has been declared as global while the other symbol has not. Because of another problem I had with the assembler, gas is invoked with option "-mQ". Disabling that option makes this error go away. (It might not be the assembler that is at fault here but the linker. Changing the gas option does fix it so I will go with the assembler.) Assembler version is: GNU assembler (GNU Binutils) 2.24.51.20140505 -- David W. Schultz http://home.earthlink.net/~david.schultz Returned for Regrooving -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140 ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] while(flag)
On 11/08/2015 04:01 PM, Ian Chapman wrote:
> Hi all,
> I'm having difficulty understanding this situation.
> flag = 1;
> while ( 0 != flag )
> {
> code;
> }
If flag is changed within an interrupt, it must be declared as volatile:
volatile int flag;
Otherwise the compiler will see that it never changes and optimize
accordingly.
--
David W. Schultz
http://home.earthlink.net/~david.schultz
Returned for Regrooving
--
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] New MSP430 GCC version release available!
On 10/17/2015 03:35 PM, Lev Serebryakov wrote: > Hello DJ, > > Saturday, October 17, 2015, 10:55:52 PM, you wrote: > > >> 1. Are you cross-building a compiler? I.e. is the host you're >>building *on* different than the host (not target, which is msp430) >>you're building *for*? (This is called a "canadian cross" and is >>much more complicated than a regular cross compiler). > Nope. *host* and *build* are both the same. > >>(one typically cross-builds by accident by specifying --build or >>--host but not both, or by specifying both but not having them the >>same.) > >> 2. Are you building in the source tree? If so, that is not supported, >>you must always build in a separate (empty) directory. > Oh, it looks like my error. I'm trying to build out-of-tree now. > I built the TI version from source a while back. I don't recall exactly what I did but fortunately, it remembers. I created the directory ti/gcc/sources/tools/msp430-build The config.log reveals that I ran from that directory: ../configure --target=msp430-elf --program-prefix=msp430-elf --with-newlib gcc has a lot of build options and by default it is going to build a lot of stuff you have no interest in. Taking a long time to do it. I also played with building a version for the 68000 with: ../configure --target=m68k-elf --with-arch=m68k --program-prefix=m68k- --enable-languages=c --disable-libmudflap --disable-libssp --disable-libgomp --disable-libstdcxx-pch --disable-threads And since that was in its own build directory, it didn't conflict at all with the msp430 build. It is almost certain that there is an optimal set of options for the task but I don't know what they are. -- David W. Schultz http://home.earthlink.net/~david.schultz Returned for Regrooving -- ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] odd code generation
Answered my own question, sort of. The TI version of gcc doesn't have the hooks to linker defined symbols like mspgcc did so I edited the linker script to provide symbols defining the information memory. I also used the now missing crtld.h as a guide and included "char __infoc[];" When I changed that to a type int, the generated code is much better. So the compiler is seeing the type cast but remembering that the original type is char. It is also apparently assuming that the alignment will be completely random so generates code assuming misalignment. Easily fixed in my case but still very surprising. -- David W. Schultz http://home.earthlink.net/~david.schultz Returned for Regrooving -- ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
[Mspgcc-users] odd code generation
I am trying to understand why the TI gcc compiler (version from 9 Feb 2015) is generating some wildly inefficient code. The line: v = corrected(results[0]) - p->offsets[0]; Appears to generate this: 2fe0: 1c 42 7e 03 mov &0x037e,r12 2fe4: b0 12 9e 2f call#0x2f9e 2fe8 <.LVL12>: 2fe8: 3d 40 40 10 mov #4160, r13 ;#0x1040 2fec: 5e 4d 02 00 mov.b 2(r13), r14 ;0x0002(r13) 2ff0: 5d 4d 03 00 mov.b 3(r13), r13 ;0x0003(r13) 2ff4: 0d 5d rla r13 2ff6: 0d 5d rla r13 2ff8: 0d 5d rla r13 2ffa: 0d 5d rla r13 2ffc: 0d 5d rla r13 2ffe: 0d 5d rla r13 3000: 0d 5d rla r13 3002: 0d 5d rla r13 3004: 0d de bis r14,r13 3006 <.Loc.223.1>: 3006: 0c 8d sub r13,r12 3008: 30 41 ret In spite of the type for offsets being an int, the compiler generates code that fetches it a byte at a time and then shifts to combine. This is with optimization on. (-O2) Looking at some other spots where I read the information memory, it also reads it a byte at a time. Why is it being so stupid? Even the shift is stupid since a single swpb would do the trick. -- David W. Schultz http://home.earthlink.net/~david.schultz Returned for Regrooving -- ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] New MSP430 GCC version release available!
On 09/20/2015 11:17 AM, Ghannouchi, Youssef wrote: > Hello GCC-enthusiasts, We are pleased to announce a new stand-alone & > open source release (v3.5.0.0) of MSP430 GCC I don't see any mention of a fix to the compiler saving more registers than required when entering an interrupt routine. Its like it completely forgot about the EABI. -- David W. Schultz http://home.earthlink.net/~david.schultz Returned for Regrooving -- ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
[Mspgcc-users] relocation error
Here is a puzzler. I have been fiddling with a version of Camelforth for the FRAM parts in an ill fated attempt to port it to the MSP430FR5969. The original code is for the IAR tools but I use gcc. After much gnashing of teeth and assorted hacking I have an error that I don't know how to fix or even if it can be fixed. The code uses a few macros to automate production of FORTH headers and the trouble is with the link field which creates a linked list of headers. Cutting it down to a small program that recreates the error: .text .globl main main: .equ link,0 .word link .equ link, . .word link .equ link, . .end test.S:7: Error: redefined symbol cannot be used on reloc Line 7 being the second .word link The really interesting thing is that while this fails on the newfangled TI version of msp430-elf-gcc, aka: msp430-elf-gcc (GCC) 4.9.1 20140707 (prerelease (msp430-14r1-167)) (GNUPro 14r1) It works just fine on my old msp430-gcc. aka: msp430-gcc (GCC) 4.6.4 20130412 (mspgcc LTS 20120406 unpatched) Is there something I am doing wrong or did someone break the assembler? -- David W. Schultz http://home.earthlink.net/~david.schultz Returned for Regrooving -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Can the RESET_VECTOR be redefined at compile time to a specific value?
On 04/18/2014 12:08 PM, Tomek Lorek wrote: Is that doable? How can I define in the application’s code that the reset vector (0xFFFE) shall contain the bootloader’s init code (0x4400)? Why not let the bootloader take care of this? Once you have a bootloader in place the idea is to let it load the main program. Since it is in charge of that process it can make sure that the reset vector gets loaded with the desired address. -- David W. Schultz http://home.earthlink.net/~david.schultz Returned for Regrooving -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] mspdebug
On 09/26/2013 08:12 AM, Ian Chapman wrote: usbutil: unable to find a device matching 0451:f432 The first step is to see if anything is there using lsusb. You should see something like: Bus 003 Device 002: ID 0451:f432 Texas Instruments, Inc. eZ430 Development Tool If it is working. Recently the Launchpad has been giving me fits which is why I pulled out a JTAG unit. At times the Launchpad works but other times it fails to enumerate. (use dmesg to view information spit out as it tries to connect) -- David W. Schultz http://home.earthlink.net/~david.schultz Returned for Regrooving -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] 16x16 multiply, schrinked result
On 02/19/2012 01:43 PM, Miloslav Semler wrote: Which is wrong for me as it discards high word from result (RESHI is not copied, instead it is used an sign extension). Routine div32768 accepts 32bit signed integer. You seem to be complaining that a 16X16 multiply returns only a 16 bit result. This is standard across all C compilers. If you need a 32 bit result you have two options: 1) Promote one or both arguments to 32 bits to force a 32X32 multiply with a 32 bit result. 2) Roll your own code if you need something faster. It is possible that buried somewhere in the standard library is a function that does this but I have never seen one. -- David W. Schultz http://home.earthlink.net/~david.schultz Who? What? Where? When? Aahhhg! - Duck Dodgers -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Examples of msp430-as with symbolic operands
On 02/17/2012 11:34 AM, Peter Bigot wrote: A couple lines are commented out because the current assembler won't process them, something I consider to be a bug. I would be interested in knowing if other tools accept $ as denoting the program location counter in contexts other than jump instructions, and if so whether it means the beginning of the instruction or the address of the offset encoded internal to the instruction. I usually use . for the current location. jmp . jmp .+0 jmp .+2 jmp .+0x100 produces: 44: ff 3f jmp $+0 ;abs 0x44 46: ff 3f jmp $+0 ;abs 0x46 48: 00 3c jmp $+2 ;abs 0x4a 4a: 7f 3c jmp $+256 ;abs 0x14a Looking at the documentation (info gas) in machine dependencies it says: The character `$' in jump instructions indicates current location and implemented only for TI syntax compatibility. So I would say that using $ in the mov instructions shouldn't be expected to work but that the implementation for using $ in jumps is messed up. Digging into the source (not the appropriate version but what I recently grabbed while playing with things ARM Cortex-M4, aka 2.22.51) it looks like this is in tc-msp430.c. At least I find the error message instruction requires label sans '$' there. But I have never dug down into the internals of gas so things get murky after this. I do see a fixup of the offset that specifically excludes zero. if ((*l1 == '$' x 0) || x 0) x -= 2; -- David W. Schultz http://home.earthlink.net/~david.schultz Who? What? Where? When? Aahhhg! - Duck Dodgers -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] msp430-gcc using wrong assembler..
On 11/19/2011 04:26 PM, Andy Warner wrote: Has anyone else encountered anything similar, or got any suggestions to try and fix this ? I had this problem and it was because the build scripts assumed that ./ appears nowhere in your search path. I posted a note here on 18 Feb. http://sourceforge.net/mailarchive/forum.php?thread_name=4D5EFBBD.6040505%40earthlink.netforum_name=mspgcc-users -- David W. Schultz http://home.earthlink.net/~david.schultz Put down that pickle! -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Custom linker file
On 08/05/2011 05:09 PM, Alex Stefan wrote: Hello, I am working on a custom bootloader. For the time being I am trying to the main code to a higher address and create a custom section to hold the bootloader code. I plan on adding a bootloader to my current project but haven't quite reached that stage yet. But I have given it some thought and I think my plan is a bit different from yours. My plan is to link two stand alone programs. I have to do this eventually as the point is to be able to load the main program without using JTAG. The first is the bootloader and nothing special needs to be done while building it. The second is the main program. The only thing special I will need to do to it is to make sure that the code starts at a higher address. I can think of two ways of doing that: tell the linker (I think there is a flag for this), or lie about the processor. (ie. claim that I am using a device with less flash) The bootloader will manage the process of loading the main program. One special thing it will do is when it writes the vectors replace the reset vector with the start point for the boot loader. This way I can have the boot loader run at reset but have all the other vectors behave as usual for the main program. The main program should have no idea that it was started by the bootloader. I hope. As usual, plans will change to reflect reality. :-) -- David W. Schultz http://home.earthlink.net/~david.schultz Pooh just is. Tao of Pooh -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
[Mspgcc-users] mspgcc4 build failure and work around
I have been using the antiquated cdk4msp version of mspgcc for several years and finally decided to try and get with the times. So I grabbed the latest version of mspgcc4 from git today and tried to build it. Things went well for a while but then died. Digging down into the error logs I found this in...mspgcc4/build/gcc-4.4.5-build/gcc/config.log: gcc version 4.5.1 20100924 (Red Hat 4.5.1-4) (GCC) configure:2400: $? = 0 configure:2402: gcc -V /dev/null 5 gcc: '-V' option must have argument configure:2405: $? = 1 configure:2428: checking for C compiler default output file name configure:2431: gcc -g -O2 conftest.c 5 /opt/msp430-gcc-4.4.5/msp430/bin/as: unrecognized option '-Qy' configure:2434: $? = 1 I was noodling around, reading the info pages for 'as' trying to find out what option -Qy was supposed to mean. I didn't find it there and decided to try 'as -h' on a lark. I was somewhat surprised when it told me it was the msp430 version. Then I noticed that my current directory was in the gcc build directory (I was looking at config.log) and sure enough 'as' was there. Then a light bulb went on and I realized that so long ago that I have nearly forgotten about it I had edited .bash_profile to include the current directory at the start of my search path. This was causing gcc to find the just built msp430 version of 'as' in the current directory instead of the intended native version. After editing the PATH I started the build process again and all went well. Is this problem deserving of a bug report? -- David W. Schultz http://home.earthlink.net/~david.schultz Life without stock is barely worth living... Anthony Bourdain -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
