Re: Invalid Operands with Inline assembly

Re: Invalid Operands with Inline assembly

[Robert Floyd]

Hi Stan,

I used your example and everything compiles and links just great.  With
one slight problem that you might be aware of with your Hitachi SH
experience...

I have asm files that initialize the chip, turns on an LED to RED and
sends out a boot string over the serial port to my PC.  These actually
work.  I used the example that you set up for me as a C file with inline
assembly that I wanted to link into my working assembly language files. 
Well after the chip runs thru all the asm code (which I can see is
working ok because the LED comes on and the boot string comes out over
the serial port), I simply... 

bra pmain	! branch to global _main in another object file

This pmain is a label in the asm file, i.e. pmain:   .long _main

But instead the chip seems to branch off into the weeds because after
several seconds the chip resets, (watchdog timeout?).  I actually went
thru the code, looked at the srec file and can see that the linker did
put in the right address for _main.  But oddly enough, nothing happens
except it eventually resets itself.  Do you think that I should be
branching to the dummy global ___main instead?  Thanks for any advice on
this.

Robert F.


Stan Katz wrote:
> 
> Robert Floyd [ mailto:robert.floyd@inet.com]wrote:
> > Stan,
> >
> > Well, I want to say thanks for bearing with me on this...I guess I am
> > going to have to show my ignorance now...
> >
> > Your example is confusing to me because you are not assigning your
> > pointers with anything.  Either it is obviously elementary and so you
> > left out the assignments or else there is some magic going on
> > here that
> > I am unaware by simply putting in unassigned pointers. Maybe you can
> > enlighten me on this...thanks so much.
> >
> 
> Robert, I apologise, the problem was mine. In the snippet the variable
> declarations should have been :
> 
>    register long pointer = TxChar;
>    register long *string = pHelloStr;
> 
> which is where the assignment of the values to the registers
> is handled by the compiler.
> 
> Stan

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

RE: Invalid Operands with Inline assembly

[Stan Katz]

Robert Floyd [ mailto:robert.floyd@inet.com ] wrote:
>
> I used your example and everything compiles and links just 
> great.  With
> one slight problem that you might be aware of with your Hitachi SH
> experience...
> 
snip

Thanks for the feedback, glad to have helped

> I have asm files that initialize the chip, turns on an LED to RED and
> sends out a boot string over the serial port to my PC.  These actually
> work.  I used the example that you set up for me as a C file 
> with inline
> assembly that I wanted to link into my working assembly 
> language files. 

I tend to do all this is C anyway, the only time I use assembly is when I
need to either put in some interrupt handling code (which usually calls a C
routine for processing anyway) or when I want to use the mul/mac/div
instructions to get a faster scaling routine.

> Well after the chip runs thru all the asm code (which I can see is
> working ok because the LED comes on and the boot string comes out over
> the serial port), I simply... 
> 
> bra pmain	! branch to global _main in another object file
> 
> This pmain is a label in the asm file, i.e. pmain:   .long _main
> 
> But instead the chip seems to branch off into the weeds because after
> several seconds the chip resets, (watchdog timeout?).  I actually went
> thru the code, looked at the srec file and can see that the linker did
> put in the right address for _main.  But oddly enough, nothing happens
> except it eventually resets itself.  Do you think that I should be
> branching to the dummy global ___main instead?  Thanks for 
> any advice on
> this.

It looks as if you are branching to the address pmain, which contains a 32
bit value equivalent to _main and is executing that as code, what happens
depends on the actual value of _main but is not likely to get you back with
the PC equal to _main either. You want to branch to the value that is at the
address pmain (assuming _main is too far away to go directly there) probably
want to do something like:
	mov.l  pmain, r4
	bra    @r4

Although you may be able to use 
	bra _main

Try the second and if the address of _main is too far from the bra
instruction to be assembled you will get an error message from the compiler
or assembler.

Stan

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: Invalid Operands with Inline assembly

[Sobhy Gad]

Hi everyone,

I'm despertly trying to build gcc-win32 for the target of MIPS-16.
what ever I do, it does not work.

I just need "objcopy", "objdumb" and "as" for MIPS-16.
I mean I need asm/disass for the MIPS-16.

