* [9fans] MIPS LE fp register ordering in MOVD
@ 2013-12-24 17:20 cherry
2013-12-26 23:46 ` cherry
0 siblings, 1 reply; 13+ messages in thread
From: cherry @ 2013-12-24 17:20 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
[-- Attachment #1: Type: text/plain, Size: 4062 bytes --]
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: 4366 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [9fans] MIPS LE fp register ordering in MOVD 2013-12-24 17:20 [9fans] MIPS LE fp register ordering in MOVD cherry @ 2013-12-26 23:46 ` cherry 2013-12-26 23:48 ` erik quanstrom 2013-12-27 3:41 ` cherry 0 siblings, 2 replies; 13+ messages in thread From: cherry @ 2013-12-26 23:46 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- 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 --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] MIPS LE fp register ordering in MOVD 2013-12-26 23:46 ` cherry @ 2013-12-26 23:48 ` erik quanstrom 2013-12-27 0:25 ` cherry 2013-12-27 3:41 ` cherry 1 sibling, 1 reply; 13+ messages in thread From: erik quanstrom @ 2013-12-26 23:48 UTC (permalink / raw) To: 9fans On Thu Dec 26 18:47:04 EST 2013, lunaria21@gmail.com wrote: > 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: so if you don't mind me asking, what is it that you're working on? - erik ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] MIPS LE fp register ordering in MOVD 2013-12-26 23:48 ` erik quanstrom @ 2013-12-27 0:25 ` cherry 2013-12-27 1:40 ` cinap_lenrek 2013-12-30 7:12 ` Skip Tavakkolian 0 siblings, 2 replies; 13+ messages in thread From: cherry @ 2013-12-27 0:25 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 843 bytes --] Of course not. I am porting Plan 9 to loongson machines, little endian MIPS. Now it runs on my loongson 2E machine, with ethernet, keyboad and basic video support. I just got floating point work, with changes in vl as above. I am trying to bring more devices up. As I don't have contrib directory, the sources are located at https://bitbucket.org/cherry9/plan9-loongson. Thanks, - cherry On Thu, Dec 26, 2013 at 6:48 PM, erik quanstrom <quanstro@labs.coraid.com>wrote: > On Thu Dec 26 18:47:04 EST 2013, lunaria21@gmail.com wrote: > > > 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: > > so if you don't mind me asking, what is it that you're working on? > > - erik > > [-- Attachment #2: Type: text/html, Size: 1375 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] MIPS LE fp register ordering in MOVD 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 1 sibling, 1 reply; 13+ messages in thread From: cinap_lenrek @ 2013-12-27 1:40 UTC (permalink / raw) To: 9fans great work, keep it up! :) -- cinap ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] MIPS LE fp register ordering in MOVD 2013-12-27 1:40 ` cinap_lenrek @ 2013-12-27 3:40 ` cherry 0 siblings, 0 replies; 13+ messages in thread From: cherry @ 2013-12-27 3:40 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 142 bytes --] Thank you :) On Thu, Dec 26, 2013 at 8:40 PM, <cinap_lenrek@felloff.net> wrote: > great work, keep it up! :) > > -- > cinap > > [-- Attachment #2: Type: text/html, Size: 455 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] MIPS LE fp register ordering in MOVD 2013-12-27 0:25 ` cherry 2013-12-27 1:40 ` cinap_lenrek @ 2013-12-30 7:12 ` Skip Tavakkolian 1 sibling, 0 replies; 13+ messages in thread From: Skip Tavakkolian @ 2013-12-30 7:12 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 965 bytes --] Cool! On Thu, Dec 26, 2013 at 4:25 PM, cherry <lunaria21@gmail.com> wrote: > Of course not. I am porting Plan 9 to loongson machines, little endian > MIPS. Now it runs on my loongson 2E machine, with ethernet, keyboad and > basic video support. I just got floating point work, with changes in vl as > above. I am trying to bring more devices up. As I don't have contrib > directory, the sources are located at > https://bitbucket.org/cherry9/plan9-loongson. > > Thanks, > - cherry > > > > On Thu, Dec 26, 2013 at 6:48 PM, erik quanstrom <quanstro@labs.coraid.com>wrote: > >> On Thu Dec 26 18:47:04 EST 2013, lunaria21@gmail.com wrote: >> >> > 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: >> >> so if you don't mind me asking, what is it that you're working on? >> >> - erik >> >> > [-- Attachment #2: Type: text/html, Size: 1827 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] MIPS LE fp register ordering in MOVD 2013-12-26 23:46 ` cherry 2013-12-26 23:48 ` erik quanstrom @ 2013-12-27 3:41 ` cherry 2013-12-27 4:32 ` Bruce Ellis 1 sibling, 1 reply; 13+ messages in thread From: cherry @ 2013-12-27 3:41 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 952 bytes --] On Thu, Dec 26, 2013 at 6:46 PM, cherry <lunaria21@gmail.com> wrote: > 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). > Indeed I can test it, simply diff the output of vl before and after. Using, fnuxi4 does NOT work for BE, as fnuxi4 is only set for LE (obj.c:1385,1404), probably due to (the same or another) historical reason. - cherry [-- Attachment #2: Type: text/html, Size: 1317 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] MIPS LE fp register ordering in MOVD 2013-12-27 3:41 ` cherry @ 2013-12-27 4:32 ` Bruce Ellis 2013-12-27 4:41 ` lucio 2013-12-28 1:22 ` cherry 0 siblings, 2 replies; 13+ messages in thread From: Bruce Ellis @ 2013-12-27 4:32 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 1270 bytes --] You might be able to blame the play station 2 and the two different MIPS chips it had. I did two compilers. The FP was very unusual and one was LE and the other BE. Inferno port worked well. brucee On 27 December 2013 14:41, cherry <lunaria21@gmail.com> wrote: > > > > On Thu, Dec 26, 2013 at 6:46 PM, cherry <lunaria21@gmail.com> wrote: > >> 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). >> > > Indeed I can test it, simply diff the output of vl before and after. > Using, fnuxi4 does NOT work for BE, as fnuxi4 is only set for LE > (obj.c:1385,1404), probably due to (the same or another) historical reason. > > - cherry > > [-- Attachment #2: Type: text/html, Size: 2075 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] MIPS LE fp register ordering in MOVD 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 1 sibling, 1 reply; 13+ messages in thread From: lucio @ 2013-12-27 4:41 UTC (permalink / raw) To: 9fans > You might be able to blame the play station 2 and the two different MIPS > chips it had. I did two compilers. The FP was very unusual and one was LE > and the other BE. Inferno port worked well. Eventually, it seems that the second compiler was somehow absorbed: 0c became a script to invoke vc, or somesuch. Could you shed some light on this? Or was forsyth involved? Bell Labs are consistently short on rationales. ++L ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] MIPS LE fp register ordering in MOVD 2013-12-27 4:41 ` lucio @ 2013-12-27 22:32 ` Bruce Ellis 0 siblings, 0 replies; 13+ messages in thread From: Bruce Ellis @ 2013-12-27 22:32 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 640 bytes --] I don't recall 0c ever being a script. That was done this century. Looks like things got broke. brucee On 27 December 2013 15:41, <lucio@proxima.alt.za> wrote: > > You might be able to blame the play station 2 and the two different MIPS > > chips it had. I did two compilers. The FP was very unusual and one was LE > > and the other BE. Inferno port worked well. > > Eventually, it seems that the second compiler was somehow absorbed: 0c > became a script to invoke vc, or somesuch. Could you shed some light > on this? Or was forsyth involved? Bell Labs are consistently short > on rationales. > > ++L > > > > [-- Attachment #2: Type: text/html, Size: 1080 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] MIPS LE fp register ordering in MOVD 2013-12-27 4:32 ` Bruce Ellis 2013-12-27 4:41 ` lucio @ 2013-12-28 1:22 ` cherry 2013-12-28 1:47 ` Bruce Ellis 1 sibling, 1 reply; 13+ messages in thread From: cherry @ 2013-12-28 1:22 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 1046 bytes --] On Thu, Dec 26, 2013 at 11:32 PM, Bruce Ellis <bruce.ellis@gmail.com> wrote: > You might be able to blame the play station 2 and the two different MIPS > chips it had. I did two compilers. The FP was very unusual and one was LE > and the other BE. Inferno port worked well. > Thanks very much for your hint. Inferno's 0l uses fnuxi4, whereas its vl uses fnuxi8, just like Plan 9's. I adopted the Inferno 0l's way, and added one line in obj.c to set fnuxi4 for BE, as well as the corresponding debug output. This seems to work with both BE and LE. For BE it gives the same output as before. diff /sys/src/cmd/vl/asm.c ./asm.c 672c672 < buf.dbuf[l] = cast[fnuxi8[i+4]]; --- > buf.dbuf[l] = cast[fnuxi4[i]]; diff /sys/src/cmd/vl/obj.c ./obj.c 1391a1392 > fnuxi4[i] = c; 1415a1417,1419 > for(i=0; i<4; i++) > Bprint(&bso, "%d", fnuxi4[i]); > Bprint(&bso, " "); Does this break anything? If not, I will submit a patch. Thanks, - cherry [-- Attachment #2: Type: text/html, Size: 1495 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9fans] MIPS LE fp register ordering in MOVD 2013-12-28 1:22 ` cherry @ 2013-12-28 1:47 ` Bruce Ellis 0 siblings, 0 replies; 13+ messages in thread From: Bruce Ellis @ 2013-12-28 1:47 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 1339 bytes --] Vita got the good gear. Ken said something about no need for them to find the bugs again. Halcyon days. We used 0? for RM4700 and later the QED7000. brucee On 28 Dec 2013 12:24, "cherry" <lunaria21@gmail.com> wrote: > > > > On Thu, Dec 26, 2013 at 11:32 PM, Bruce Ellis <bruce.ellis@gmail.com>wrote: > >> You might be able to blame the play station 2 and the two different MIPS >> chips it had. I did two compilers. The FP was very unusual and one was LE >> and the other BE. Inferno port worked well. >> > > Thanks very much for your hint. Inferno's 0l uses fnuxi4, whereas its vl > uses fnuxi8, just like Plan 9's. I adopted the Inferno 0l's way, and added > one line in obj.c to set fnuxi4 for BE, as well as the corresponding debug > output. This seems to work with both BE and LE. For BE it gives the same > output as before. > > diff /sys/src/cmd/vl/asm.c ./asm.c > 672c672 > < buf.dbuf[l] = cast[fnuxi8[i+4]]; > --- > > buf.dbuf[l] = cast[fnuxi4[i]]; > diff /sys/src/cmd/vl/obj.c ./obj.c > 1391a1392 > > fnuxi4[i] = c; > 1415a1417,1419 > > for(i=0; i<4; i++) > > Bprint(&bso, "%d", fnuxi4[i]); > > Bprint(&bso, " "); > > Does this break anything? If not, I will submit a patch. > > Thanks, > - cherry > > [-- Attachment #2: Type: text/html, Size: 2070 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2013-12-30 7:12 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-12-24 17:20 [9fans] MIPS LE fp register ordering in MOVD cherry 2013-12-26 23:46 ` cherry 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
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).