On Sun, Oct 2, 2011 at 4:09 PM, Jasper Lievisse Adriaanse
<jas...@humppa.nl>wrote:
> On Sun, Oct 02, 2011 at 01:30:53PM -0500, Peter Bigot wrote:
> > Several problems. SP is apparently not a register name; use r1.
> msp430-gas
> > does not recognize non-decimal numbers using a suffix letter; use 0x41
> for
> > 01000001b and 41h. (All those #01000001b values are being recognized as
> > backwards jumps to a label denoted by an octal number.)
> >
> > Some of that may or may not be considered a bug. For example, if you
> think
> > msp430-gas should support radix suffixes, please file a tracker ticket.
> >
> > If you want to replace the main routine but still link with the C
> runtime
> > support, you should put it in section .init9 not in text. Use
> "msp430-gcc
> > -S foo.c" on a trivial main routine to see what directives are expected.
> >
> > Similarly, compile some sample programs that use
> attribute((interrupt(V)))
> > to see what's expected when defining an interrupt vector.
> >
> > If you don't have any need to link with the C runtime support (it is
> truly
> > an asm-only program), use msp430-as instead of msp430-gcc. It may still
> be
> > relevant which section you put things in (it will be, for vectors), but
> > without linking in crt0.a at least the remaining init/fini sections
> should
> > be empty and text will start at the beginning of flash. Look at the
> > msp430.x scripts coming from binutils to see the relevant section order.
> >
> > Peter
> Thanks, at least I've got this example working now. I can see why the
> #00001000b values are being recognized as a label, knowing it doesn't
> recognize it as a bitfield. I don't think I would consider that a bug,
> especially since gcc doesn't grok it either.
>
The main question is whether gas recognizes that on other platforms, or is
documented as recognizing it for msp430. If not, then no, it's not a bug.
Using msp430-as with the fixed source still results in a
> Error: unknown operand #WDTPW|WDTHOL
> for me, though directly using #23168 works. Why does gas decide to ignore
> this
> particular define?
>
My advice was incomplete in the case of an application that is entirely
assembly. Use msp430-gcc if you're going to be assembling from source that
requires the C preprocessor. But consider not using it to link the final
output. As an alternative, use msp430-ld and give it the parameters for the
correct interrupt vector table length and the path to the corresponding
mcu-specific linker scripts. E.g.:
msp430-ld \
/usr/local/mspgcc-dev/lib/gcc/msp430/4.6.0/crt0ivtbl16.o \
-L /usr/local/mspgcc-dev/msp430/lib/ldscripts/msp430f110 \
-o a.out \
x.o
Look at the source for
crt0.S<http://mspgcc.git.sourceforge.net/git/gitweb.cgi?p=mspgcc/gcc;a=blob;f=gcc/config/msp430/crt0.S;hb=HEAD>and
other files in that directory for some hints; e.g., you're likely to
need a definition of __reset_vector and maybe _unexpected. Or roll your own
interrupt vector in the assembler source. Avoiding msp430-gcc for the
non-relocatable link of the final application would eliminate some
unnecessary operations on startup.
Having switched back to msp430-gcc so the preprocessor is invoked (the .S
triggers "-x assembler-with-cpp", while a .s would trigger "-x assembler")
that expands to (0x5A00)|(0x0080) which still doesn't work. At a minimum,
the parentheses confuse it, and that probably could be interpreted as a bug
in the headers. I may have asked TI to put parentheses around the right
hand side of defines, because that's good practice in C where you can
otherwise end up with precedence errors (e.g., 3*X where X is #defined as
1+2). It's not necessary for single values like this, and results in syntax
not recognized by the assembler's primitive expression parser. If you file
a tracker ticket I may be able to get them to change it for the next header
release. I'm also not sure the gas expression processor handles bitwise or;
that might have to be +, if that's supported.
There hasn't been a lot of call for this sort of thing.
Thanks for taking the time to explain all this.
>
You're welcome.
Peter
>
> Cheers,
> Jasper
>
> > On Sun, Oct 2, 2011 at 1:08 PM, Jasper Lievisse Adriaanse
> > <jas...@humppa.nl>wrote:
> >
> > > Hi,
> > >
> > > Whilst trying to do some assembly-only coding I ran into an (probably
> > > PEBKAC)
> > > issue. I have this simple file called foo.S:
> > >
> > > -----8<-----
> > > #include <msp430.h>
> > >
> > >
> > >
> ;------------------------------------------------------------------------------
> > > ; Main Code
> > >
> > >
> ;------------------------------------------------------------------------------
> > >
> > > .text ; program start
> > > .global _main ; define entry point
> > >
> > > _main: mov.w #0280h,SP ; initialize stack pointer
> > > mov.w #WDTPW|WDTHOLD,&WDTCTL ; stop watchdog timer
> > >
> > > bis.b #01000001b,&P1DIR ; make P1.0 and P1.6 output
> > > ; all others are inputs by
> > > default
> > >
> > > Mainloop: bit.b #00001000b,&P1IN ; read switch at P1.3
> > > jc Off ; if P1.3 open branch to Off
> > > label
> > >
> > > On: bic.b #00000001b,&P1OUT ; clear P1.0 (red off)
> > > bis.b #01000000b,&P1OUT ; set P1.6 (green on)
> > > jmp Wait ; branch to a delay routine
> > >
> > > Off: bis.b #00000001b,&P1OUT ; set P1.0 (red on)
> > > bic.b #01000000b,&P1OUT ; clear P1.6 (green off)
> > >
> > > Wait: mov.w #1834,R15 ; load R15 with value for
> > > delay
> > > L1: dec.w R15 ; decrement R15
> > > jnz L1 ; if R15 is not zero jump to
> L1
> > > jmp Mainloop ; jump to the Mainloop label
> > >
> > >
> > >
> ;------------------------------------------------------------------------------
> > > ; Interrupt Vectors
> > >
> > >
> ;------------------------------------------------------------------------------
> > > .sect ".reset" ; MSP430 RESET Vector
> > > .short _main
> > >
> > > .end
> > > -----8<-----
> > >
> > > Afaics this code is correct, though gcc disagrees:
> > > $ msp430-gcc -g -Os -mmcu=msp430g2213 cstack.S -o cstack.o
> > > cstack.S: Assembler messages:
> > > cstack.S:13: Error: backward ref to unknown label "262145:"
> > > cstack.S:16: Error: backward ref to unknown label "512:"
> > > cstack.S:19: Error: backward ref to unknown label "1:"
> > > cstack.S:20: Error: backward ref to unknown label "262144:"
> > > cstack.S:23: Error: backward ref to unknown label "1:"
> > > cstack.S:24: Error: backward ref to unknown label "262144:"
> > > $
> > >
> > > Anyone with a cluebat?
> > >
> > > Also, is the explicit stack pointer initialization needed with gcc or
> will
> > > it
> > > do this automagically?
> > >
> > > --
> > > Cheers,
> > > Jasper
> > >
> > > "Capable, generous men do not create victims, they nurture them."
> > >
> > >
> > >
> ------------------------------------------------------------------------------
> > > All of the data generated in your IT infrastructure is seriously
> valuable.
> > > Why? It contains a definitive record of 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-d2dcopy2
> > > _______________________________________________
> > > Mspgcc-users mailing list
> > > Mspgcc-users@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/mspgcc-users
> > >
>
> --
> Cheers,
> Jasper
>
> "Capable, generous men do not create victims, they nurture them."
>
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of 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-d2dcopy2
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
