as question

as question

[Dan Brennan]

In arch/ppc/kernel/head.S the following code segment exists:

turn_on_mmu:
        mfmsr   r0
        ori     r0,r0,MSR_DR|MSR_IR
        mtspr   SRR1,r0
        lis     r0,start_here@h
        ori     r0,r0,start_here@l
        mtspr   SRR0,r0
        SYNC
	RFI

However, when I do objdump on head.o this is what appears:

00000088 <turn_on_mmu>:
      88:       7c 00 00 a6     mfmsr   r0
      8c:       60 00 00 30     ori     r0,r0,48
      90:       7c 1b 03 a6     mtsrr1  r0
      94:       3c 00 00 00     lis     r0,0
      98:       60 00 00 00     nop
      9c:       7c 1a 03 a6     mtsrr0  r0
      a0:       4c 00 00 64     rfi

It appears that the code which loads the address of the label start_here
does not get assembled correctly. Is this observation correct?

I'm building for the est8260 target.

Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: as question

[David Edelsohn]

>>>>> Dan Brennan writes:

Dan> In arch/ppc/kernel/head.S the following code segment exists:

Dan> lis     r0,start_here@h
Dan> ori     r0,r0,start_here@l

Dan> However, when I do objdump on head.o this is what appears:

Dan> 94:       3c 00 00 00     lis     r0,0
Dan> 98:       60 00 00 00     nop

Dan> It appears that the code which loads the address of the label start_here
Dan> does not get assembled correctly. Is this observation correct?

	What do those instructions look like in the final executable after
the link-editor has statically substituted the address of the start_here
symbol?

David

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: as question

[Dan Brennan]

You're right, I objdump'd on the wrong object. They are okay. Still
trying to figure out why execution stops immediately following the RFI.
Thanks.

David Edelsohn wrote:
>
> >>>>> Dan Brennan writes:
>
> Dan> In arch/ppc/kernel/head.S the following code segment exists:
>
> Dan> lis     r0,start_here@h
> Dan> ori     r0,r0,start_here@l
>
> Dan> However, when I do objdump on head.o this is what appears:
>
> Dan> 94:       3c 00 00 00     lis     r0,0
> Dan> 98:       60 00 00 00     nop
>
> Dan> It appears that the code which loads the address of the label start_here
> Dan> does not get assembled correctly. Is this observation correct?
>
>         What do those instructions look like in the final executable after
> the link-editor has statically substituted the address of the start_here
> symbol?
>
> David

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: asm info

[Benjamin Herrenschmidt]

>I want to write some small functions/peices of code in
>ppc assembly. I have ppc user manuals and the ABI, but
>I don't know the syntax. I need to know how to code asm
>inside the C source, and I need to know how to write a
>.S file to assemble and link with C object files. Where
>can I find the docs ?  Does gcc support Altivec ?

Hi Giuliano. Just out of curiosity: what do you plan to
"altivec'ize" ? I'm doing it here or there too (the current
xvid CVS for example contain some altivec stuff).

You can write a .S file and get it assembled with the current
binutils. Look at the various existing examples (kernel code
for example ;) on how to get a .S file assembled. Basically
export your function with

 .glob function_name
function_name:
    your code here
    blr

You may need some -mcpu=7400 though

Inline assembly is a lot more tricky because mostly of the way
the registers are "abstracted" by the inline assembler to let the
compiler assign them. You have some examples of code not using
this "abstract" feature though in the altivec code of the IDCT and
motion compensation in libmpeg2.

Now, in order to generate vec code from C using apple/moto C
extensions, you can either use the old "gcc-vec" which is a 2.95.2
version of gcc with altivec extensions available here or there on the
net, or compile the latest gcc 3.1 prerelease. The former is quite
buggy, I used it to generate .S files from altivec C that I could
tweak a bit before assembling, I avoid it for the main C sources of
the project (the non-vec ones).
The later support altivec with the -maltivec flag (and different
scheduling if you use -mcpu=7400 or -mcpu=7450). Though it also use
the new syntax for vector constants (basically replace (x,y,z,...)
constants with {x,y,z,...} and it will be happy).


Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: as question

[Dan Malek]

Dan Brennan wrote:

> You're right, I objdump'd on the wrong object. They are okay. Still
> trying to figure out why execution stops immediately following the RFI.

How do you know it stops?


	-- Dan


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

asm info

[Giuliano Pochini]

I want to write some small functions/peices of code in
ppc assembly. I have ppc user manuals and the ABI, but
I don't know the syntax. I need to know how to code asm
inside the C source, and I need to know how to write a
.S file to assemble and link with C object files. Where
can I find the docs ?  Does gcc support Altivec ?


Bye.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: asm info

[Kaoru Fukui]

On 19 Apr, Giuliano Pochini wrote:
>
> I want to write some small functions/peices of code in
> ppc assembly. I have ppc user manuals and the ABI, but
> I don't know the syntax. I need to know how to code asm
> inside the C source, and I need to know how to write a
> .S file to assemble and link with C object files. Where
> can I find the docs ?  Does gcc support Altivec ?

Hi!

 ftp://ppc.linux.or.jp/pub/users/fukui

There are newer binutils and gcc-3.1.pre.
Those have Altivec instruction.
gcc-3.1 will be switch to altivec with -maltivec.

But If you want to altivec code,
It need the source which is written by altivec register.
See www.altivec.org about altivec.

Anyway, Try to write simple c source.
Then

gcc -S simple.c

You get simple.s

The simple.s is written by asmppc.

Kaoru


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: as question

[Gabriel Paubert]

On Thu, 18 Apr 2002, Dan Brennan wrote:

>
> In arch/ppc/kernel/head.S the following code segment exists:
>
> turn_on_mmu:
>         mfmsr   r0
>         ori     r0,r0,MSR_DR|MSR_IR
>         mtspr   SRR1,r0
>         lis     r0,start_here@h
>         ori     r0,r0,start_here@l
>         mtspr   SRR0,r0
>         SYNC
> 	RFI
>
> However, when I do objdump on head.o this is what appears:
>
> 00000088 <turn_on_mmu>:
>       88:       7c 00 00 a6     mfmsr   r0
>       8c:       60 00 00 30     ori     r0,r0,48
>       90:       7c 1b 03 a6     mtsrr1  r0
>       94:       3c 00 00 00     lis     r0,0
>       98:       60 00 00 00     nop
>       9c:       7c 1a 03 a6     mtsrr0  r0
>       a0:       4c 00 00 64     rfi
>
> It appears that the code which loads the address of the label start_here
> does not get assembled correctly. Is this observation correct?

No, the code is not yet linked. Hint: add --reloc to the objdump command
to see what instructions will be modified by the linker.

	Regards,
	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: asm info

[Giuliano Pochini]

> Hi!
>
>  ftp://ppc.linux.or.jp/pub/users/fukui
>
> There are newer binutils and gcc-3.1.pre.

Got it. thanks.


Bye.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: asm info

[Giuliano Pochini]

> Hi Giuliano. Just out of curiosity: what do you plan to
> "altivec'ize" ? I'm doing it here or there too (the current
> xvid CVS for example contain some altivec stuff).

Nothing. I was just curious. I have a good old bwG3 (yet grrr!).

> Inline assembly is a lot more tricky because mostly of the way
> the registers are "abstracted" by the inline assembler to let the
> compiler assign them.

Yes, I know why, but I don't know how :) I don't want to use
inline asm, I want to be able to read the code that contains it.

Bye.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/