Please Help.

best regards
S. Gad


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: Invalid Operands with Inline assembly

[Robert Floyd]

> It looks as if you are branching to the address pmain, which contains a 32
> bit value equivalent to _main and is executing that as code, what happens
> depends on the actual value of _main but is not likely to get you back with
> the PC equal to _main either. You want to branch to the value that is at the
> address pmain (assuming _main is too far away to go directly there) probably
> want to do something like:
>         mov.l  pmain, r4
>         bra    @r4

Since _main is a global function defined in another file, I do notice
that it does link up the right address.  I checked the srec again and
can see it is correct.  It's just odd how it does not ever seem to get
there to the compiled 'C' portion when I burn a prom for the SH1.

I tried your example above but I get the error 'bad expression' when
using 'bra @r4'. The expression:

jmp @r4 

does compile ok, however.  I'll give it go again when I get to my prom
burner.  Thanks for your help.

Robert

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

RE: Invalid Operands with Inline assembly

[Stan Katz]

Robert Floyd [ mailto:robert.floyd@inet.com ] wrote :
>> snip
> Why would not the following work just as well...
> 
> extern long TxStr;		  /* defined as .globl TxStr in external asm
file */
> 
> int main()
> {
>    char pHelloStr[6] = "Hello";
>    
>    while(1)
>    {
> 
>       asm( 
>           " mov  %0, r4;"          /* Move global asm label TxStr to r4 */
>           " mov  %1, r0;"          /* And string to r0 */
>           " jsr  @r4;"             /* And jump via r4 */
>           :                        /* no outputs */
>           : "r" (TxStr),           /* %0 is Input 0, a register, use TxStr
*/
>             "r" (pHelloStr)        /* %1 is Input 1, a register, use
pHelloStr */
>           : "r0", "r4"             /* and uses r0 and r4 as scratch */
>           );
>    }
>    
>    return(0);
> }
> 
> int __main() {}                     /* I was told I need this for gcc,
> don't know why */
> 

The reason I added the pointers is to make sure that the data is already in
a register because TxStr is actually a long value and pHelloStr is a pointer
to a constant string which is probably in the same segment as the code but
may not be within the range of the offset from the PC addressing mode. These
are definitely not registers. The "r" specifiers for the inputs to the asm
block specify the parameters as registers so I need to make sure that the
data is available in a register and the pointers leave it up the compiler to
get the data where it is needed.

GNU allows other (or multiple) specifiers for the asm block. The ones that I
have used are "i" for an input which specifies immediate data (for the SH2
this is limited to signed 8 bits which is sign extended) and "0" to "9"
where I use the same register for input and output. From the manual "m"
(address), "o" (offsettable address) and some other are allowed but when I
tried to use them I found that I was having trouble specifying the address
mode, it ended up easier for me to use the "r" specification and let the
compiler assign the value to a local (block scope) register variable.

BTW, __main() is called by GCC as part of the C++ initialization before
calling main(), if you don't supply one it will grab it from the library (if
it is linked) or complain.

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

RE: Invalid Operands with Inline assembly

[Stan Katz]

Robert Floyd [ mailto:robert.floyd@inet.com ] Wrote:
>>Snip
> I have a particular assembly source file that
> contains everything I need to use the serial port on the 
> Hitachi part. 
> For example, it contains one piece of code that allows one to send a
> string out the serial port.  So in another assembly file if I want to
> send out "Hello World", I do the following:
> 
> DoHelloWorld:
> 	mov.l	pTxString,r4		! address loaded for 
> global TxStr function
> 	mova	pHelloStr,r0		! get 'Hello World' 
> string and put in r0
> 	jsr	@r4			! jump to address in r4 
> (global TxStr)
> 
> ---and at the bottom of my file I have----
> 
> pTxString:	.long	TxStr		    ! TxStr is a global 
> function in another asm
> file 
> pHelloStr:	.asciz	"\n\rHello World "   ! my ascii string
> 
> 
> Since I really want to write my code in C but I also don't want to
> recreate the wheel, since there is alot of assembly language 
> functions I
> could use, how could I write this DoHelloWorld function in C.  
>> Snip

