Re: [9fans] chem preprocessor
On Tue, Aug 12, 2014 at 4:03 PM, Jacob Todd wrote: > BWK wrote a preprocessor for troff for drawing chemical structures long ago. > I've ported it to plan 9 with just a small changes. If you would like to try > it out just `9fs busybeingbrutal.org`, it's chem.tbz. I have only tested the > examples. > Tried a few examples and it works for me, very nice. Thank you. - cherry
[9fans] Loongson port, and 64 bit MIPS
Hello 9Fans, I just got a Loongson 2F machine (Yeeloong 8089A laptop) (MIPS LE), so I extended my previous Loongson 2E port (32 bit) to run on it. Now both machines can run Plan 9. Specific to 2F laptop, the keyboard, mouse, screen and ethernet are supported. The hard drive is supported only on 2E. USB does not work yet on either machine. And for the userland of MIPS LE, all the commands built and seem to work okay, including acme and page. If anybody interested, check it out at https://bitbucket.org/cherry9/plan9-loongson (lucio, is it the same machine as yours?) Currently the 2F kernel specific bits are kept in a separated directory. It is quite similar to 2E but I haven't tried to unify both kernels. Bind it before the 2E sources to use it. As a separated message, upon minux's request, I started to look into 64 bit MIPS. Both 2E and 2F machines are 64 bit, though R4000-ish, not standard MIPS64. Currently I build the compiler, 4c, based on the old one from /n/sources/contrib/tim, now at https://bitbucket.org/cherry9/4c With this compiler, the 64 bit kernel is in progress. For now, it boots on my 2E machine, with serial console only. I haven't got time to look into any device drivers. PCI space is 32 bit... Will do it ASAP. Hope this message is useful. Thanks, -cherry
Re: [9fans] Loongson port, and 64 bit MIPS
On Fri, Aug 15, 2014 at 1:54 AM, Fausto Saporito wrote: > Yep it's cool! > I have one from Tekmote (supplier for all Europe). > They have also a laptop with Loongson 3 (full MIPS64). Thank all! Yes, they do. Loongson 3A is multicore, which I would like to play with. But it is too far expensive to me... - cherry
Re: [9fans] Loongson port, and 64 bit MIPS
On Fri, Aug 15, 2014 at 3:23 AM, David du Colombier <0in...@gmail.com> wrote: > Awesome job! Thanks. > > -- > David du Colombier > Thanks again! Indeed I have a question about unifying the 2E and 2F kernels. Currently 2F is separated so that it is convenient for me to experiment new code for 2F hardwares without worrying breaking 2E. Eventually it might be better to unify them. I think it is possible to share the C code, with specific hardware enabled/disabled in configuration file. Mainly the differences are some #define'd or enum constants in mem.h and io.h, including IRQ and some addresses. What would be the best way to do it? Would it be possible to upstream this port to distribution? Minux strongly encouraged me to do so. Thanks, - cherry
Re: [9fans] Loongson port, and 64 bit MIPS
On Fri, Aug 15, 2014 at 2:30 PM, David du Colombier <0in...@gmail.com> wrote: >> Indeed I have a question about unifying the 2E and 2F kernels. >> Currently 2F is separated so that it is convenient for me to >> experiment new code for 2F hardwares without worrying breaking 2E. >> Eventually it might be better to unify them. I think it is possible to >> share the C code, with specific hardware enabled/disabled in >> configuration file. Mainly the differences are some #define'd or enum >> constants in mem.h and io.h, including IRQ and some addresses. What >> would be the best way to do it? > > Maybe you could define them as variables in the port section > of the configuration files. I think this is particularly > relevant for things like screen resolution. > > For example: > > port > int width = 1024; > int height = 600; Thanks for all suggestions. I have unified clock.c and screen.c for both machines in this way. > > You could also define something like ln2e and ln2f variables > and make some code depending on these conditions. The best > would be to detect the cpu revision automatically. Is it > possible in your case? Yes, it is possible. The cpu revision are different on the two. I may try this once I get more hardwares working. > > Perhaps others have better ideas. > >> Would it be possible to upstream this port to distribution? Minux >> strongly encouraged me to do so. > > You may want to contact Jim McKie and explain your work and > motivations to get it merged into the Plan 9 distribution. > Thank you for the information. > -- > David du Colombier >
Re: [9fans] Loongson port, and 64 bit MIPS
On Sat, Aug 16, 2014 at 12:03 PM, wrote: >> I just got a Loongson 2F machine (Yeeloong 8089A laptop) (MIPS LE), so >> I extended my previous Loongson 2E port (32 bit) to run on it. > > Got it running, it's simply MAGIC! I am very happy to hear this. Thanks very much for your encouragement. I also uploaded a kernel image to the download page of the bitbucket repo. https://bitbucket.org/cherry9/plan9-loongson/downloads/9ln2flive This kernel has an in-kernel bzfs including binaries like sam, acme and the compiler (so it is a little big in size). So it can boot by itself, but also possible to connect a file server. Now you don't need it. Anyone who is interested could try this for start. - cherry
Re: [9fans] Loongson port, and 64 bit MIPS
On Sat, Aug 16, 2014 at 6:13 AM, Shane Morris wrote: > Just a quick one - I assume all devices on the Yeeloong (ie, wifi) are > functional? Not yet. I am trying to get the hard drive up on the Yeeloong. Haven't looked at wifi. And USB will be the hard part for me... Hopefully it will be all supported. > If so, this would make a nice little terminal... Now it can be a terminal with (cabled) ethernet. - cherry
Re: [9fans] Loongson port, and 64 bit MIPS
On Sun, Aug 17, 2014 at 1:28 AM, wrote: >> Not yet. I am trying to get the hard drive up on the Yeeloong. Haven't >> looked at wifi. And USB will be the hard part for me... Hopefully it >> will be all supported. > > I need to ask: VGA? I'll come back to that when you respond. The laptop screen works well. Did you mean the VGA port connecting an external monitor? It also works for me. The resolution remains at 1024x600, so it only occupies the upper part of a 4:3 monitor. Linux that comes with the machine does a similar thing. I haven't done anything for adjusting the resolution (don't know whether it is possible even). What problem did you have with the display? > > USB you should probably adopt from 9pi rather than the Bell Labs > distribution (there seems no avoiding the need to have 9pi, 9atom and > 9front at one's fingertips, which is another important issue right > now). Miller has done a lot of good work in that direction (and > Bluetooth, too). Thanks. Even the usb seem to be different, I did learn a lot from 9pi kernel. > > ATA ought to be a walk in the park, but Erik Quanstrom would be the > authority (outside of Bell Labs) on that. The hard drive seem to work, by just enabling sd in the configuration file (uncommenting sd in dev, and sdata in misc) and using generic ide driver of 2E. With ext2srv I can read/write linux partition. I didn't do much test though, nor looked into any detail. The disk seem to vary even the machines are all 8089A. Mine is a 2GB SSD, I guess yours not, so I am not sure it will apply on your machine. Experiments are welcomed (be sure to back up ahead). - cherry
Re: [9fans] Loongson port, and 64 bit MIPS
On Sun, Aug 17, 2014 at 1:24 AM, wrote: >> This kernel has an in-kernel bzfs including binaries like sam, acme >> and the compiler (so it is a little big in size). > > This is valiant (not dissimilar in intent from miller's 9pi) and > useful, but in my opinion you'll get a lot more support from people > who like me are willing to build the system from scratch. Of course. Thank you :) > > There are three issues that strike me here: 1. if I understand the > 9front-loader, you have built something that resembles it; I am not sure, probably not. Not familiar with 9front's loader. In my case, the kernel image is ELF which the bootloader recognizes. The boot process all come from /sys/src/9/boot from the Labs. > 2. if you > did, it would be nice to converge your version and theirs (I remember > you did a lot of work building the bzroot that 9front (and 9pi) may > want to adopt Yes, I did build the bzroot. My intention was to boot the machine even before the ethernet or disk driver was done. It turned out to be very helpful for me to write the driver and fix issues at that early stage. Now it used as a "live" image for people to start with, before building everything. Maybe turn it into a installation image in the future. It basically resembles the Labs' pc live/installation image, 9pcflop. I just don't need to do the tricks for putting everything into a floppy. > 3. more specifically, your understanding of how a > boot image is build could benefit the way 9pi is constructed as well. > > The above is from discussions we have had and not yet validated by > careful investigation of the actual release sources. In any case, I > believe that all plan 9 distributions have an opportunity with 9pi and > 9ln to consider a commonly maintained installation process. Maybe all > it takes is more documentation, but more likely just a little more > effort. Yes, any advice is welcomed. Thanks, - cherry
[9fans] MIPS64
Hello 9Fans, I would like to share that mips64 support of Plan 9 is currently available. The compiler and the libraries are at https://bitbucket.org/cherry9/4c And a 64-bit kernel for Loongson machine is built, at https://bitbucket.org/cherry9/plan9-loongson64 The kernel seems to work fine, and so do programs like acme and page. The userland support is in the compiler repo instead of along with the kernel, as I hope it will be useful for not only Loongson but mips64 in general. The kernel is not 9k kernel though. It is instead a (minimal) modification from 32-bit Plan 9. The next step is probably to switch to 9k kernel. For the userland, ape is not ported yet, so a few programs don't build. Currently the kernel code is not so user-friendly: to build the kernel, it needs to bind _port64/ before /sys/src/9/port/, and in the 32-bit Loongson sources bind 2f/ to the front to use 2F drivers. A kernel image is uploaded to the download page of the repo. Hope this is useful. Thanks, - cherry
Re: [9fans] MIPS64
On Sat, Sep 6, 2014 at 1:24 AM, Bruce Ellis wrote: > Interesting. I did 4c last century (for the Inferno PS2 port). Must have not > made it into the distrib. I only found one in contrib/tim (http://plan9.bell-labs.com/sources/contrib/tim/4acl.tgz), from which I started the work. It seems not the one you did? Thank you anyway. - cherry
Re: [9fans] how to undo in Rio shell window and Acme editor?
> > > I tried p9p Acme on Mac OS X, seems the mouse button emulation with > trackpad is broken, p9p Acme doesn't response to Shift + Secondary Click, > this is probably my problem, won't play it now until I'm more familiar with > 9front in Virtualbox. > Alt+Click does a middle click (button 2), Command+Click does a right click (button 3). Also, Command+Z does what's expected.
[9fans] loongson (spim) port
Hello Fans, In case any one is interested, recently I am trying to port Plan 9 to loongson 2E machine (fuloong 2E minicomputer from Lemote, mips le). Well, the 2F machines are way more popular than the 2E, but I have only the 2E in hand... The current status is that, the kernel is booted up, but the ethernet is not supported yet, nor the disk. So the only thing it can do is having fun through rc(1) on a serial console, with a bzroot built in the kernel. Now I am trying to bring the ethernet up, so hopefully we could have a minimal cpu server. While the machine is 64 bit, this kernel is 32 bit. Many bits are taken from the rb kernel (many thanks!). There is still a long way to go. Unlike the rb kernel, I haven't thought hard about performance issues for its tlb size. And libc stuff is just a copy from mips code with "just working" modifications for the endianess, and not all cases are covered. FP is not up either, for unknown reason... I would like to share it and I am asking for a contrib directory. - cherry
Re: [9fans] loongson (spim) port
Thank you Lucio. I am so encouraged as it's my first work on Plan 9. I am sending you the code off list, due to the big attachment. On Fri, Sep 13, 2013 at 1:08 AM, wrote: > > I would like to share it and I am asking for a contrib directory. > > I'd love to see what you've done, so maybe I can help twist Geoff's > arm (not that I've ever known Bell Labs to be reluctant with contrib > space on sources). > So, it seems I need some other way to share it, probably not 9p? > > I have a Yeeloong 8089 A I bought specially for this purpose, so > please can I (a) encourage you to continue and (b) contribute in any > way to your efforts? It does seem like you know considerably more > than I do about this, but I'm willing to catch up, if you have the > patience to guide me. > I have not looked up how Yeeloong are different to my 2E machine. There are general bits to fix/improve, e.g. spim libs. FP could be very helpful. Sadly, I have not been able to get any FP instruction out of 0a/c/l to run... Devices are also great, even if they could be different for different machines. I am still new to the 9 kernel and do not actually know more. I am willing to talk with you and learn from you about it. Thanks, - cherry
[9fans] MIPS LE fp register ordering in MOVD
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
Re: [9fans] MIPS LE fp register ordering in MOVD
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:
EXTERNcharfnuxi4[4];/* for 3l [sic] */
Thanks,
- cherry
On Tue, Dec 24, 2013 at 12:20 PM, cherry 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
>
>
Re: [9fans] MIPS LE fp register ordering in MOVD
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 wrote: > 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 you're working on? > > - erik > >
Re: [9fans] MIPS LE fp register ordering in MOVD
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 > < 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
Re: [9fans] MIPS LE fp register ordering in MOVD
Thank you :) On Thu, Dec 26, 2013 at 8:40 PM, wrote: > great work, keep it up! :) > > -- > cinap > >
Re: [9fans] MIPS LE fp register ordering in MOVD
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 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
[9fans] Things about werc + Plan 9 httpd
Hello,
As I recently played werc on Plan 9, I would like to share a couple of
things I found.
First, in the Docs page (
http://werc.cat-v.org/docs/web-server-setup/plan-9-httpd), it says
> you will need to replace the ‘%($“extraHeaders%)’ in lib/headers.tpl with
‘% echo $"extraHeaders’ no clue why.
The reason is %(...%) invokes "echo -n", and when the variable is empty (in
many cases $extraHeaders is), it calls write() with zero length, which, if
writes to a pipe, causes the other end of the pipe read()'s zero byte (as
pipe(3) says, write boundary is preserved), and it may think it's got to
the end. For example, cat, /sys/src/cmd/cat.c:10
while((n=read(f, buf, (long)sizeof buf))>0)
$“extraHeaders is used in bin/werc.rc:140
template $headers $master_template | awk_buffer
which also suffers the same problem. I have played many different ways to
work around it, and my current solution (I believe covering all cases) is
to wrap echo as
fn echo { builtin echo $* | cat }
so when it is echoing nothing, "cat" will consume the zero-length write().
Any comment or idea? I don't have p9p so I don't know why there is no such
problem. Probably unix's pipe implemented differently.
Second, in the same Docs page, the werc-wrapper's arguments seem not
matched with httpd's magic. Is it outdated? Or I missed anything? The
following works for me:
SERVER_NAME=$*(2)
REQUEST_URI=`{echo $*(22)}
if(~ $#REQUEST_URI 0)
REQUEST_URI=/
REQUEST_METHOD=$*(20)
PLAN9=/
Another thing is about remapping the root directory. Httpd does not handle
it, so we put all stuff into a sub directory, but many werc generated links
are still pointing to something under the root, e.g. the side-bar, and even
css. Certainly a way is to hack werc. My alternative approach is generating
rewriting rules mapping every first-level directories, putting it into a
script starting httpd, like,
echo /w @/magic/werc-wrap > /tmp/rewrite
echo / @/w >> /tmp/rewrite
for(i in `{ls -p $sitedir})
echo /$i @/w/$i >> /tmp/rewrite
bind /tmp/rewrite /sys/lib/httpd.rewrite
Kill httpd | rc
ip/httpd/httpd
A problem is adding new stuff to the root requires a restart of httpd, but
this happens probably not very often.
Hope this is useful, and sorry for a long email.
Thanks,
- cherry
[9fans] echo -n and zero-length write(2)
Hello Fans,
When echo(1) is invoked with -n and no or empty arguments, it calls
write(2) with zero length. When writing to a pipe, the other end of the
pipe read()'s zero byte, which causes it thinks it's got to the end and
close the pipe, and commands after the "echo -n" would fail to write. I
start thinking whether this is the desired behavior. On one hand, it is an
easy way to do a zero-length write() through echo -n, also it is consistent
for echo(1): to do a write(2). On the other hand, it makes rc script
behaves differently if sending to a pipe, and probably some people would
expect empty echo -n is just a no-op. Which should be better?
The context is, as posted on the werc list, it's template.awk generates rc
script with echo -n, and the output of the script is sent to a pipe. When
the argument is empty it fails. My last post was wrapping echo as
fn echo { builtin echo $* | cat }
But invoking cat for every echo hurts the performance. Perhaps the most
efficient way is to write an ad hoc echo that does not do zero-length
write(2)? Any suggestion?
Thanks,
- cherry
Re: [9fans] echo -n and zero-length write(2)
On Thu, Jan 23, 2014 at 11:10 PM, Anthony Sorace wrote: > > Any suggestion? > > There is no "better" answer to this question. You are advised to > read "The Unix and the Echo"[1], by Doug McIlroy, and Russ Cox's > adaptation for our system, "The Plan 9 and the Echo"[2]. > Thanks for pointing me to the right direction :) - cherry
