I've been using mspgcc for a few months now for development using a 4618 chip. In addition, we may be switching to the 2618 chip.
I just recently joined this mail list, as I'm wondering about extended instruction support for these chips. I've tried looking at the archives on SF.net, but the search keeps timing out. Could someone update me on the current progress?
I'm also interested in helping further development on this project. I've been programming C / C++ for many years, but I have very little formal training.I'm more of the 'self-learning' type. I have no knowledge of compiler programming or anything similar, but would like to learn. As a step, if there is anything I can do to help program/test any new developments I'd love to spend some time trying if someone can provide a bit of mentoring.
My setup is as follows: mspgcc on Linux (FC 2), gdbproxy on Windows XP connected to a TI USB FET. I use DDD (gdb) to connect to the proxy and load/debug my files.
tonyb dot mailsend at gmail
On Fri, Mar 7, 2008 at 8:13 PM, TonyB <tonyb.mailsend@...> wrote:
> I just recently joined this mail list, as I'm wondering about extended
> instruction support for these chips. I've tried looking at the archives on
> SF.net, but the search keeps timing out. Could someone update me on the
> current progress
I don't know specifically about the extended support for x618 but unless the
extended instructions are measurably improving general code generation for
non-x618 specific code, the compiler shouldn't know about them. Instead,
they should be used from asm() constructs (
http://www.ibiblio.org/gferg/ldp/GCC-Inline-Assembly-HOWTO.html ). You can
wrap the asm() snippets into #defines and function calls so that they look
almost invisible, as if they were emitted by the code generator. GCC has a
very nice facility for asm(), where the compiler generates and even
optimizes data movements to register and memory locations required by the
asm() instructions, without knowing their semantics.