This is a case where the parameters for the asm function can help, I would
try something like the following (based on the code that you sent and I
snipped)

extern long TxChar;

int main()
{
   char pHelloStr[6] = "Hello";
   
   while(1)
   {
   register long *pointer;
   register long *string;

      asm( 
          " mov  %0, r4;"         /* Move function pointer to r4 */
          " mov  %1, r0;"          /* And string pointer to r0 */
          " jsr  @r4;"             /* And jump via r4 */
          :                        /* no outputs */
          : "r" (pointer),         /* %0 is Input 0, a register, use C
variable pointer */
            "r" (string),          /* %1 is Input 1, a register, use C
variable string */
          : "r0", "r4"             /* and uses r0 and r4 as scratch */
          );
   }
   
   return(0);
}

This lets the C compiler handle the assignment of the addresses to the
registers which are passed as parameters to the asm function. Since the
compiler seems to concatenate all the asm strings into one long string, I
use a single asm statement and let it concatenate the strings before
processing the asm.
The last 3 lines of the asm routine define the Output parameters, Input
Parameters and Registers affected by the asm routine. For more details on
this look at the "Using GNU GCC" manual, Chapter 3 - "Extensions to the C
language Family", section 3.30. 

I have not tried to get very fancy with the parameter specifications, and
usually just use register variables that are assigned in a surrounding
block.

BTW, you could probably eliminate the " mov %0,r4;" and simply do " jsr
@%0;".

Stan

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: Invalid Operands with Inline assembly

[Robert Floyd]

Stan,

Why would not the following work just as well...

extern long TxStr;		  /* defined as .globl TxStr in external asm file */

int main()
{
   char pHelloStr[6] = "Hello";
   
   while(1)
   {

      asm( 
          " mov  %0, r4;"          /* Move global asm label TxStr to r4
*/
          " mov  %1, r0;"          /* And string to r0 */
          " jsr  @r4;"             /* And jump via r4 */
          :                        /* no outputs */
          : "r" (TxStr),           /* %0 is Input 0, a register, use
TxStr */
            "r" (pHelloStr)        /* %1 is Input 1, a register, use
pHelloStr */
          : "r0", "r4"             /* and uses r0 and r4 as scratch */
          );
   }
   
   return(0);
}

int __main() {}                     /* I was told I need this for gcc,
don't know why */


I do not see why the pointers are needed since TxStr already is defined
in the asm file as .globl TxStr. The linker should apply the right
address here.  And the string pHelloStr is basically the address for the
string "Hello" above so could be directly loaded into the register.  It
does compile and link fine.  I tried it but it did not work since I
think I am branching to the wrong 'main'.  I looked at the assembly
listing and ___main is defined as the global instead of the 'main' at
the top of my program. So I guess I need to branch to ___main.

I would like to know why you added in the pointers in your example. 
Thanks.

Robert F.




