Re: Strange instruction

Re: Strange instruction

[Kevin D. Kissell]

That's a 64-bit add, which is actually being used as a 64-bit move
of the "sp" register to k1.  Try "objdump -m mips:isa64" (or whatever
variant gives your version of objdump the right to disassemble the
MIPS III+/MIPS64 instructions.

One might suspect that your board monitor ROM was built for a 64-bit CPU.
This illustrates why, if one want to write portable assembler code for MIPS,
one should implement "move" operations as OR Target,$0,Source rather than
using an ADDU or DADDU...

----- Original Message ----- 
From: "Dmitriy Tochansky" <toch@dfpost.ru>
To: <linux-mips@linux-mips.org>
Sent: Thursday, October 14, 2004 13:53
Subject: Strange instruction


> Hello!
> 
> When starts kernel for my au1500 board reseting board. After disassembling I found instruction
> which reseting board. Here is few strings of "mipsel-linux-objdump -D vmlinux" output:
> 
> ---
> 
> a0000650:       07400003        bltz    k0,a0000660 <nmi_handler+0x1c>          
> a0000654:       03a0d82d        0x3a0d82d                                       
> a0000658:       3c1ba020        lui     k1,0xa020 
> 
> ---
> 
> Base address changed by me.
> 
> What is A0000654? There is board resets.
> 
> 

Re: Strange instruction

[Kevin D. Kissell]

That's a 64-bit add, which is actually being used as a 64-bit move
of the "sp" register to k1.  Try "objdump -m mips:isa64" (or whatever
variant gives your version of objdump the right to disassemble the
MIPS III+/MIPS64 instructions.

One might suspect that your board monitor ROM was built for a 64-bit CPU.
This illustrates why, if one want to write portable assembler code for MIPS,
one should implement "move" operations as OR Target,$0,Source rather than
using an ADDU or DADDU...

----- Original Message ----- 
From: "Dmitriy Tochansky" <toch@dfpost.ru>
To: <linux-mips@linux-mips.org>
Sent: Thursday, October 14, 2004 13:53
Subject: Strange instruction


> Hello!
> 
> When starts kernel for my au1500 board reseting board. After disassembling I found instruction
> which reseting board. Here is few strings of "mipsel-linux-objdump -D vmlinux" output:
> 
> ---
> 
> a0000650:       07400003        bltz    k0,a0000660 <nmi_handler+0x1c>          
> a0000654:       03a0d82d        0x3a0d82d                                       
> a0000658:       3c1ba020        lui     k1,0xa020 
> 
> ---
> 
> Base address changed by me.
> 
> What is A0000654? There is board resets.
> 
> 

Re: Strange instruction

[Fuxin Zhang]

objdump -d -mmips:4000 vmlinux to force it regconize all MIPS III 
instructions

I think this option should be renamed( i had try -mips3 -mmips3 etc. 
before i find it
by reading the source code)
 or the default should be changed.

Dmitriy Tochansky wrote:

>Hello!
>
>When starts kernel for my au1500 board reseting board. After disassembling I found instruction
>which reseting board. Here is few strings of "mipsel-linux-objdump -D vmlinux" output:
>
>---
>
>a0000650:       07400003        bltz    k0,a0000660 <nmi_handler+0x1c>          
>a0000654:       03a0d82d        0x3a0d82d                                       
>a0000658:       3c1ba020        lui     k1,0xa020 
>
>---
>
>Base address changed by me.
>
>What is A0000654? There is board resets.
>
>
>
>  
>

Re: Strange instruction

[Kevin D. Kissell]

Sorry about that disinformation.  The man page doesn't provide
the necessary details - but running "objdump -H" does (and the
-H help option *is* called out in the man page).

----- Original Message ----- 
From: "Fuxin Zhang" <fxzhang@ict.ac.cn>
To: "Kevin D. Kissell" <kevink@mips.com>
Sent: Thursday, October 14, 2004 12:56
Subject: Re: Strange instruction


> 
> 
> Kevin D. Kissell wrote:
> 
> >In all fairness, the syntax is in he "man" page for objdump, so 
> >  
> >
> The man page does mention the option -m
> 
>       -m machine
>       --architecture=machine
>            Specify the architecture to use when  disassembling  object  
> files.
>            This  can  be  useful  when disassembling object files which 
> do not
>            describe architecture information, such as S-records.  You 
> can list
>            the available architectures with the -i option.
>      but it does not mention how to specify a machine, although I did 
> find it in
> objdump --help later:)
> 
> debian GNU objdump 2.14.90.0.7 20031029
> 
> >one doesn't really have to read the sources to figure it out!
> >But the question of whether the default mode of objdump 
> >should be the minimum 32-bit legacy instruction set is a good 
> >one.  Not  many currenly used MIPS processors are MIPS I.  
> >I understand that disassembling advanced instructions that are 
> >not supported by a particular CPU as if they were normal can 
> >cause confusion and error, but perhaps the default would be to 
> >disassmble everything as MIPS64 rev 2, but with all instructions 
> >that are not in MIPS I flagged somehow, perhaps with a message
> >after the assembly code to indicate the extended ISA level?  e.g.
> >
> >a0000650:       07400003        bltz    k0,a0000660 <nmi_handler+0x1c>          
> >a0000654:       03a0d82d        move k1,sp *mips3*
> >a0000658:       3c1ba020        lui     k1,0xa020 
> >
> >Where specifying -m mips:isa64 or -m mips:4000 would suppress the warnings
> >on MIPS64 or MIPS III instructions respectively. Just a thought...
> >
> >----- Original Message ----- 
> >From: "Fuxin Zhang" <fxzhang@ict.ac.cn>
> >To: "Dmitriy Tochansky" <toch@dfpost.ru>
> >Cc: <linux-mips@linux-mips.org>
> >Sent: Thursday, October 14, 2004 10:45
> >Subject: Re: Strange instruction
> >
> >
> >  
> >
> >>objdump -d -mmips:4000 vmlinux to force it regconize all MIPS III 
> >>instructions
> >>
> >>I think this option should be renamed( i had try -mips3 -mmips3 etc. 
> >>before i find it
> >>by reading the source code)
> >> or the default should be changed.
> >>
> >>Dmitriy Tochansky wrote:
> >>
> >>    
> >>
> >>>Hello!
> >>>
> >>>When starts kernel for my au1500 board reseting board. After disassembling I found instruction
> >>>which reseting board. Here is few strings of "mipsel-linux-objdump -D vmlinux" output:
> >>>
> >>>---
> >>>
> >>>a0000650:       07400003        bltz    k0,a0000660 <nmi_handler+0x1c>          
> >>>a0000654:       03a0d82d        0x3a0d82d                                       
> >>>a0000658:       3c1ba020        lui     k1,0xa020 
> >>>
> >>>---
> >>>
> >>>Base address changed by me.
> >>>
> >>>What is A0000654? There is board resets.
> >>>      
> >>>
> >
> >
> >  
> >
> 

Re: Strange instruction

[Kevin D. Kissell]

Sorry about that disinformation.  The man page doesn't provide
the necessary details - but running "objdump -H" does (and the
-H help option *is* called out in the man page).

----- Original Message ----- 
From: "Fuxin Zhang" <fxzhang@ict.ac.cn>
To: "Kevin D. Kissell" <kevink@mips.com>
Sent: Thursday, October 14, 2004 12:56
Subject: Re: Strange instruction


> 
> 
> Kevin D. Kissell wrote:
> 
> >In all fairness, the syntax is in he "man" page for objdump, so 
> >  
> >
> The man page does mention the option -m
> 
>       -m machine
>       --architecture=machine
>            Specify the architecture to use when  disassembling  object  
> files.
>            This  can  be  useful  when disassembling object files which 
> do not
>            describe architecture information, such as S-records.  You 
> can list
>            the available architectures with the -i option.
>      but it does not mention how to specify a machine, although I did 
> find it in
> objdump --help later:)
> 
> debian GNU objdump 2.14.90.0.7 20031029
> 
> >one doesn't really have to read the sources to figure it out!
> >But the question of whether the default mode of objdump 
> >should be the minimum 32-bit legacy instruction set is a good 
> >one.  Not  many currenly used MIPS processors are MIPS I.  
> >I understand that disassembling advanced instructions that are 
> >not supported by a particular CPU as if they were normal can 
> >cause confusion and error, but perhaps the default would be to 
> >disassmble everything as MIPS64 rev 2, but with all instructions 
> >that are not in MIPS I flagged somehow, perhaps with a message
> >after the assembly code to indicate the extended ISA level?  e.g.
> >
> >a0000650:       07400003        bltz    k0,a0000660 <nmi_handler+0x1c>          
> >a0000654:       03a0d82d        move k1,sp *mips3*
> >a0000658:       3c1ba020        lui     k1,0xa020 
> >
> >Where specifying -m mips:isa64 or -m mips:4000 would suppress the warnings
> >on MIPS64 or MIPS III instructions respectively. Just a thought...
> >
> >----- Original Message ----- 
> >From: "Fuxin Zhang" <fxzhang@ict.ac.cn>
> >To: "Dmitriy Tochansky" <toch@dfpost.ru>
> >Cc: <linux-mips@linux-mips.org>
> >Sent: Thursday, October 14, 2004 10:45
> >Subject: Re: Strange instruction
> >
> >
> >  
> >
> >>objdump -d -mmips:4000 vmlinux to force it regconize all MIPS III 
> >>instructions
> >>
> >>I think this option should be renamed( i had try -mips3 -mmips3 etc. 
> >>before i find it
> >>by reading the source code)
> >> or the default should be changed.
> >>
> >>Dmitriy Tochansky wrote:
> >>
> >>    
> >>
> >>>Hello!
> >>>
> >>>When starts kernel for my au1500 board reseting board. After disassembling I found instruction
> >>>which reseting board. Here is few strings of "mipsel-linux-objdump -D vmlinux" output:
> >>>
> >>>---
> >>>
> >>>a0000650:       07400003        bltz    k0,a0000660 <nmi_handler+0x1c>          
> >>>a0000654:       03a0d82d        0x3a0d82d                                       
> >>>a0000658:       3c1ba020        lui     k1,0xa020 
> >>>
> >>>---
> >>>
> >>>Base address changed by me.
> >>>
> >>>What is A0000654? There is board resets.
> >>>      
> >>>
> >
> >
> >  
> >
> 

