* [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-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
* 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
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).