From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham
	autolearn_force=no version=3.4.4
Received: (qmail 19896 invoked from network); 20 Jan 2021 06:24:25 -0000
Received: from 1ess.inri.net (216.126.196.35)
  by inbox.vuxu.org with ESMTPUTF8; 20 Jan 2021 06:24:25 -0000
Received: from mimir.eigenstate.org ([206.124.132.107]) by 1ess; Wed Jan 20 00:59:38 -0500 2021
Received: from abbatoir.fios-router.home (pool-74-101-2-6.nycmny.fios.verizon.net [74.101.2.6])
	by mimir.eigenstate.org (OpenSMTPD) with ESMTPSA id 2a406283 (TLSv1.2:ECDHE-RSA-AES256-SHA:256:NO)
	for <9front@9front.org>;
	Tue, 19 Jan 2021 21:59:26 -0800 (PST)
Message-ID: <6AE51FD76D949F3DCD2772A03858F36C@eigenstate.org>
To: 9front@9front.org
Date: Tue, 19 Jan 2021 21:59:25 -0800
From: ori@eigenstate.org
In-Reply-To: <CAF46DJ5yKeVXWdWs5rNRds2TdsFVDpnFtYPL0S+ZLnjCRaT3eA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: replication SOAP template storage 
Subject: Re: [9front] Weird >>= operator behaviour in 5c/5l
Reply-To: 9front@9front.org
Precedence: bulk

Quoth Jonas Amoson <jonas.amoson@gmail.com>:
> Left shifting by 32 instead of 0 does explain my
> result, and seam indeed to be the real bug.
> 
> Regarding optimising out shifts where the number
> of steps is zero: it already does that when using the
> pattern x = x >> 0; but it doesn't for x >>= 0;
> 
> Thanks,
> Jonas
> 
> On Mon, 18 Jan 2021 at 07:50, <ori@eigenstate.org> wrote:
> >
> > Quoth Noam Preil <noam@pixelhero.dev>:
> > > It could just be architecture specific behavior.
> > >
> >
> > It's a bug. Two, actually.
> >
> > 1) a shift of zero should be optimized out by
> >    the compiler; cinap has a change for this in
> >    the works already. This fix should hide the
> >    second bug.
> >
> > 2) a shift by a literal zero is miscompiled by
> >    the assembler into a shift by 32, because
> >    of a missed special case in the instruction.
> >    encoding. I'm working on fixing the assembler.

I think this corrects the linker.

diff -r 01125acb5565 sys/src/cmd/5l/asm.c
--- a/sys/src/cmd/5l/asm.c	Tue Jan 19 19:56:38 2021 -0800
+++ b/sys/src/cmd/5l/asm.c	Tue Jan 19 21:56:58 2021 -0800
@@ -785,7 +785,7 @@
 
 	case 8:		/* sll $c,[R],R -> mov (R<<$c),R */
 		aclass(&p->from);
-		o1 = oprrr(p->as, p->scond);
+		o1 = oprrr((instoffset == 0) ? ASLL : p->as, p->scond);
 		r = p->reg;
 		if(r == NREG)
 			r = p->to.reg;

The PDF version of the arm architecture manual
I found implied that this is the correct way
to do it, and the official arm website is so
bad that I can't figure out if it contradicts
the PDF from some academic's website.

Only lightly tested, not sure if I have any
edge cases.