Strange instruction

[Dmitriy Tochansky]

Hello!

When starts kernel for my au1500 board reseting board. After disassembling I found instruction
which reseting board. Here is few strings of "mipsel-linux-objdump -D vmlinux" output:

---

a0000650:       07400003        bltz    k0,a0000660 <nmi_handler+0x1c>          
a0000654:       03a0d82d        0x3a0d82d                                       
a0000658:       3c1ba020        lui     k1,0xa020 

---

Base address changed by me.

What is A0000654? There is board resets.

Re: Strange instruction

[Thiemo Seufer]

Kevin D. Kissell wrote:
> That's a 64-bit add, which is actually being used as a 64-bit move
> of the "sp" register to k1.  Try "objdump -m mips:isa64" (or whatever
> variant gives your version of objdump the right to disassemble the
> MIPS III+/MIPS64 instructions.
> 
> One might suspect that your board monitor ROM was built for a 64-bit CPU.
> This illustrates why, if one want to write portable assembler code for MIPS,
> one should implement "move" operations as OR Target,$0,Source rather than
> using an ADDU or DADDU...

GNU as has "move" as builtin macro which is expanded differently for
32 and 64 bit mode. This simplifies the task of writing code for both
models. Unfortunately the expansion was broken for a while and
generated always the 64 bit version if the toolchain was 64bit
_capable_. IIRC this was fixed in the early 2.14 timeframe.


Thiemo

Re: Strange instruction

[Nigel Stephens]

Thiemo Seufer wrote:

>
>
>GNU as has "move" as builtin macro which is expanded differently for
>32 and 64 bit mode. This simplifies the task of writing code for both
>models. Unfortunately the expansion was broken for a while and
>generated always the 64 bit version if the toolchain was 64bit
>_capable_. IIRC this was fixed in the early 2.14 timeframe.
>
>
>  
>

Wouldn't it be safer, as Kevin suggests, for the "move" macro to 
generate "or $rd,$0,$rs", since that will work correctly in either mode?

Nigel

>  
>

Re: Strange instruction

[Thiemo Seufer]

Nigel Stephens wrote:
> Thiemo Seufer wrote:
> >GNU as has "move" as builtin macro which is expanded differently for
> >32 and 64 bit mode. This simplifies the task of writing code for both
> >models. Unfortunately the expansion was broken for a while and
> >generated always the 64 bit version if the toolchain was 64bit
> >_capable_. IIRC this was fixed in the early 2.14 timeframe.
> 
> Wouldn't it be safer, as Kevin suggests, for the "move" macro to 
> generate "or $rd,$0,$rs", since that will work correctly in either mode?

For CPUs with two adders the instruction scheduling is a bit better.
Ther are also many other macros which are expanded in dependence of
the 32/64 bit address/register size, a different "move" macro
expansion won't help much if the assembler invocation was wrong.


Thiemo

Re: Strange instruction

[Kevin D. Kissell]

> Nigel Stephens wrote:
> > Thiemo Seufer wrote:
> > >GNU as has "move" as builtin macro which is expanded differently for
> > >32 and 64 bit mode. This simplifies the task of writing code for both
> > >models. Unfortunately the expansion was broken for a while and
> > >generated always the 64 bit version if the toolchain was 64bit
> > >_capable_. IIRC this was fixed in the early 2.14 timeframe.
> > 
> > Wouldn't it be safer, as Kevin suggests, for the "move" macro to 
> > generate "or $rd,$0,$rs", since that will work correctly in either mode?
> 
> For CPUs with two adders the instruction scheduling is a bit better.

For CPUs with two adders, only one of which can do ORs, you mean.
Isn't that a pretty small population of MIPS CPUs?

> Ther are also many other macros which are expanded in dependence of
> the 32/64 bit address/register size, a different "move" macro
> expansion won't help much if the assembler invocation was wrong.

Perhaps, but it strikes me as being only prudent to remove unnecessarily
fragile artifacts like this.  I'm sure that there are some macros that cannot
be implemented in a 32/64-bit independent manner, but it's clear that some
of them could be, but are not. And those that can be, should be, as a matter 
of software engineering principle.  Now, finding the time/money to actually 
do the work may be another story...  ;o)

            Regards,

            Kevin K. 