Stan Katz wrote:
> 
> Robert Floyd [ mailto:robert.floyd@inet.com ] Wrote:
> >>Snip
> > I have a particular assembly source file that
> > contains everything I need to use the serial port on the
> > Hitachi part.
> > For example, it contains one piece of code that allows one to send a
> > string out the serial port.  So in another assembly file if I want to
> > send out "Hello World", I do the following:
> >
> > DoHelloWorld:
> >       mov.l   pTxString,r4            ! address loaded for
> > global TxStr function
> >       mova    pHelloStr,r0            ! get 'Hello World'
> > string and put in r0
> >       jsr     @r4                     ! jump to address in r4
> > (global TxStr)
> >
> > ---and at the bottom of my file I have----
> >
> > pTxString:    .long   TxStr               ! TxStr is a global
> > function in another asm
> > file
> > pHelloStr:    .asciz  "\n\rHello World "   ! my ascii string
> >
> >
> > Since I really want to write my code in C but I also don't want to
> > recreate the wheel, since there is alot of assembly language
> > functions I
> > could use, how could I write this DoHelloWorld function in C.
> >> Snip
> 
> This is a case where the parameters for the asm function can help, I would
> try something like the following (based on the code that you sent and I
> snipped)
> 
> extern long TxChar;
> 
> int main()
> {
>    char pHelloStr[6] = "Hello";
> 
>    while(1)
>    {
>    register long *pointer;
>    register long *string;
> 
>       asm(
>           " mov  %0, r4;"         /* Move function pointer to r4 */
>           " mov  %1, r0;"          /* And string pointer to r0 */
>           " jsr  @r4;"             /* And jump via r4 */
>           :                        /* no outputs */
>           : "r" (pointer),         /* %0 is Input 0, a register, use C
> variable pointer */
>             "r" (string),          /* %1 is Input 1, a register, use C
> variable string */
>           : "r0", "r4"             /* and uses r0 and r4 as scratch */
>           );
>    }
> 
>    return(0);
> }
> 
> This lets the C compiler handle the assignment of the addresses to the
> registers which are passed as parameters to the asm function. Since the
> compiler seems to concatenate all the asm strings into one long string, I
> use a single asm statement and let it concatenate the strings before
> processing the asm.
> The last 3 lines of the asm routine define the Output parameters, Input
> Parameters and Registers affected by the asm routine. For more details on
> this look at the "Using GNU GCC" manual, Chapter 3 - "Extensions to the C
> language Family", section 3.30.
> 
> I have not tried to get very fancy with the parameter specifications, and
> usually just use register variables that are assigned in a surrounding
> block.
> 
> BTW, you could probably eliminate the " mov %0,r4;" and simply do " jsr
> @%0;".
> 
> Stan

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: Invalid Operands with Inline assembly

[Robert Floyd]

Stan,
Thanks so much.  You are completely correct and my examples are
compiling fine now.

Forgive me for asking but quite possibly you can explain something to
me.  For my SH7032, I have a particular assembly source file that
contains everything I need to use the serial port on the Hitachi part. 
For example, it contains one piece of code that allows one to send a
string out the serial port.  So in another assembly file if I want to
send out "Hello World", I do the following:

DoHelloWorld:
	mov.l	pTxString,r4		! address loaded for global TxStr function
	mova	pHelloStr,r0		! get 'Hello World' string and put in r0
	jsr	@r4			! jump to address in r4 (global TxStr)

---and at the bottom of my file I have----

pTxString:	.long	TxStr		    ! TxStr is a global function in another asm
file 
pHelloStr:	.asciz	"\n\rHello World "   ! my ascii string


Since I really want to write my code in C but I also don't want to
recreate the wheel, since there is alot of assembly language functions I
could use, how could I write this DoHelloWorld function in C.  I tried
the following:

extern long TxChar;

int main()
{
   char pHelloStr[6] = "Hello";
   
   while(1)
   {
      asm( "mov.l TxStr, r4;");
      asm( "mova pHelloStr, r0;");
      asm( "jsr  @r4;");
   }
   
   return(0);
}

All I get is the following message:  
Assembler messages:
/var/tmp/ccSJdkkV.s:54: Error: pcrel too far
/var/tmp/ccSJdkkV.s:55: Error: pcrel too far

I searched the entire SH7032 Hardware manual and Programming Manual and
did not find any reference to pcrel.  Could you tell me what it is and
maybe another way that I could call a function that is written in
assembly that is in another file?  Thanks for any help on this.

Robert


Stan Katz wrote:
> 
> Robert Floyd wrote
> 
> >> I am attempting to embed inline assembly into my C code but during the
> >> compilation, I keep getting the error "invalid operands for opcode".
> >> Here is one of my lines:
> >>
> >> asm("mov %r14, %r15");
> >>
> >> I don't see why this should cause an error.  mov is a valid Hitachi SH
> >> opcode, r14 and r15 are valid registers.
> 
> I have been using inline assembly on the SH for a while now without any
> problems. From my understanding the "%" is used to specify replacable
> parameters for the inline assembly and is the cause of the confusion. To
> simply move between registers the line is
>         asm("mov r14, r15;");
> 
> A common problem that I have is that the compiler seems to concatenate all
> sequential asm commands into a single long string and then complains because
> there is no separation between assembly mnemonics. I have mad a practice of
> adding a terminating ";" to all my commands to prevent this (as in the above
> example).
> 
> I have not needed any additional command line parameters to get the code
> working.
> 
> Stan

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

