Re: [Mspgcc-users] TI compiler
Could you post your interrupt code (C) and the resulting assembler? It's hard to debug problems without seeing those... -- 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
Bob von Knobloch writes: > 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. Add "-v" to your gcc line, it will show you more info on where it's searching for things. Note that the linker and the preprocessor use different search paths; the path to the linker script may come from gcc (via -L or an absolute path) or from the linker's built-in path. You can also use "strace -f -o /tmp/foo gcc . . ." to capture all the places it searches for files (grep for msp430g2231 in that file), which might help. -- 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
This has come up before, and here's what's going on... the new msp430-elf-gcc includes all the code required by the standard, partly because... well, standards... and partly so that the testsuite can test everything. The old msp-gcc made lots of assumptions about how the compiler would actually be used, and "pre-optimized" the runtime for it. So you end up with things like "argv handling" when there's no command line, or "exit closes files" when you never exit. A big change is using a float-enabled printf when you don't need it. I put some notes here, way back when, but they're old, and IIRC it's been improved even more since then: http://people.redhat.com/~dj/msp430/size-optimizations.html Also, you can use "msp430-elf-gcc -mintr ..." to minimize the runtime support. Also, if you're REALLY constrained to size, you might consider getting the crt0.S source file from newlib and modifying it yourself to really strip out the parts you don't need. Most embedded code really only needs to set up the stack and watchdog, then jump to main(). -- 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] New MSP430-GCC release available!
Lev Serebryakov writes: > Was support for Insight TK frontend dropped? I could not find > "gdbtk" in sources. Yes, gdbtk was dropped from upstream in 2013. It's a separate repo if you want to try to use it; we did the work to integrate it for our 2014 release but it was a lot of work, so we decided not to do it in the 2015 release as the divergence was even more, and most of our customers switched to Eclipse (or other IDEs) anyway. https://github.com/monnerat/insight -- ___ 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!
> Agenda VR3 (did you remember this very first Linuix-based PDA with > MIPS-based CPU?) Yup, I was involved with the project way back then. > Could you please clear situation with debugging (in separate thread in > mailing list)? Sorry, that's a TI question, they provide the DLLs and SOs for that. -- ___ 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!
> To be honest, your (RedHat + TI) way is worst possible one :-( Worst for your purposes, perhaps. We just have a different goal - a turnkey custom collection that "just works" for our customers. That means we normally include things that wouldn't be included in a system package. What you want is an "upstream" collection, broken down by packages, with the latest greatest of each package. Over time, the upstream releases with msp430 support will happen and allow that. Often we do releases for customers that can't go upstream right away (usually because the chips are still NDA, which is obviously not the case for MSP430 ;) so our workflow is geared towards self-sufficiency. And BTW I know all about packaging rules, I do after all work for Red Hat, we have a distro or two ourselves :-) -- ___ 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!
> Yep, it works, modulo DESTDIR problems, which could be easily patched. We've always used a separate --prefix for each release (typically /opt/redhat/msp430-YYMMDD/) so we wouldn't notice. > I'm not sure, that toolchain need all these separate tcl and tk > stuff (system already has them!), but it is better than nothing > (though, very Windows-like!). No surprise, we support windows :-) And not all Unix-y systems have those, either. Even Linux is the user hasn't chosen to install them yet (which is commonly the case). -- ___ 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!
Two questions: 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). (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. -- ___ 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!
That should be built as part of building gcc/ so you probably have a problem earlier on that you didn't see in your logs... -- ___ 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!
> It is clang 3.4.1, and I don't want to install gcc, if it is possible to > avoid with some "simple" patch :) IIRC there's an option in clang to use the old semantics (-std=gnu89). -- ___ 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!
You're probably running into a common problem with "static inline" vs "extern inline" - the semantics of those changed with the recent C standards, so not all compilers do the same thing. I assume you're not using GCC? -- ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] New MSP430 stand-alone GCC version release available!
> (1) Sources could not be downloaded automatically. You need browser. > What should distributive build cluster do? There's nothing magic about downloading the sources, just use any command-line URL tool (wget, curl, etc): wget http://software-dl.ti.com/msp430/msp430_public_sw/mcu/msp430/MSPGCC/latest/exports/msp430-gcc-source.tar.bz2 > (3) There are no instructions at all! > > ./configure --prefix=/usr/local --target=mdp430 && gmake all I use ./configure --prefix=... --target=msp430-elf --enable-languages=c,c++ && make && make install If you're building the upstream sources, it's a bit trickier because they're separate packages, but as long as you use --target=msp430-elf any of the "how to build a cross compiler" instructions should suffice. > fails in early stages with different problems, looks like it is very > Linux-specific (stock binutils/gcc could be build virtually anywhere!) It shouldn't be Linux specific. We build it for Linux (native) and MinGW (cross). If you include the specific error messages perhaps we could suggest solutions... Note that - in general - cross builds tend to have stricter requirements about available tools than native builds. For example, a cross gcc build is allowed to require that the native compiler is g++, whereas a native gcc build has to allow pretty much any C++ compiler. (Also note that *I* don't like unneeded restrictions, and other compilers should work fine as long as they're mostly compatible :) -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] relocation error
Just a request, when reporting errors against the assembler, please give the assembler's version number, not the compiler's version number: $ msp430-elf-as --version GNU assembler (GNU Binutils) 2.25.51.20150212 FWIW I've reproduced this with the FSF assembler reporte above, which is the binutils development trunk version. Also FWIW, I think defining one symbol to have two values is a bad idea... -- 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=190641631&iu=/4140/ostg.clktrk ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] msp430-gcc-full-linux-installer-2.1.1.0.run
> Is there an option that I missed to force it to build for the non > MSP430X memory-model? If you specify -mmcu= when compiling, specify the same -mmcu= when linking, else the tools don't know which libraries to use. If that fails, add -mcpu=msp430x or -mcpu=msp430 to force the issue. -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] msp430-elf-g++ optimizing out main()
> The map file is telling me a few small functions are being linked in > (memset, memcpy) and I assume that since the standard library wasn't built > with -ffunction-sections or -fdata-sections that it then links the entire > library. -ffunction-sections affects multiple functions in the same object. It has no effect on separate objects. Functions like memcpy() and memset() are in separate source files in the library, so will be linked in or not depending only on whether or not they're actually needed. > Is this also a side effect of the library not being build with those > sections flags? If so, why isn't the library built like that for > cases like this where you want to have only a few small functions? One could argue that the library should be built with whatever flags the user specifies. This quickly turns into thousands, if not millions, of permutations of builds, and is not practical. The only way to solve this is to build the whole library as part of your project, so you can choose the flags you want. Also, the -ffunction-section and -fdata-section flags are mostly useless for the standard libraries *anyway*, as, as I mentioned already, they're already broken into one function per section. The -minrt option is designed to work mostly with the startup code, by selectively linking in parts of (what is normally) crt0.s based on a more "global" knowledge of features used by the program. If you use a C++ function that uses exceptions, the exception startup gets linked in. Without -minrt, the exception startup gets linked in even if nothing uses exceptions. -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] msp430-elf-g++ optimizing out main()
main() is not a root with gcc, start() is (defined by your linker script), and is usually provided by crt0.o - except you told it not to with -nodefaultlibs. The flag you really want is -minrt, which tells gcc to encode extra information in each object that helps the linker reduce the amount of runtime needed to only the routines that will actually do something useful (and, most likely, remove C++ constructors/destructors at the same time). If even with that flag the code still doesn't fit, add -Wl,-Map,somemap.txt and see *what* functions are getting included, and why. It may turn out to be something silly. Also, if main() returns a value, the runtime may include extra processing to happen at exit() time, which is kinda pointless on an MCU. main() should end in a while(1); so it doesn't return. -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] replacing libgloss in msp430-elf
> It's not really feasible to extract those changes and apply them to a > non-bundled source directory since the base version isn't exactly GCC > 4.9.1.If you or TI could provide information on whether those > patches are likely to get refactored and merged upstream, and any > timeline information that's available, I think most folks here would > be interested. You need my __intN patch set, currently being reviewed upstream. Some parts have been approved and applied, but you still need the main conversion (3/5, pending libg++ review) and the msp430-specific part (5/5, just waiting on part 3/5). This patch set is based on the TI-specific patch in their 4.9 sources. https://gcc.gnu.org/ml/gcc-patches/2014-08/threads.html#01398 -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] No clue for thsi....
> -mmcu=msp430f449 -O2 -Wall -Wno-old-style-declaration -std=c99 By specifying "-std=c99" you have disabled all the GNU extensions, including "asm". Try --std=gnuc99 instead, or replace "asm" with "__asm__" in those headers. -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] msp430-elf-gcc (GCC) 4.9.1 20140707 (prerelease (msp430-14r1-10)) (GNUPro 14r1) (Based on: GCC 4.8 GDB 7.7 Binutils 2.24 Newlib 2.1)
The GCC manual, chapter "Extensions to the C Language Family" section
"Function Attributes" documents the interrupt attribute:
void f () __attribute__ ((interrupt (15)));
or
void __attribute__ ((interrupt (15))) f ()
{
}
Note that the attribute tells gcc to create a section
__interrupt_vector_15 (in this case) that contains a pointer to the
function. It's up to the linker to combine these sections into your
interrupt vector table, so make sure you either use TI's runtime or
understand what gcc is doing behind the scenes. Use "msp430-elf-gcc
-S file.c" or "msp430-elf-gcc --save-temps ..." to get access to the
*.s assembly files to see what's going on.
--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Packaging for msp430-elf-*
> Thanks. I see that arm-elf-gcc includes newlib in the compiler > package. I’m able to build binutils just fine, unfortunately gcc has > some errors with clang (stray ‘-static-libgcc’ options that are not > supported by clang). While a native GCC build is likely to be built with alternate compilers, most cross compilers assume they're being built with gcc itself. I don't do anything gcc-specific myself, but the general framework might be so. > Is msp430 support present in the latest gdb, too? Yes. If you want to debug the built-in simulator, use "target sim". To debug hardware, you'll need a gdb-remote-compatible hardware driver, such as the TI debug DLLs, and use "target remote". -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] MSP430 simulator in gdb
> Will TI be providing sufficient documentation on the CIO API that the > msp430 implementation can be completed, thus making the system > interface usable in other frameworks? http://processors.wiki.ti.com/index.php/CIO_System_Call_Protocol -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Packaging for msp430-elf-*
> Ah, yes, sorry. What I meant was can msp430-elf-gcc be built without > newlib? I wanted to create a separate package for newlib. Typically, the gcc runtime (libgcc) needs to know what the "usual" runtime will be, as some routines in libgcc may need to call C library functions. The usual way to build it is to do it in two steps so that things like stdio.h et al are available to the libgcc build. I haven't tried to build libgcc before newlib in a long time, but if it works, either things have changed or you just haven't noticed the problem yet ;-) -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Packaging for msp430-elf-*
> Also, why are you building msp430-elf-gcc in two steps, Peter? Can I > build newlib first and then msp430-elf-gcc? How do you build newlib without a C compiler? -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] replacing libgloss in msp430-elf
The reason msp430 is different is because CIO *can* be used on real hardware, to communicate through a hardware debugger or emulator pod. Perhaps moving the cio-enabled nosys to a libcio.a? Then we'd need a -mcio option to gcc to enable it, but could default to doing the generic nosys thing... -- 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] MSP430 simulator in gdb
> You can do that with the RH newlib as long as you don't link in > libgloss's versions of the low-level routines - i.e. remove -lgloss > from your link line and add -lbspacm. To clarify: don't link in -lnosys if you're not compiling with "-msim" or don't link in -lsim if you are compiling with "-msim" Both of these are linked at the same point as libc and libgcc, by the gcc driver, depending on whether or not you use the -msim option. Both are from libgloss, but have slightly different versions of some functions to compensate for the differences between the simulator and real hardware, mostly the non-CIO system calls like exit(). -- 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] MSP430 simulator in gdb
> Can you elaborate on "branch-to-self" opcode?
Any branch opcode that branches to itself, i.e. a one-opcode infinite
loop.
1: BR #1b
This also works with any indirect or conditional branch, as long as
the target of the branch is the address of the branch opcode. Here's
the code in the simulator at the end of the branch handler ("u1" is
the true/false conditional, which is "true" for unconditional branches
of cours):
if (u1)
{
if (TRACE_BRANCH_P (MSP430_CPU (sd)))
trace_generic (sd, MSP430_CPU (sd), TRACE_BRANCH_IDX,
"J%s: pc %#x -> %#x sr %#x, taken",
cond_string (opcode->cond), PC, i, SR);
PC = i;
if (PC == opcode_pc)
exit (0);
}
else
if (TRACE_BRANCH_P (MSP430_CPU (sd)))
trace_generic (sd, MSP430_CPU (sd), TRACE_BRANCH_IDX,
"J%s: pc %#x to %#x sr %#x, not taken",
cond_string (opcode->cond), PC, i, SR);
The other way to call exit() (in the RH simulator) is to call 0x181 as
if it were the C function exit(). The simulator traps "call to
0x18" and does a syscall instead of the call. This is a
non-standard interface though, but the only way to call exit() with a
non-zero return code.
> What is the inline asm syntax that will give me this?
Just do this:
for(;;);
or this:
#define exit() __asm__ volatile ("1: BR #1b")
--
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] MSP430 simulator in gdb
> I'd already outlined my expectations in the earlier thread; see for > example > http://www.mail-archive.com/mspgcc-users@lists.sourceforge.net/msg12038.html. > If the msp430 version supplies a weak definition of _write() (not > write()) newlib uses either write() or _write() depending on which the underlying libraries provide. There's no difference between then as far as which you provide. If you'd like to propose changing which of the two newlib looks for by default, I'm OK with that. There's no standard there, and newlib doesn't provide a write() that calls _write_r() regardless. > that goes through CIO, we're good because I can replace it *If* you link in libgloss (you don't have to), *and* you don't provide a copy of write(), *then* a copy that uses CIO is linked in via -lgloss. So go ahead and replace it. > with one that delegates to a descriptor-specific implementation. If > the definitions aren't weak, we're probably not good. It's in a library, one per object. If you provide your own, the linker won't link in the libgloss version. It doesn't need to be weak. > I'll hold off on further comment until I have an opportunity to see > what actually needs to be done to make this work. I expect something > that allows me to do for the msp430 what I did for ARM as described > at: http://pabigot.github.io/bspacm/newlib.html#newlib_sys You can do that with the RH newlib as long as you don't link in libgloss's versions of the low-level routines - i.e. remove -lgloss from your link line and add -lbspacm. -- 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] MSP430 simulator in gdb
> That doesn't really help the rest of us, though. Yup, I've complained to TI about that. I'll bring it up again. > I'm interfacing with other external hardware including LCDs and FAT > file systems, and I want to re-use the standard libc interface at > the application layer. Could you elaborate on this? Are you talking about real hardware talking to real peripherals, or is there a host involved? > Like Mark, one of my needs is for input as well as output. For ARM, I > can take a binary toolchain from launchpad with a pre-built newlib and > substitute a new system interface that meets my requirements. As long > as I can do the same thing for the msp430 one, I'll have no issues > with the default solution being CIO. None of the CIO stuff interferes with the ANSI routines in newlib/libc. You still use printf() and fopen() etc. The CIO code is at the very bottom in libgloss, where it provides a CIO-specific write() call. If you have some other low-level I/O routines, like a serial port or lcd, just provide your own read() and write() functions and the rest of newlib will "just work". -- 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] MSP430 simulator in gdb
> Is this documented? How can I write drivers to this standard? That's the catch. It's not documented. I have a sample implementation from TI that I used (with permission) to write the simulator/libgloss code. In general, though, the target side works like this: fill up a "command buffer" at __CIOBUF__ and branch/call an opcode at C$$IO$$ The host sets a breakpoint at C$$IO$$. When it's hit, it reads the command from __CIOBUF__ and "does it", which may involve reading data from the buffer and/or writing results back, then resumes the target. The target then looks at __CIOBUF__ to get the results of the syscall. The target side of this is at newlib's libgloss/msp430/ (part in cio.* and part in write.c) The simulator side of this is at gdb's sim/msp430/msp430-sim.c in msp430_cio(). A lot of the to/from buffering is common. -- 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] MSP430 simulator in gdb
> Will TI be providing sufficient documentation on the CIO API that the > msp430 implementation can be completed, thus making the system > interface usable in other frameworks? I have enough information to finish the msp interface, I've just had no reason to do so so far. CIO doesn't have exit() though so the RH simulator *also* has its own syscall interface, just for that call. If you just want to "exit cleanly" a branch-to-self opcode will also trigger an exit(0) from the RH simulator. > I personally would wish that newlib prefer APIs that are not > proprietary. My intent for my own msp430-elf projects is to implement > a msp430 libgloss approach that's much closer to what was done in the > arm target for libgloss. If there's a chance that'd be adopted > upstream as an alternative to the CIO one, it'd motivate me to make > that a priority. CIO was used at TI's request, to be compatible with their simulators and their hardware drivers - I.e. a CIO library in your app would work in the simulator *and* on real hardware - I think this works with msp430-elf-gdb also. -- 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] MSP430 simulator in gdb
> You need to be using msp430-elf-gcc for that feature, not mspgcc as Right, as previously agreed on, we're using "msp430-foo" for the non-RH tools, and "msp430-elf-foo" for the RH tools. -- 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] MSP430 simulator in gdb
> Wait, a write() syscall made in the msp430 binary can show up on stdout of > the simulator? How does that work? Do I need to link in any special > function for that? The RH simulator (msp430-elf-run, not msp430-run) supports TI's "CIO" interface, at least for write(), which means the RH simulator can write to stdout (we use it for testing). CIO supports a range of file I/O operations, but we only implemented write(). The code in libgloss (part of newlib) has an implementation of CIO and write() that works with the simulator. > I don't know what a "vpu" is, so I am spared from confusion... I dodn't know either, but it was an unused command line option so I used it :-) -- 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] MSP430 simulator in gdb
> Is there any best way to pass data in / out of the simulator? I > guess I can use the "run" program and set up a memory region for the > input data, and write a little main() to feed it into through the > algorithm. But if there's an easier way, I'd like to hear about it > before I do it the hard way. If you link in your input data via a linker script, and write() out the output data to stdout and redirect it, it should be pretty easy to set up. msp430-elf-run also has command line options to map files to memory regions, see "msp430-elf-run --help" for help. (er, a note about msp430-elf-run - the --trace-vpu command traces register changes, not the "vpu") -- 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] MSP430 simulator in gdb
Could you try the gdb from the FSF's source tree? It's version 7.7 and has the RH simulator in it. However, I don't think the profiling results from the RH simulator will be useful to you if you want cycle-accurate counts, but it will show you every single instruction being executed. Also, there's a standalone simulator msp430-elf-run that has some profiling command line options, not sure if those would be helpful. -- 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] Unable to use LARGE MEMORY MODEL with RH GCC
Sorry, I don't know anything about CCS, just about the gnu tools themselves. You'll have to wait for someone from TI to reply. -- Time is money. Stop wasting it! Get your web API in 5 minutes. www.restlet.com/download http://p.sf.net/sfu/restlet ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Unable to use LARGE MEMORY MODEL with RH GCC
The right way to enable large model is to use -mlarge If that causes problems, we'd need to know more about the problem to try to diagnose it. Note that adding -mlarge means that *all* objects and libraries must be recompiled with -mlarge, you can't mix and match large and small model. -- Time is money. Stop wasting it! Get your web API in 5 minutes. www.restlet.com/download http://p.sf.net/sfu/restlet ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Are here any msp430-elf target full toolchain build instructions a'la gcc-arm-embedded?
> (1) Is newlib-nano supported? > (2) Is C++ supported? Tricky questions. Technically, if you don't have a support contract with someone, the answer is "no" because, well, because ;-) But the answers you probably want are... I haven't tried newlib-nano but there's no reason why it wouldn't work. The tools support C++ although getting it to work well in smaller RAM'd chips might be tricky. We test it internally, but our simulator has lots of RAM. Heck, the tools probably support other languages as well but we haven't tested them. -- "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Are here any msp430-elf target full toolchain build instructions a'la gcc-arm-embedded?
> DD> so yeah, it's probably what people want. The only exception would be, > DD> for example, if you were packaging for a distro and you want to > DD> support upgrading. In those cases, it's better for the packaging if > DD> the package version numbers match the upstream version numbers, which > DD> means separate packages. > So, there is contradiction between requirements :) Not quite. For distros, you have a separate package which is the "collector" for all the other packages. For example, if you installed "mspgcc" then that package would automatically pull in all the sub-packages like gcc, binutils, etc, and let the sub-packages update independently of the collector package. > And it contradicts to building separate packages too, because you > could not build and install half of a package Not much I can help with here, the upstream sources are what they are. Even porting linux to new architectures, we run into these problems. The solution is that someone does it manually once, and after that, you build each package using the previous version of the other package each time. -- "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Are here any msp430-elf target full toolchain build instructions a'la gcc-arm-embedded?
There's nothing special about the msp430-elf tools; you cross-build them just like any other embedded toolchain. If you can, use the latest versions of gcc, binutils, gdb, and newlib (which is typically the development head if there hasn't been a recent release). If you download the TI build of the tools, you'll get one cohesive package, so yeah, it's probably what people want. The only exception would be, for example, if you were packaging for a distro and you want to support upgrading. In those cases, it's better for the packaging if the package version numbers match the upstream version numbers, which means separate packages. As for the two-stepping of gcc, note that modern gcc releases have separate host and target parts of the build. You do "make all-host; make install-host" at first, which gives you the compiler but not the runtime, then you build the libraries, then go back to gcc and do "make all; make install" to do the rest. This is needed regardless of which runtime you use. -- "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] msp430-elf-gcc upcoming release
> I see. I guess to me a "syscall interface" implies something other > than a normal C function call to a function that's linked with the > caller. It does to me too. The *implementation* of those standard C functions may involve some sort of interface that's known to the debugger/simulator as well. In the case of msp430-elf-libgloss, that interface is CIO, but it could involve designated interrupts or a simulated I/O peripheral. But that syscall interface is hidden in the libgloss C function calls. In other cases, there might not be a syscall interface, if the C functions interface directly with hardware, such as a serial port or LCD interface. But I don't think any of the implementations involve a separate OS running *on the chip*, which talks to your app with a well-known interface, similar to how (for example) the Linux kernel talks to apps running on a Linux machine. Note, however, that there *is* a newlib port for running on a native x86 Linux platform, which *does* use the Linux kernel syscall API, but not for the MSP430. In *that* port, the _read() et al C functions call the Linux kernel syscall. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] msp430-elf-gcc upcoming release
> But it's not called like a normal C function, it goes through some > sort of syscall interface so you don't actually link your _write() > function with newlib? It *is* called like a normal C function. You really do just link libgloss.a (or your equivalent) in with your app like you would any other library. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] msp430-elf-gcc upcoming release
> So I'm guessing DJ implemented a default hardware I/O implementation in > libgloss > that uses the CIO infrastructure (no idea what that is, but I'm guessing it > uses > the JTAG Mailbox system somehow to talk with the debugger host? in which case > I'd love to play with it that... assuming mspdebug can support it) In a nutshell... the target fills in a structure at a "known" address, then executes an opcode at a "known" address. The debugger/simulator/whatever traps execution at that address, then looks at the structure to decide what to do. In the CIO case, the "known" addresses are based on symbols in the symbol table. So as long as the debugger can set a breakpoint at a given address, and examine/change target memory, you can implement CIO. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] msp430-elf-gcc upcoming release
> I was surprised to see DJ's comment that there actually was no > standard system interface; the "standard interface" I was referring to > is the one documented at http://neptune.billgatliff.com/newlib.html "The key to a successfully ported newlib is providing stubs that bridge the gap between the functionality newlib needs, and what your target system can provide." This bridge is what I was referring to. Newlib calls read() but does not provide an implementation of it. Libgloss provides various target-specific implementations of read(), the one I wrote for msp430 uses CIO to communicate with the simulator/debugger. > I was expecting for MSP430 to also simply implement the functions > stubbed in newlib's libnosys, but at first glance it looks like the > CIO one uses different names, and maybe doesn't support all the same > functions. Hmmm... it should be all the same names. I only changed the existing libgloss hooks. But, I don't always do all the hooks, usually only write() and exit() are needed for our testing. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] msp430-elf-gcc upcoming release
> > It uses the TI CIO interface. > > Interesting; is there any public documentation on how to use that? Not that I know of. > An option to build MSP430 newlib with the standard system interface > would be even better. I don't know of a "standard" interface. Each chip I've done has done something a little different, depending on what the architecture provided that could be hooked. > It's not clear to me why a TI-specific interface is desirable to > anybody other than TI. Part of the point of using a GNU-based > toolchain is portability across processors (even if vendors would > prefer that we be locked to their offerings). They use the CIO interface across all their processors, and it lets you debug gcc-produced executables in their IDE/simulator/hardware. As for reverse-engineering it... the sources are in libgloss and the simulator ;-) > I saw that, but it only mentioned two specific flags, compared with > the nine that are used by gcc-arm-embedded (though they're using a > forked newlib). However if nobody actually uses newlib for > applications on MSP430 yet, perhaps the community will come up with a > set of flags that work. There are far more than nine flags available, too. Users almost need to check them all and decide which features they're using in their app and which they aren't. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] msp430-elf-gcc upcoming release
> * The only headers/linker scripts available are from > GCC_RH_20131206.zip; memory.ld and peripherals.ld for each MCU need to > be manually combined to get something binutils can process Hmmm... I was under the impression that there were toplevel chip-specific scripts that included the sub-scripts. Maybe that's handled some other way in the TI IDE... > * __delay_cycles() didn't get back-ported from the version that TI > published back in December My bad. I can provide it if anyone needs it, but I'll see about adding it to the 4.9 branch. > I expect there'll be some issues with newlib as well; it appears to > use a unique syscall interface that I haven't tried to reverse > engineer. It uses the TI CIO interface. > Insight from Red Hat on a complete set of recommended flags known to > work together would be appreciated. We build with the "big" newlib, for testing. There are a bunch of flags which I mentioned in my "size optimization" email: https://www.mail-archive.com/mspgcc-users@lists.sourceforge.net/msg11977.html -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] msp430-elf size optimizations - some notes and a patch
> On a different note, i was wondering if anybody on the list have the same > problem as me, using the TI pre-compiled binaries for the MSP430 (the RH > port, downloaded from TI web site), the msp430-elf-gdb.exe , works Ok with > 430 and 430X but using only small memory model for a 430X. If you switch to > large memory and have code above 64K, it will build ok the .elf file or > .hex file (all addresses are OK), but msp430-elf-gdb.exe does not load code > or debug any address above the 64K. In fact address like 0x1 wraps > around to 0x. If you step into a function that supposed to be in high > memory, the GDB simply report as invalid address, and try to step into > 0x instead of 0x1. Anybody experienced this behavior? Cc'ing Kevin, our gdb expert... Could you come up with a small test case we can use to debug this? Perhaps including the ELF file and a sample gdb session, so we use all the same command line parameters etc? -- 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/13534_NeoTech ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] msp430-elf size optimizations - some notes and a patch
> OK, if it is /that/ much space then it's a completely different > matter. I thought we were just talking about clearing the bss and > setting the initialised data, which should just be a couple of > short simple loops. Worst case startup is around 400 bytes, but once you start optimizing, you might as well handle all the cases as best you can. > Perhaps more relevantly, what about C++ support? msp430 developers > will need some basic C++ support, including global constructors - > but can usually do without global destructors, support for unhandled > exceptions (or any exceptions or RTTI), etc., which can otherwise > take up a lot of code space. Basic C++ should be there, I think including exceptions. > And I expect Ada support is on your things-to-do list as well, in > case you get bored! Sorry, Ada isn't on my to-do list ;-) > On some systems (not gcc on the msp430), I have had to resort to > making empty stub functions for exit() and a few other library > functions in order to avoid massive library imports. Me too. -- Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] msp430-elf size optimizations - some notes and a patch
> Great news and thank you for the update, is it possible to throw > somewhere the Windows binaries? I think it is time for fresh windows > binaries, the last one was back in December. Sorry, I don't work for TI, so I can't make them do a release or say anything about their schedule or intentions. All I do is maintain the port in the FSF source tree. Also, please keep in mind that this is a patch that's still a work-in-progress, subject to change, etc. Certainly not a supported or official thing yet. > or some nice documentation on how I can build the msp-elf RH tools > myself. Note: msp430-elf, not msp-elf The answer here is "the same way you build any other cross toolchain." There's nothing magic about he msp430-elf tools, assuming you know how to build a cross toolchain at all. If not, you're probably going to be frustrated, but in case you want to try anyway... Basically (and substituate your real paths as desired): P="--prefix=/usr/local" T="--target=msp430-elf" export PATH=/usr/local/bin:$PATH cd $binutilsworkdir $somewhere/binutils-sources/configure $P $T make make install cd $gccworkdir $somewhere/gcc-sources/configure $P $T --with-newlib --enable-languages=c,c++ make all-host make install-host cd $newlibworkdir $somewhere/newlib-sources/configure $P $T make make install cd $gccworkdir make all-target make install-target -- Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] msp430-elf size optimizations - some notes and a patch
> Is it the intent to fully support C++ in this port, inclusive of > static initializers and exceptions? If you have enough flash/ram, yes. We fully test C++ in our simulators, so if gcc/newlib support it in general, it should work for msp430 also. > (Exclusive of features that require host support like threads, > though it'd be good if could be used with various MSP430 > clocks providing the underlying timers.) Well, if you want *peripheral* support in the runtime libraries, that's a different story ;-) -- Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] msp430-elf size optimizations - some notes and a patch
> Er, that reminds me, I missed some stuff in the doc about removing
> Java support... sigh.
I added this:
Lastly, there's a GCC option -minrt that tells gcc to use a "minimum
runtime" for programs that do not need static initializers or
constructors (popular in C++ and Java). Note that this is different
than initialized data (like "int j = 5;"), this is for functions that
need to be called before main() is. You can also forcibly remove the
extra language support in your linker script by discarding anything
from crtbegin/crtend:
/DISCARD/ : { *crtbegin*.o(*) *crtend*.o(*) }
Don't forget to take out the KEEP's for crtbegin/end too, though ;-)
--
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries. Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] msp430-elf size optimizations - some notes and a patch
> Even if you have the smallest mps430 with 512 bytes flash, it does > not matter if your program is 24 bytes or 511 bytes - all that > matters is that it fits in the chip you have. If the startup is more than 512 bytes, it matters a lot. If you only have 512 bytees of code space and you discover your project doesn't fit because of a couple hundred bytes of Java support, is that OK? Probably not. This is the type of thing we're trying to avoid. The GCC runtime supports *everything* GCC could do, but most project don't need everything. Er, that reminds me, I missed some stuff in the doc about removing Java support... sigh. > But if there /are/ costs - which can include lots of confusing > unnecessary symbols in map files and debugger sessions - then it is > not clear that saving a couple of bytes is worth it. There are already a lot of confusing symbols in the raw dumps, but they won't confuse the debugger or the programmer. The ones that confuse the debugger are definitions of symbols, whereas these are references to symbols. > And since most embedded programs do not return from main(), then > size optimisations based on that are worthwhile. Especially since an ISO-compliant exit() has a lot of work to do. > Ultimately, rather than having compiler flags "optimise for space" or > "optimise for speed", what we /really/ want is "give me the fastest > possible code that takes no more space than I have on the chip". Maybe > that will come in gcc 5.0 :-) Given that the compiler (which does the optimization) and the linker (which knows how big the image is) are separate projects, I doubt you'll ever see this. > Will the __intN stuff ever make it into mainline? That's the plan. It's been officially deferred until 4.10's cycle but the reviews so far have been positive. -- Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
[Mspgcc-users] msp430-elf size optimizations - some notes and a patch
I'm writing this document to collect some of the current/new knowledge
on how to minimize the flash/rom size needed for MSP430 applications,
using the new msp430-elf (FSF/Red Hat) tools. I'll keep a copy at
http://people.redhat.com/~dj/msp430/size-optimizations.html
This document has two purposes: to collect this information in one
public place, and to ask others to test it out and provide feedback.
Linker Section Optimization
__int20 Patch for Large Model
Building Newlib for Reduced Size
Obvious: Please do all size testing with -Os, which optimizes for
size, and not -O3, which optimizes for speed.
** Linker Section Optimizations
The msp430-elf assembler has a new directive ".refsym" that adds a
reference to the named symbol into the generated object. In the past,
to do this, you'd use a ".word" directive instead, but that takes up
space in the final image. This new directive takes up no space in the
image.
The startup code provided in the upstream newlib/libgloss (crt0 et al)
uses ".refsym" to tell the linker about dependencies between the
various snippets of startup code and things in the whole image which
require them. This dependency information is partly manual in crt0.S
itself, and partly automatic in code generated by gcc and gas.
For example, gcc has code to check if main() ever returns. In most
embedded programs, it won't. If it *does* return, gcc adds a ".refsym"
that causes a snippet in crt0.S to be included which adds a call to
exit() after the call to main(). If main() doesn't return, there won't
be any special code after the call to main().
The assembler has code to detect if either the data or bss sections
are used, and if they are, it will use .refsym to tell crt0 to pull in
snippets of code to initialize the RAM correctly. However, this means
that most objects will now have extra "undefined" symbols that aren't
part of your application:
U __crt0_movedata
This new functionality means that there's a new library that must be
linked in: "-lcrt". This is built by libgloss (part of newlib) by
splitting up crt0.s, and contains all the snippets. To link this
library correctly, you need a special new section in your linker
script, which looks like this:
.text :
{
. = ALIGN(2);
PROVIDE (_start = .);
KEEP (*(SORT(.crt_*)))
*(.lowtext .text .stub .text.* .gnu.linkonce.t.* .text:*)
The keep/sort line places all the snippets from crt0 at that point
(after _start but before the rest of your program) in asciibetical
order. Conveniently, the sections in libcrt.a are all named like
".crt_0013something" so the four-digit number causes them to all be
inserted in the right order.
What's the net result of all this? A simple "blink an led" program
that has no global variables can take as few as 24 bytes of flash
depending on how you blink the led!
** __int20 Patch for Large Model
The second big change is some ongoing work to add true "__intN"
support to the GCC internals. Before now, gcc had one __int128 type
built-in and any target that wanted something else had to hack it in
somehow, without support from gcc's core. I've put a huge unofficial
patch online at:
http://people.redhat.com/~dj/msp430/int20-patch.txt
This patch may not apply cleanly if the upstream sources have changed
too much since the patch was generated.
There are two parts to this patch: The first part is the core __intN
support, and the second part is changes to the msp430 backend to
enable __int20 and support it as a regular integer type. Note that
this patch mostly affects "large model" programs (-mlarge) as it
changes pointer math to use __int20 for size_t instead of "unsigned
long".
To explicitly use the __int20 type, replace "int" with "__int20" like
this:
unsigned __int20 x[10];
extern __int20 a, b, c;
void foo (__int20 a, void *b);
Note that __int20 won't work (and you'll get a helpful compile-time
error) unless you are building for an MSP430X-class cpu. You are
allowed to use an explicit __int20 type with small model, though.
** Building Newlib for Reduced Size
In some cases, applications may want to use the stock newlib runtime
but want to reduce the amount of flash newlib routines use. If you're
willing to rebuild newlib yourself, there are some config options you
can provide that remove features you may not need. For an up-to-date
list of these options, run "./configure --help" in the newlib/
subdirectory. Any --enable-foo option can be given as --disable-foo to
disable a feature. For example:
../newlib-trunk/configure --disable-newlib-io-float
There is also an alternate tiny malloc() implementation that can be
enabled:
../newlib-trunk/configure --enable-newlib-nano-malloc
Note that you can specify multiple --enable/--disable options on one
configure command.
--
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflow
Re: [Mspgcc-users] How to tell the linker to place the particular function at the specified address?
In general (i.e. untested ;) you'd add a linker script snippet like
this:
section_TAO 0xC400 : {
*(.myfuncsec_TAO)
}
Then tag your function with a section attribute:
static void __interrupt __attribute__((section(".myfuncsec_TAO")))
Timer0_A0_alter(void)
{
}
The key here is that you can change the section a function (or
anything, like data or tables) is in, and the linker knows how to put
specific sections at specific addresses.
Note that this only works if *other* output sections in the link do
not overlap. I typically avoid the examples above, and instead use
memory regions, that way I know they won't overlap or overflow.
MEMORY {
MYFUNCSEC (r) : ORIGIN = 0x0c400, LENGTH = 0x00400
}
section_TAO : {
*(.myfuncsec_TAO)
} > MYFUNCSEC
Note that you can also do per-file placement, by replacing the '*' wildcard
with the file name you want:
section_TAO {
int_a0.o(.text)
} > MYFUNCSEC
but if there are other .text things in that object that you're not
aware of, that won't guarantee that the specific handler is at the
address you want.
--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] RFC: ATTENTION ALL PORTS/PACKAGES MAINTAINERS!
> A clean distinction is that mspgcc traditionally used msp430-cmd > while msp430 gcc uniformly uses msp430-elf-cmd for all toolchain > commands. If that distinction were reflected in the package names, > it might be very simple to have parallel installations. Also, it's useful to have parallel installations as the msp430-elf "RH" toolchain is ABI compatible with the TI tools, not the mspgcc tools. -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] RedHat Toolchain for small chips
The typical case for tiny programs is that the startup/shutdown code, which normally has to be robust enough to handle all language extensions, is vastly bigger than the program itself. There are a couple of things you can manually do to trim out bits you know you don't need, like custom crt0.S (to cut out calls you don't need) or *.lnk files (to discard functions that are implicitly pulled in). We have some patches to do more of this automatically, which just haven't made it to the public releases yet. It might be worth comparing with TI's release of gcc. Also, be aware that some of the changes are in newlib and binutils, not just gcc. -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] MSP430 RedHat Toolchain: minor issues
Some quick answers where available... > and probably not MSP430 specific, with -Os "static inline > functions()" are not inlined, i also tried adding > __attribute__((always_inline)) but it did not seem to have an effect > in a quick test. Please try "extern inline functions()" instead. There was a change in the ISO standard that's been tripping up lots of software like this. > it was probably a design decision to change the ABI and start with > R12 instead of R15 for parameters. this leads to some work with > assembler modules interacting with c modules. The ABI is intended to be compatible with TI's own compiler. > positively, after working around these issues (we use custom linker > scripts anyway as we reserve space for a bootlaoder, MSP430F2xx) it > compiles and runs :-) Woot! -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] MSP430 RedHat Toolchain Generating Invalid Calls
I ran the Makefile in your zip using the latest FSF builds and it... just worked :-P Which version of gcc are you using? I.e. "msp430-elf-gcc -v" ? -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] MSP430 RedHat Toolchain Generating Invalid Calls
The _47 implies it's trying to shift by 47 bits (not registers). However, the "slll" variant is for longs (32-bit) and the helpers only go up to 15 bits (after that, it's supposed to use the variable-count helper instead). Maybe that will help you get a sharable test case, because that's what I need to debug it ;-) -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] GCC MSP430
There are three multilibs that are built: 430 - the "default" so it doesn't have a subdir - is for all non-430X processors. 430x - for 430X series processors, but still using 16-bit pointers. 430x/large - for 430X series processors using 20-bit pointers. For each of those, newlib is built using a "common subset" so it works for any (I hope) processor in that category. GCC (msp430-elf-gcc, not mspgcc) has two options it looks at: -mmcu= - if has "430x" or "430X" in it, you get the 430x family. Default is the 430 family. -mlarge - enables 20-bit pointers. IIRC there's also -mcpu= which specifies the family (430/430x) directly, for when the MCU name doesn't match the pattern. Also, keep in mind that newlib is not targetted specifically to the 430's needs. It's a generic runtime library so tends to be more "one size fits all" than "one variant per chip" like mspgcc's library. -- 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=60133471&iu=/4140/ostg.clktrk ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Unofficial Red Hat Port
> Correct me if I'm wrong here, but this only applies when the > initialisation involves a constructor function rather than just > assignment of a fixed value. Correct. > are all run before main() is called. These might add extra code space > because the constructor calls can't be fully inlined here, but it should > not be much. There is some startup code to go through the list of such functions, and call them all, too. It's not much, but if every byte counts... -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13. http://pubads.g.doubleclick.net/gampad/clk?id=64545871&iu=/4140/ostg.clktrk ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Unofficial Red Hat Port
> For small targets like this, it is common to compile C++ with "-fno-rtti True, but even the "static objects must be initialized" code adds some runtime space/time cost. It's not much, but the smallest MSP430's don't have much rom/ram to spare. -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Unofficial Red Hat Port
> Okay I'll ask... Is there FORTRAN support? No! :-) (but it might work anyway, I haven't tested) > Now on to my real question... > > how much real world testing has been done? Has the output been put > onto real msp430 chips? I'm testing against our simulator (it's in the gdb repo). I've built a few test apps, mostly blinky lights, for hardware testing, but most of the hardware testing has been to make sure the simulator is accurate. > Or are you testing against the test suites? I'm using gcc's testsuite, which is tens of thousands of tests per multilib, with three multilibs (430, 430x, 430x/large). > I handle building and supporting to some level the compilers being > used for msp430 development for TinyOS. If you've been using mspgcc for this, you probably should continue using it for now, just because it's much more mature and feature-rich. However, if you want to start testing fsf-gcc with TinyOS, I really want to hear about anything that doesn't work ;-) -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Unofficial Red Hat Port
Just FYI, the port is now "official" as it's been approved and checked in to the FSF repository! http://gcc.gnu.org/ml/gcc/2013-09/msg00107.html I have some follow-up patches that will get commited "shortly" too, though. -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Unofficial Red Hat Port
> Is c++ an officially supported aspect of the port? I'm going to conditionally say "yes" because, while I build and test C++, I know there are some language features of C I took advantage of to get far (20-bit) addressing, that C++ simply doesn't support. So I'm not sure how well C++ will work "in real programs" in all cases. Also, there's some overhead in setting up the C++ objects that might be an issue on the smallest MSP430 devices. You can work around it on a per-project basis, but it's something to keep in mind when choosing a language. I also expect there will be plenty of "in real programs" features you folks will be asking for that I'll need to add - FSF ports are not fixed in stone :-) If you ask me for FORTAN support, though, I'm more likely to say "no" :-) (or at least "you're on your own") -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] extern
Typically, you have "extern ..." in all but one source file, and just "..." in one source file where that symbol is defined. Saying "extern int foo;" means "I expect some other module to have foo." Saying "int foo;" means "I have foo." So exactly one module needs to have foo, to avoid linker errors. There's an exception in C... If you have an uninitialized variable, it tells the linker to allocate space for it (it's a "common symbol" instead of a regular symbol). IMHO this is bad practice, because it lets two modules think they "own" a variable, perhaps with two different purposes. -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] mspgcc Red Hat release
>And now, look at official ARM arm-gcc building script: it builds > gcc twice, it copy first copy of gcc somewhere, to remove later, it > wants to find some linux-specific headers in process, etc, etc, > etc. Also, it uses There are two parts to gcc: the compiler binaries, and the support runtime. The support runtime needs to know what libraries you're using. Linux-based targets are tricky because you need a working gcc to build glibc, and you need a working glibc to build gcc. For non-linux embedded, it's easier - you do "make all-host" in gcc, and it only builds the compiler. So you can do the simple binutils/gcc configure/make/install and it works, with an extra step (make all-target) or two to build the runtime libraries of choice. -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] mspgcc Red Hat release
Speaking as an FSF maintainer (sorry, can't divulge Red Hat secrets ;), to answer some of the technical questions... It's our intention that the GCC ABI be compatible with the TI ABI, at least, as best we can (If you discover an incompatibility, report it). We've been testing for cross-linking compatibility between our objects/libraries and theirs. The FSF does not package tools at all - it's up to the distro maintainers and third parties to put together packaged (and potentially supported) versions of the tools. Maintainers are responsible for keeping the sources buildable and working correctly in the "default" build, which in our case is either trunk or release branches, built with other gnu packages (gcc, binutils, gdb, newlib is our standard set). The upstream version of gcc supports 430 and 430X, including high memory. Note that the linker doesn't handle "fill two memory regions with the same type of thing" very well, so optimizing the packing of objects into both ROM spaces may require the user to customize the linker script and/or sources (yes, we provide ways to help do this :) We're not 100% compatible with mspgcc, at least as far as the msp430-specific extensions are concerned. We want to be, though. Our highest priority has been creating a port that is acceptable to upstream, once we're accepted upstream our prioririty will shift to user requests (features, bugs, optimizations, etc). The library we've been using for porting is newlib. Instructions for building the msp430 toolchain are the same as for every other gcc/binutils/newlib toolchain (even on cygwin or mingw). Other libraries should be usable, though, although they may need to be recompiled to use the new ABI, and/or to update the msp430-specific extensions. Personally, I'd rather make it "just work" but it will take time to find, test, and fix all the incompatibilities, which will partly depend on users helping. We have a few ideas for supporting chip-specific headers and linker scripts (at least, by default). I've written a short perl script to read TI's device table, so that's not the problem... the problem is there are SO MANY CHIPS! ;-) We don't think we can put TI's device table in the FSF's repo (license issues) and it's not polite (or maintainable) to check in hundreds of files, so we haven't decided what to do there. I've added some features (ok, one ;) to gas/ld to make it possible to further reduce the memory footprint by eliding "standard" gcc/elf features (like C++ constructor tables) if they're not needed. Turns out there are a lot of these, and each has their own "way", so no easy task there. Part of this can be avoided by using a custom startup that just doesn't bother with these features, but we need them in the "standard" startup in order to test the tools (what's good for our development process isn't always good for real users ;) -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
