From mboxrd@z Thu Jan  1 00:00:00 1970
Mime-Version: 1.0
Date: Thu, 10 Mar 2005 10:39:55 -0800
References: AAQ4DJCAAAgDAaTsLseeeKUMOBBGyNdf
Message-ID: <20050310T103955Z_FFB700000000@mail2.cu-portland.edu>
From: Ben Huntsman <BHuntsman@mail2.cu-portland.edu>
Subject: Re: [9fans] got it
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Topicbox-Message-UUID: 2245ff9c-ead0-11e9-9d60-3106f5b1d025

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.=20

on arm.

ulong *x, y[64];

	x =3D y;
	*x++ =3D 1;
	*x++ =3D 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=20
(otherwise it would be y-252, right? 63*4). Then it does a pre-increment=20=

and offset by 4, which puts you right at the first element of y.=20

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

That's my reading anyway.

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

ron