9front - general discussion about 9front
 help / color / mirror / Atom feed
From: ori@eigenstate.org
To: 9front@9front.org
Subject: Re: [9front] Weird >>= operator behaviour in 5c/5l
Date: Tue, 19 Jan 2021 22:12:48 -0800	[thread overview]
Message-ID: <E8E4EF1A6057EBA2A06B9C17E6E3149C@eigenstate.org> (raw)
In-Reply-To: <6AE51FD76D949F3DCD2772A03858F36C@eigenstate.org>

Quoth ori@eigenstate.org:
> 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.
> 
I like this version more.

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 22:12:05 2021 -0800
@@ -789,6 +789,12 @@
 		r = p->reg;
 		if(r == NREG)
 			r = p->to.reg;
+		/*
+		 * R>>32 is encoded as R>>0, so flip to the
+		 * equivalent R<<0.
+		 */
+		if(instoffset == 0)
+			o1 &= ~(1<<5);
 		o1 |= r;
 		o1 |= (instoffset&31) << 7;
 		o1 |= p->to.reg << 12;


  reply	other threads:[~2021-01-20  6:39 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-17 21:36 Jonas Amoson
2021-01-18  4:05 ` Noam Preil
2021-01-18  5:20   ` ori
2021-01-18 16:11     ` Jonas Amoson
2021-01-20  5:59       ` ori
2021-01-20  6:12         ` ori [this message]
2021-01-20 12:06           ` Jonas Amoson
2021-01-20 22:11           ` Anthony Martin
2021-01-20 23:39             ` ori

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E8E4EF1A6057EBA2A06B9C17E6E3149C@eigenstate.org \
    --to=ori@eigenstate.org \
    --cc=9front@9front.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).