Am 06.12.2002 21:16:43, schrieb "David Brown" :
>Also, is there any way to optomise tail calls (if that is the right word) ?
>I am thinking of a function that ends with a call to another function, where
>the "call #...; ret" pair is replaced with a "jmp ..." instruction.
not sure but does __attrib
Am 06.12.2002 22:52:57, schrieb Mark Stokes :
> that I didn't find the #define problem I was having anywhere in the Docs. I
> had printed and read multiple times the pages that Chris suggested long
> before I wrote the original inquiry.
i have not seen that mentioned explicitly neither, but t
Times:
Using C : 0x102 bytes (256 dec)
Some execution times:
Value Time (uS)
12345678456.0
034 248.0
12300678456.0
0204.0
Using naked Asm : 0x6A bytes (106 dec)
Value Digit Time (uS)
12345678 8256.0
0343
Hi Dmitry,
I hope this is of interest to you. I know I have the source, and could
fiddle things myself, but this is way beyond my knowledge.
I've been playing about with bitfields, and looking at the code generated by
gcc for various manipulations. Normally I tend to use chars to hold flag
regi
Steve,
I've just begun to use gcc with the FET msp430f149, thanks to your fine
work on rproxy. I had been limping along with the freebie IAR toolset
in hopes that somoe would get gdb/FET working, and thankfully that has
happened. Finally, I can go back to Linux land and to do my development
> the Registers directly. As for the loading of the variables directly
> using the parameter passing into assembly, I'll probably have to do that
> for this particular variable.
This is not really _optimal_ if you do not know where the particular variable
located. For example, if you think, that
Thanks for the detailed reply. The reason for the assembly is to get
rid of the C overhead for certain routines. This is why I'm accessing
the Registers directly. As for the loading of the variables directly
using the parameter passing into assembly, I'll probably have to do that
for this partic
this has been fixed a while ago...
You have to get new sources from CVS and recompile gcc.
~d
On Friday 06 December 2002 17:46, HiD wrote:
> Hi,
> when I compiled the attached file with msp430-gcc version 3.2 I got the
> following error messages:
>
Hi,
when I compiled the attached file with msp430-gcc version 3.2 I got the
following error messages:
--
msp430-gcc.exe -c CircularBuffer.c -o CircularBuffer.o
-I"C:/Dev-Cpp/include" -mmcu=msp430x149
CircularBuffer.c: In function `CB
Hi,
when I compiled the attached file with msp430-gcc version 3.2 I got the
following error messages:
--
msp430-gcc.exe -c CircularBuffer.c -o CircularBuffer.o
-I"C:/Dev-Cpp/include" -mmcu=msp430x149
CircularBuffer.c: In function `
I've finally got the card I needed for testing, so now I have gdb working
fine for the msp430 using the FET. It all works nicely - I can program it
using pyjtag (which I normally do as part of my "make"), and I can debug it
using gdb. Insight seems to get confused if I have "target remote
localho
you're right,
the same on me,
but if someone like borlands and such, why not? :)
~d
On Friday 06 December 2002 15:21, David Brown wrote:
> Are you thinking of this as a way to embedded assembly clearer? I am not a
> great fan of using macro pairs that open or close scopes - I've made them
> and
Are you thinking of this as a way to embedded assembly clearer? I am not a
great fan of using macro pairs that open or close scopes - I've made them
and used them myself before, and got confused by them. They can really mess
up bug-hunting when gcc reports a nesting error somewhere totally differ
#define ASMSTART__asm__ __volatile__ (
#define ASMEND );
#define _(x...) #x"\n\t"
int foo()
{
int aa;
ASMSTART
_( mov r1, r12 )
_( clr %0 )
: "=r" (aa)
ASMEND
return aa;
}
--
/**
there is.
look at ld.info node:scripts.
this is a good start.
~d
On Friday 06 December 2002 11:44, David Brown wrote:
> When making that last post, I had to look at the standard linker files.
> There are a great many of these files for each processor, all with slight
> variations. Is there any d
When making that last post, I had to look at the standard linker files.
There are a great many of these files for each processor, all with slight
variations. Is there any documentation giving an overview of what they are,
and which is used by the linker?
mvh.
David
If you have a function that should always be run from ram, then it should be
possible to have it copied to ram on startup. I haven't tried this on the
msp430, but I have used it on a 68332, compiled with gcc. The idea is to
specify a special section for the function, and use linker magic to get i
17 matches
Mail list logo