Re: Strange instruction

[Kevin D. Kissell]

> Nigel Stephens wrote:
> > Thiemo Seufer wrote:
> > >GNU as has "move" as builtin macro which is expanded differently for
> > >32 and 64 bit mode. This simplifies the task of writing code for both
> > >models. Unfortunately the expansion was broken for a while and
> > >generated always the 64 bit version if the toolchain was 64bit
> > >_capable_. IIRC this was fixed in the early 2.14 timeframe.
> > 
> > Wouldn't it be safer, as Kevin suggests, for the "move" macro to 
> > generate "or $rd,$0,$rs", since that will work correctly in either mode?
> 
> For CPUs with two adders the instruction scheduling is a bit better.

For CPUs with two adders, only one of which can do ORs, you mean.
Isn't that a pretty small population of MIPS CPUs?

> Ther are also many other macros which are expanded in dependence of
> the 32/64 bit address/register size, a different "move" macro
> expansion won't help much if the assembler invocation was wrong.

Perhaps, but it strikes me as being only prudent to remove unnecessarily
fragile artifacts like this.  I'm sure that there are some macros that cannot
be implemented in a 32/64-bit independent manner, but it's clear that some
of them could be, but are not. And those that can be, should be, as a matter 
of software engineering principle.  Now, finding the time/money to actually 
do the work may be another story...  ;o)

            Regards,

            Kevin K. 

