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.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 369 invoked from network); 20 Jan 2021 12:35:20 -0000 Received: from 1ess.inri.net (216.126.196.35) by inbox.vuxu.org with ESMTPUTF8; 20 Jan 2021 12:35:20 -0000 Received: from mail-vs1-f48.google.com ([209.85.217.48]) by 1ess; Wed Jan 20 07:06:33 -0500 2021 Received: by mail-vs1-f48.google.com with SMTP id 186so10455564vsz.13 for <9front@9front.org>; Wed, 20 Jan 2021 04:06:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=l9Q/rRrJIFBpZJbBnYeW6aX+kCsLDEG972cSCK23MXI=; b=Zjb8Yp62L3BpcPnUtIRiOfcTzbHl0WzBSMPhSG0EVKBoIZExeXCzXYNj8fIWIFJj4Q HxtqApTHRW9vxMAzKbNT75x4fm5WgzBWGzvL32aydUaxvARJOzOW6+Vid+LO5qkWqiiA kuayi1aouVZfhLkP97XfvFWnx/U6s0R+LhOnUkPIyUOmvXuhuuTxzJkk8yJrYIj82gUg tIoK94TX+kPMt37gKLehf/Ku4auV9I9qi+WE3sLT5zx19c9mGPA5FS9LmeMpZkD36vOk 0A9Z+MjQg78V6NV2f6QGdKmPqCGpiYd6ZyQ1d7qI3gI50C51AArA9PivpybKwHgf0WYw twQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=l9Q/rRrJIFBpZJbBnYeW6aX+kCsLDEG972cSCK23MXI=; b=YVmWJPMqCFo8BrRz+qGNwrFFql/sZwRN6Ux1vy/81k90VZqlBY7fHMkIvfpkd39pKO 5FoyE/akVjBtj9WcIhR2/s3mUQ+DDunMR3U6QrBI3ZaAIiCQnb6KRPLWmAZjTxNDogo3 5xVl8bNqVRL+PgFcubVyICfK0sZ3eFjBGfQ0jv+JWqZBwG8X5jJfY9BsU+XIUlLoitF9 Z+CMGHtSMRe0nCROlE/F4aGx2Kzia0/gosbh+adPuvUrI3RzuJxmAKaYnPo8Lz+7T+Mf DZA6pu84vunhNbvVE/z2XTNyqXbuvxlM6dfWllsznwnddk/R4YaQNq5XxZkdq6fstzjE Oudw== X-Gm-Message-State: AOAM532AtmK++yWgMvy9f9jy6DZj5FXSN4stDqbbDisB8OBctQ5M68we mkq2GaihewyzKJ9n+BMOyeHy+1Qdf4u+Ia+IGAgDgXWmdFw= X-Google-Smtp-Source: ABdhPJw8MYK6MCS9oKkGME7FWqfE3vMcBXXVRoRyweYJRn4Yi2mgvk+lZiJa/PlS+GeXMimI11+Aeok1CEJkghqktKw= X-Received: by 2002:a67:f810:: with SMTP id l16mr5863231vso.41.1611144382738; Wed, 20 Jan 2021 04:06:22 -0800 (PST) MIME-Version: 1.0 References: <6AE51FD76D949F3DCD2772A03858F36C@eigenstate.org> In-Reply-To: From: Jonas Amoson Date: Wed, 20 Jan 2021 14:06:11 +0200 Message-ID: To: 9front@9front.org Content-Type: text/plain; charset="UTF-8" List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: virtual extensible module-oriented blockchain rails Subject: Re: [9front] Weird >>= operator behaviour in 5c/5l Reply-To: 9front@9front.org Precedence: bulk Great! I have not tested your patch extensively yet, but Netsurf now runs without graphical glitches on 32-bit arm on my old Rpi terminal. Jonas On Wed, 20 Jan 2021 at 08:39, wrote: > > Quoth ori@eigenstate.org: > > Quoth Jonas Amoson : > > > 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, wrote: > > > > > > > > Quoth Noam Preil : > > > > > 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; >