RE: Invalid Operands with Inline assembly

[David Korn]

>I am attempting to embed inline assembly into my C code but during the
>compilation, I keep getting the error "invalid operands for opcode". 
>Here is one of my lines:
>
>asm("mov %r14, %r15");

  I've found (on PPC; it might apply to SH also) that you can't put a
space between the two operands. gas expects the entire operand list to
be in one field, the space acts as a separator, and it parses what you've
typed as

    mov %r14,

followed by a comment field that contains the text "%r15". So try again
without the space. What that other guy said about %-signs might matter too.

    DaveK
-- 
SEAL Team 6 World Trade Center Serbian Cocaine [Hello to all my fans
in domestic surveillance] cracking KGB nuclear arrangements CIA
counter-intelligence smuggle fissionable ammunition SDI

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Invalid Operands with Inline assembly

[Robert Floyd]

I am attempting to embed inline assembly into my C code but during the
compilation, I keep getting the error "invalid operands for opcode". 
Here is one of my lines:

asm("mov %r14, %r15");

I don't see why this should cause an error.  mov is a valid Hitachi SH
opcode, r14 and r15 are valid registers, the quotations are necessary as
well as the % before each register.  I don't see what else I am
missing.  I am using my Hitachi cross-compiler I built which has been
working like a champion except when I use inline assembly.  Is there
some parameter I need to add on the Command Line before I compile my
file?

Thanks for any help.

Robert F.

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: Invalid Operands with Inline assembly

[Keith Wright]

> From: Robert Floyd <robert.floyd@inet.com>
> 
> I am attempting to embed inline assembly into my C code but during the
> compilation, I keep getting the error "invalid operands for opcode". 
> Here is one of my lines:
> 
> asm("mov %r14, %r15");
> 
> I don't see why this should cause an error.  mov is a valid Hitachi SH
> opcode, r14 and r15 are valid registers, the quotations are necessary as
> well as the % before each register.

Gcc uses a % to mark an argument that must be substituted
by the compiler with some C expression.  Thus you need two %%'s
to get one through the compiler and into the assembler.

Here is a chunk of embeded Motorola Coldfire code.  It's written
in CWEB, so ignore @ signs and the following character.

Warning: I don't know squat about the Hitachi SH.

@ The |trap_to_system| is the heart of the linkage between a user
program and \coldboot/.  It takes two parameters.
The first is a count of the number of arguments (actually the number
of quad words occupied by the argument list, but this should be
the same thing in most cases).  The macro will produce a trap whose
number is the same as the argument count.
The second parameter is a unique number that identifies the system call.  
To keep things consistent, new system call numbers should be created
by adding to the |enum| types in |@<declare system call numbers@>|.
There are four sets of numbers, one for each trap number.

The macro expects to be used in an environment in which the variables
|res| and |arglist| are defined.  The variable |arglist| should be
set up before invoking the macro to be a pointer to the first argument
of the system call wrapper procedure.  The variable |res| will contain
the result of the system call, which is always an integer.

That explanation, and the examples already done, should be enough
to use the macro, if you should ever need to.  To understand it,
first read [6] \S 4.31, on using in-line assembly language in \.{gcc}
and [3] \S 3.3.8 for an description of the sharp sign in \CEE/ macro
definitions.
@<macro definitions shared with \.{romcalls.c}@>=
#define trap_to_system(argc,calln)@/\
  @[asm volatile(@/\
    " move.l %1,%%d0; move.l %2,%%d1; trap #" #argc "; move.l %%d0,%0"@/\
    : "=g" (res)@/\
    : "g" (calln), "g" (arglist)@/\
    : "%d0", "%d1")@];

\item{[3]} Samuel P.~Harbison and Guy L.~Steele~Jr., {\it \CEE/ A Reference
Manual} (Fourth Edition), Prentice Hall (1995)

\item{[6]} Richard M.~Stallman, {\it Using and Porting GNU CC},
Free Software Foundation (1996)

-- 
     -- Keith Wright  <kwright@free-comp-shop.com>

Programmer in Chief, Free Computer Shop < http://www.free-comp-shop.com >
         ---  Food, Shelter, Source code.  ---

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com