Re: Strange instruction

[Thiemo Seufer]

Kevin D. Kissell wrote:
> > Nigel Stephens wrote:
> > > Thiemo Seufer wrote:
> > > >GNU as has "move" as builtin macro which is expanded differently for
> > > >32 and 64 bit mode. This simplifies the task of writing code for both
> > > >models. Unfortunately the expansion was broken for a while and
> > > >generated always the 64 bit version if the toolchain was 64bit
> > > >_capable_. IIRC this was fixed in the early 2.14 timeframe.
> > > 
> > > Wouldn't it be safer, as Kevin suggests, for the "move" macro to 
> > > generate "or $rd,$0,$rs", since that will work correctly in either mode?
> > 
> > For CPUs with two adders the instruction scheduling is a bit better.
> 
> For CPUs with two adders, only one of which can do ORs, you mean.

Yes.

> Isn't that a pretty small population of MIPS CPUs?

Sure, but there's little reason to deny this optimization.

> > Ther are also many other macros which are expanded in dependence of
> > the 32/64 bit address/register size, a different "move" macro
> > expansion won't help much if the assembler invocation was wrong.
> 
> Perhaps, but it strikes me as being only prudent to remove unnecessarily
> fragile artifacts like this.

It was an assembler bug.


Thiemo

Re: Strange instruction

[Dan Malek]

On Oct 14, 2004, at 7:53 AM, Dmitriy Tochansky wrote:

> Hello!
>
> When starts kernel for my au1500 board reseting board. After 
> disassembling I found instruction
> which reseting board. Here is few strings of "mipsel-linux-objdump -D 
> vmlinux" output:
>
> ---
>
> a0000650:       07400003        bltz    k0,a0000660 <nmi_handler+0x1c>
> a0000654:       03a0d82d        0x3a0d82d
> a0000658:       3c1ba020        lui     k1,0xa020

The Au1xxx is schizophrenic about the way it handles endianness.
The core starts up big endian mode, the bus interface depends upon
configuration options.  When you want to run the processor in
little endian mode (as is the case with this board), there are still
times during initialization that it is running big endian.  For these 
code
sequences, the instructions have to be byte swapped because the
bus interface is running little endian.  You are also using little 
endian
tools, so you will have to also byte swap these before disassembly
to get the proper instructions.


	-- Dan

Re: Strange instruction

[Dan Malek]

On Oct 14, 2004, at 9:45 AM, Dan Malek wrote:

> The Au1xxx is schizophrenic about the way it handles endianness.

I guess I need to apologize for my choice of words as some people
thought this implied something negative about this processor and
better describe what is likely happening here.

Tell me more details about exactly where you see this code in the
boot rom and what kind of boot rom you are using.  My comments
about the core start up and bus controller endian modes are
still valid, and in some cases there may be byte swapped code
depending upon the core/bus modes (they are separately
software configurable).  Just consider that when disassembling
instructions in the rom.

Thanks.


	-- Dan