From: cherry <lunaria21@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] MIPS LE fp register ordering in MOVD
Date: Thu, 26 Dec 2013 18:46:39 -0500 [thread overview]
Message-ID: <CACzOosASeD5Nf8wW54T_KEF6pudeDsxPOKxfO0Mp8fZdzC7fDw@mail.gmail.com> (raw)
In-Reply-To: <CACzOosBPd3-HxQGuMeoL9aMSoUDNvwRfNNNT=KhQJm2X3z5eDw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5136 bytes --]
Another issue is 0l/vl seems to output wrong bits for single precision
floats in little endian mode, due to a similar reason: it used bytes 4-7
instead of 0-3. This seems to fix it:
% diff /sys/src/cmd/vl/asm.c asm.c
672c672,675
< buf.dbuf[l] = cast[fnuxi8[i+4]];
---
> if(little)
> buf.dbuf[l] = cast[fnuxi8[i]];
> else
> buf.dbuf[l] = cast[fnuxi8[i+4]];
An alternative fix would be simply use fnuxi4 instead of fnuxi8, so that
both BE and LE would work (I guess, don't have BE machine to test). Is
there any (probably historical) reason for not using fnuxi4? I am asking
this since in /sys/src/cmd/vl/l.h:
EXTERN char fnuxi4[4]; /* for 3l [sic] */
Thanks,
- cherry
On Tue, Dec 24, 2013 at 12:20 PM, cherry <lunaria21@gmail.com> wrote:
> Hello Fans,
>
> It seems 0l/vl in little endian mode outputs wrong ordering of fp
> registers in MOVD. For a double, which is stored in an even-odd pair of fp
> registers, the least significant bits should be held in the even numbered
> register, regardless of the endianess. When moving from/to memory, in LE
> mode the first 4 bytes should go to even numbered registers, which is
> different from BE mode.
>
> A patch is submitted.
>
> % patch/diff 0l-movd-fpreg-order
> /sys/src/cmd/vl/asm.c
> asm.c.orig:1019,1026 -
> /n/sources/patch/0l-movd-fpreg-order/asm.c:1019,1031
> o1 = OP_IRR(opirr(ALAST), v>>16, REGZERO, REGTMP);
> o2 = OP_IRR(opirr(AOR), v, REGTMP, REGTMP);
> o3 = OP_RRR(oprrr(AADDU), r, REGTMP, REGTMP);
> - o4 = OP_IRR(opirr(AMOVF+ALAST), 0, REGTMP, p->to.reg+1);
> - o5 = OP_IRR(opirr(AMOVF+ALAST), 4, REGTMP, p->to.reg);
> + if(little) {
> + o4 = OP_IRR(opirr(AMOVF+ALAST), 0, REGTMP,
> p->to.reg);
> + o5 = OP_IRR(opirr(AMOVF+ALAST), 4, REGTMP,
> p->to.reg+1);
> + } else {
> + o4 = OP_IRR(opirr(AMOVF+ALAST), 0, REGTMP,
> p->to.reg+1);
> + o5 = OP_IRR(opirr(AMOVF+ALAST), 4, REGTMP,
> p->to.reg);
> + }
> break;
> case 16:
> o1 = OP_IRR(opirr(ALAST), v>>16, REGZERO, REGTMP);
> asm.c.orig:1029,1036 -
> /n/sources/patch/0l-movd-fpreg-order/asm.c:1034,1046
> o4 = OP_IRR(opirr(AMOVF+ALAST), 0, REGTMP, p->to.reg);
> break;
> case 8:
> - o1 = OP_IRR(opirr(AMOVF+ALAST), v, r, p->to.reg+1);
> - o2 = OP_IRR(opirr(AMOVF+ALAST), v+4, r, p->to.reg);
> + if(little) {
> + o1 = OP_IRR(opirr(AMOVF+ALAST), v, r, p->to.reg);
> + o2 = OP_IRR(opirr(AMOVF+ALAST), v+4, r, p->to.reg+1);
> + } else {
> + o1 = OP_IRR(opirr(AMOVF+ALAST), v, r, p->to.reg+1);
> + o2 = OP_IRR(opirr(AMOVF+ALAST), v+4, r, p->to.reg);
> + }
> break;
> case 4:
> o1 = OP_IRR(opirr(AMOVF+ALAST), v, r, p->to.reg);
> asm.c.orig:1050,1057 -
> /n/sources/patch/0l-movd-fpreg-order/asm.c:1060,1072
> o1 = OP_IRR(opirr(ALAST), v>>16, REGZERO, REGTMP);
> o2 = OP_IRR(opirr(AOR), v, REGTMP, REGTMP);
> o3 = OP_RRR(oprrr(AADDU), r, REGTMP, REGTMP);
> - o4 = OP_IRR(opirr(AMOVF), 0, REGTMP, p->from.reg+1);
> - o5 = OP_IRR(opirr(AMOVF), 4, REGTMP, p->from.reg);
> + if(little) {
> + o4 = OP_IRR(opirr(AMOVF), 0, REGTMP, p->from.reg);
> + o5 = OP_IRR(opirr(AMOVF), 4, REGTMP, p->from.reg+1);
> + } else {
> + o4 = OP_IRR(opirr(AMOVF), 0, REGTMP, p->from.reg+1);
> + o5 = OP_IRR(opirr(AMOVF), 4, REGTMP, p->from.reg);
> + }
> break;
> case 16:
> if(r == REGTMP)
> asm.c.orig:1062,1069 -
> /n/sources/patch/0l-movd-fpreg-order/asm.c:1077,1089
> o4 = OP_IRR(opirr(AMOVF), 0, REGTMP, p->from.reg);
> break;
> case 8:
> - o1 = OP_IRR(opirr(AMOVF), v, r, p->from.reg+1);
> - o2 = OP_IRR(opirr(AMOVF), v+4, r, p->from.reg);
> + if(little) {
> + o1 = OP_IRR(opirr(AMOVF), v, r, p->from.reg);
> + o2 = OP_IRR(opirr(AMOVF), v+4, r, p->from.reg+1);
> + } else {
> + o1 = OP_IRR(opirr(AMOVF), v, r, p->from.reg+1);
> + o2 = OP_IRR(opirr(AMOVF), v+4, r, p->from.reg);
> + }
> break;
> case 4:
> o1 = OP_IRR(opirr(AMOVF), v, r, p->from.reg);
>
> Let me know if I missed anything.
>
> Thanks and Merry Christmas.
> - cherry
>
>
[-- Attachment #2: Type: text/html, Size: 5700 bytes --]
next prev parent reply other threads:[~2013-12-26 23:46 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-24 17:20 cherry
2013-12-26 23:46 ` cherry [this message]
2013-12-26 23:48 ` erik quanstrom
2013-12-27 0:25 ` cherry
2013-12-27 1:40 ` cinap_lenrek
2013-12-27 3:40 ` cherry
2013-12-30 7:12 ` Skip Tavakkolian
2013-12-27 3:41 ` cherry
2013-12-27 4:32 ` Bruce Ellis
2013-12-27 4:41 ` lucio
2013-12-27 22:32 ` Bruce Ellis
2013-12-28 1:22 ` cherry
2013-12-28 1:47 ` Bruce Ellis
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=CACzOosASeD5Nf8wW54T_KEF6pudeDsxPOKxfO0Mp8fZdzC7fDw@mail.gmail.com \
--to=lunaria21@gmail.com \
--cc=9fans@9fans.net \
/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).