Cool!
On Thu, Dec 26, 2013 at 4:25 PM, cherry 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 try
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" wrote:
>
>
>
> On Thu, Dec 26, 2013 at 11:32 PM, Bruce Ellis wrote:
>
>> You might be able to blame the pla
On Thu, Dec 26, 2013 at 11:32 PM, Bruce Ellis 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
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, 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
>
> 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,
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 wrote:
>
>
>
> On Thu, Dec 26, 2013 at 6:46 PM, cherry wrote:
Thank you :)
On Thu, Dec 26, 2013 at 8:40 PM, wrote:
> great work, keep it up! :)
>
> --
> cinap
>
>
On Thu, Dec 26, 2013 at 6:46 PM, cherry 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
> <
great work, keep it up! :)
--
cinap
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, t
On Thu Dec 26 18:47:04 EST 2013, lunari...@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 y
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]];
---
>
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 L
13 matches
Mail list logo
