[9fans] got it

[9fans] got it

[Ronald G. Minnich]

an optimization is dumping onto another, it seems.

on arm.

ulong *x, y[64];

	x = y;
	*x++ = 1;
	*x++ = 2;

assembly gives:

	MOVW	$y-260(SP),R3
	MOVW	$1, R2
	MOVW.P	R2, $4(R3)

so the 260 puts you two words before the first element of Y, I'm guessing
(otherwise it would be y-252, right? 63*4). Then it does a pre-increment
and offset by 4, which puts you right at the first element of y.

Which all fails badly if you're setting x to a constant, as in constant
page table value in memory for startup.

That's my reading anyway.

I'm still unsure, all I know is the .s code looks wrong to me for the l.s
changes I'm making. (I'm too lazy to write assembly, I try to have C
compilers do it for me. Usually works. Maybe not this time.)

ron

Re: [9fans] got it

[Russ Cox]

i have tried a few things and cannot reproduce this.
can you post a short c program and a short sequence
of commands that turns the c program into the assembly?

$y-260(SP) means -260(SP) with a comment that
that's expected to be "y".  -260 is just the offset of y
in the stack frame.

russ


On Thu, 10 Mar 2005 11:34:44 -0700 (MST), Ronald G. Minnich
<rminnich@lanl.gov> wrote:
>
> an optimization is dumping onto another, it seems.
>
> on arm.
>
> ulong *x, y[64];
>
>         x = y;
>         *x++ = 1;
>         *x++ = 2;
>
> assembly gives:
>
>         MOVW    $y-260(SP),R3
>         MOVW    $1, R2
>         MOVW.P  R2, $4(R3)
>
> so the 260 puts you two words before the first element of Y, I'm guessing
> (otherwise it would be y-252, right? 63*4). Then it does a pre-increment
> and offset by 4, which puts you right at the first element of y.
>
> Which all fails badly if you're setting x to a constant, as in constant
> page table value in memory for startup.
>
> That's my reading anyway.
>
> I'm still unsure, all I know is the .s code looks wrong to me for the l.s
> changes I'm making. (I'm too lazy to write assembly, I try to have C
> compilers do it for me. Usually works. Maybe not this time.)
>
> ron
>

Re: [9fans] got it

[Ronald G. Minnich]

On Thu, 10 Mar 2005, Russ Cox wrote:

> $y-260(SP) means -260(SP) with a comment that
> that's expected to be "y".  -260 is just the offset of y
> in the stack frame.

yep, that I know. But first element of y should be, I was thinking, at
-252(SP), not 260.

I'll get the code.

ron

Re: [9fans] got it

[Ronald G. Minnich]

On Thu, 10 Mar 2005, Ronald G. Minnich wrote:

>
>
> On Thu, 10 Mar 2005, Russ Cox wrote:
>
> > $y-260(SP) means -260(SP) with a comment that
> > that's expected to be "y".  -260 is just the offset of y
> > in the stack frame.
>
> yep, that I know. But first element of y should be, I was thinking, at
> -252(SP), not 260.

sorry, russ, I missed the point. Never mind.

ron

Re: [9fans] got it

[Ben Huntsman]

Does the same happen on the Inferno side?  So far as I know, we've a few ARM guys over there..

>>> Ronald G. Minnich<rminnich@lanl.gov> 3/10/2005 10:34:44 AM >>>

an optimization is dumping onto another, it seems. 

on arm.

ulong *x, y[64];

	x = y;
	*x++ = 1;
	*x++ = 2;

assembly gives:

	MOVW	$y-260(SP),R3
	MOVW	$1, R2
	MOVW.P	R2, $4(R3)

so the 260 puts you two words before the first element of Y, I'm guessing 
(otherwise it would be y-252, right? 63*4). Then it does a pre-increment 
and offset by 4, which puts you right at the first element of y. 

Which all fails badly if you're setting x to a constant, as in constant 
page table value in memory for startup. 

That's my reading anyway.

I'm still unsure, all I know is the .s code looks wrong to me for the l.s 
changes I'm making. (I'm too lazy to write assembly, I try to have C 
compilers do it for me. Usually works. Maybe not this time.)

ron

Re: [9fans] got it

[Ronald G. Minnich]

On Thu, 10 Mar 2005, Ben Huntsman wrote:

> Does the same happen on the Inferno side?  So far as I know, we've a few
> ARM guys over there..

not sure. I just wrote a c program to generate the .s code to set up the
18 PTEs I need for ARM, and I'm filing this little thing under "C" for
"Curious".

It just plain looks like wrong code is getting generated, but who knows.
I'm no arm assembly expert.

Man, for a RISC, ARM sure has modes to it ...

ron