[9fans] Go and 21-bit runes (and a bit of Go status)
Just a heads-up to 9fans that the Go build for Plan 9 (386 or ARM) now expects the underlying platform to be updated with the 21-bit runes fixes from Bell Labs, the pertinent submission has been accepted and processed. Being up to date may not improve the build as much as one may wish, but not being up to date is guaranteed to be a problem. Anthony Martin is also in the process of getting another important patch to the Go distribution approved, while there may be delays figuring out what to do about the SSE2 extension to the Intel 386 architecture. Regarding the latter, Plan 9 does not allow floating point instructions to be executed within note handling, but erring on the side of caution also forbids instructions such as MOVOU (don't ask me) which is part of the SSE(2?) extension, but hardly qualifies as a floating point instruction. I have yet to see the type of suggestion for Go, but specially for Plan 9, that resolves all future conflicts on this score: it is a difficult bit of architectural design on both sides. I, for one, would be interested in plausible suggestions. The 64-bit people may need them even more, or maybe not at all. ++L
Re: [9fans] ARM and u-boot
> uImage support to 5l (patch/arm-uboot) - a requirement to exist nicely with > the loader. The exynos5 port that I am working on (Arndale Board, Samsung > Chromebook) relies on this exclusively. this is in 9atom. also note, that the kw kernel is bootable without uimage support. - erik
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
> Regarding the latter, Plan 9 does not allow floating point
> instructions to be executed within note handling, but erring on the
> side of caution also forbids instructions such as MOVOU (don't ask me)
> which is part of the SSE(2?) extension, but hardly qualifies as a
> floating point instruction.
movou (movdqu in the manual) is a sse2 data movement instruction.
not all sse2 instructions require that sse be turned on (pause, for example),
but movou uses at least one xmm register so is clearly using the sse
unit, thus requiring that it be turned on.
the go runtime memmove uses movou for memmoves between 33 and 128
bytes. i only see a 10 cycle difference for these cases on my atom machine,
(maximum 13%), so we're not missing out on much here by not using sse.
the real win, or loss for the plan 9 memmove, is in the short memmoves.
but this is a µbenchmark, and it would be more convincing with a real
world test.
- erik
harness; 8.memmovetest
memmove
1 92.42578 cycles/op
2 81.28125 cycles/op
4 56.47266 cycles/op
8 58.32422 cycles/op
16 62.28516 cycles/op
32 70.26563 cycles/op
64 86.32031 cycles/op
128 118.3125 cycles/op
512 323.5078 cycles/op
1024587.1094 cycles/op
40962119.242 cycles/op
131072 133058.5 cycles/op
rt·memmove
1 20.60156 cycles/op
2 20.34375 cycles/op
4 24.46875 cycles/op
8 22.42969 cycles/op
16 27.45703 cycles/op
32 52.82813 cycles/op
64 79.19531 cycles/op
128 129.1289 cycles/op
512 314.4492 cycles/op
1024569.9648 cycles/op
40962132.297 cycles/op
131072 135378.3 cycles/op#include
#include
typedef struct Movtab Movtab;
typedef void* (*Movfn)(void*, void*, ulong);
u32int runtimecpuid_edx = 0x400;
extern void* runtimememmove(void*, void*, ulong);
struct Movtab {
Movfn f;
char*name;
};
uvlong hz;
int sztab[] = {1, 2, 4, 8, 16, 32, 64, 128, 512, 1024, 4096, 128*1024, };
uchar buf0[128*1024];
uchar buf1[128*1024];
Movtab movtab[] = {memmove, "memmove", runtimememmove, "rt·memmove", };
//Movfn movtab[] = {memmove, runtimememmove};
uvlong
gethz(void)
{
char buf[1024], *f[5];
int n, fd;
fd = open("/dev/time", OREAD);
if(fd == -1)
sysfatal("%s: open /dev/time: %r", argv0);
n = pread(fd, buf, sizeof buf-1, 0);
if(n <= 0)
sysfatal("%s: read /dev/time: %r", argv0);
buf[n] = 0;
n = tokenize(buf, f, nelem(f));
if(n < 4)
sysfatal("%s: /dev/time: unexpected fmt", argv0);
return strtoull(f[3], 0, 0);
}
void
inner(Movfn f, ulong sz)
{
int i;
for(i = 0; i < 1024; i++)
f(buf1, buf0, sz);
}
void
main(int argc, char **argv)
{
int i, j;
uvlong t[2], c[nelem(movtab)][nelem(sztab)];
// double dhz;
Movfn f;
ARGBEGIN{
}ARGEND
hz = gethz();
// dhz = hz;
for(i = 0; i < 2; i++){
print("%s\n", movtab[i].name);
f = movtab[i].f;
for(j = 0; j < nelem(sztab); j++){
cycles(t + 0);
inner(f, sztab[j]);
cycles(t + 1);
c[i][j] = t[1] - t[0];
print("%d %g cycles/op\n", sztab[j],
c[i][j]/1024.);
sleep(0);
}
print("\n");
}
exits("");
}from postmaster@kw:
The following attachment had content that we can't
prove to be harmless. To avoid possible automatic
execution, we changed the content headers.
The original header was:
Content-Disposition: attachment; filename=memmove_386.s
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
memmove_386.s.suspect
Description: Binary data
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
> Regarding the latter, Plan 9 does not allow floating point > instructions to be executed within note handling, but erring on the > side of caution also forbids instructions such as MOVOU (don't ask me) > which is part of the SSE(2?) extension, but hardly qualifies as a > floating point instruction. The reason for FP being forbidden in note handler is that the kernel only saves the general purpose (Ureg) registers of the interrupted/notified process context. The fp or xmm registers are *not* saved and a note handler modifying those (thru fp instructions or sse instructions) would trash these registers for the program interrupted by the note. you could save the ureg, and jump out of the note handler with notejmp(), save the fp/sse registers yourself and then do the handling of the note outside of the note context. (this is how signals are implemented in ape). or we change the kernel to save the fp registers in notify() as well, pushing them on the user stack and restoring them on noted() just like the Ureg. or GO could just stop using *OMG-OPTIMIZED* SSE memmove() in the note handler. -- cinap
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
> or GO could just stop using *OMG-OPTIMIZED* SSE memmove() in the note > handler. But it would not stop users from doing so, so at minimum we'd have to detect the abuse and report it, rather than crash. Saving the entire register space would be expensive for all well-behaved processes and avoiding the micro-optimisation in memmove() (a Plan 9-specific option) would be my recommendation. But dragons do lurk and will need to be slain. Incidentally, do the FP registers need to be saved for the sake of MOVOUs? Or should I ask whether MOVOUs clobber registers not saved before note handling? ++L
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
> movou (movdqu in the manual) is a sse2 data movement instruction. > not all sse2 instructions require that sse be turned on (pause, for example), > but movou uses at least one xmm register so is clearly using the sse > unit, thus requiring that it be turned on. I see Erik answers my question: xmm registers may be clobbered. I suppose they could be saved in the Go runtime, if absolutely essential? ++L
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
the saving isnt the problem. the kernel already flushes the fp registers to the process fpsave area on notify. its just that we do *not* copy the registers to the user stack, but save them in the process fpsave area. as theres just just one fpsave area in the process, and not one for notes and one for normal code, note handler is forbitten to use fp again. its not for the sake of movou. its for the sake of the process interrupted by the note. say, you have a programm that gets just interrupted by note while in that omgoptimized sse memmove() where it just loaded some chunks into XMM0 register, and then the note fires. then the note handler does memmove itself modifying XMM0 itself loading it with something completely different. then note handler finishes continuing the original programm, then XMM0 would contain the garbage from the note handler! it would look for the program like if registers randomly change under it! -- cinap
Re: [9fans] ARM and u-boot
> also note, that the kw kernel is bootable without uimage > support. ... and so is any other Plan 9 arm kernel, as long as you have access to u-boot's console or config variables. See booting(8).
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
> then the note handler does memmove itself modifying XMM0 itself loading > it with something completely different. then note handler finishes > continuing the original programm, then XMM0 would contain the garbage > from the note handler! it would look for the program like if registers > randomly change under it! True enough. If memmove() were the only problem, solving it would be easy. One option: drop MOVOU altogether; another option: save xmm8 (following from what you said). But it's the whole FP edifice that's relevant in the bigger picture: it may be bad practice, but what if I want to compute the next iteration for pi in a note handler? How is the Go runtime going to stop me, or at least make sure I am aware that I should not be doing it rather than give me an incorrect answer that I then use to fire a ballistic missile at the wrong target? (I concede that I have not thought about this much - feel free to think you have to explain this to an idiot.) ++L
Re: [9fans] Fossil disk usage over 100%?
> This paragraph has more qualifiers than your average winter olympics If you prefer snarky insinuations rather than an attempt to convey accurate information, I think you're reading the wrong mailing list.
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
On Sun, Jun 02, 2013 at 05:54:14PM +0200, lu...@proxima.alt.za wrote: > I should not be doing it rather than give me an incorrect answer that > I then use to fire a ballistic missile at the wrong target? I knew Google was up to something. khm
Re: [9fans] Fossil disk usage over 100%?
On Sun, Jun 02, 2013 at 04:55:59PM +0100, Richard Miller wrote: > > This paragraph has more qualifiers than your average winter olympics > > If you prefer snarky insinuations rather than an attempt to convey > accurate information, I think you're reading the wrong mailing list. > I disagree.
Re: [9fans] Fossil disk usage over 100%?
> I disagree. Yes.
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
> I knew Google was up to something. Google? Who's Google? ++L
Re: [9fans] Fossil disk usage over 100%?
it takes no skill to make snarky comments. i have two file servers that have been continuously and reliably operating since 2003 and 2010 -- a ken fs since 2003, and a venti-backed fossil fs since 2010. I have a third which is currently pickled -- an fs64 that ran from the time geoff created it in 2006 until about 2010. all have been through power outages and in one case a disk failure. dedicate a machine to the file server. On Sun, Jun 2, 2013 at 9:09 AM, wrote: > > I disagree. > > Yes. > > >
Re: [9fans] Fossil disk usage over 100%?
On Jun 2, 2013, at 12:41, Skip Tavakkolian wrote: > it takes no skill to make snarky comments. Khm brought trolling back to the intelligent man. His work is truly an art. Veety
Re: [9fans] Fossil disk usage over 100%?
my guess is that it's a mutated gene. On Sun, Jun 2, 2013 at 9:45 AM, Matthew Veety wrote: > On Jun 2, 2013, at 12:41, Skip Tavakkolian > wrote: > > > it takes no skill to make snarky comments. > > Khm brought trolling back to the intelligent man. His work is truly an art. > > Veety >
Re: [9fans] Fossil disk usage over 100%?
On Sun, Jun 02, 2013 at 09:49:26AM -0700, Skip Tavakkolian wrote: > my guess is that it's a mutated gene. > Ah, a Chomskyite.
Re: [9fans] Fossil disk usage over 100%?
but was probably abused as a child. On Sun, Jun 2, 2013 at 9:53 AM, Kurt H Maier wrote: > On Sun, Jun 02, 2013 at 09:49:26AM -0700, Skip Tavakkolian wrote: > > my guess is that it's a mutated gene. > > > > Ah, a Chomskyite. > > >
Re: [9fans] Fossil disk usage over 100%?
On Sun, Jun 02, 2013 at 10:01:12AM -0700, Skip Tavakkolian wrote: > but was probably abused as a child. > This is a perfect counterexample to "it takes no skill to make snarky comments." You clearly need practice; this one was clumsy.
Re: [9fans] Fossil disk usage over 100%?
the feeding hours are over for the day; back to your cave. On Sun, Jun 2, 2013 at 10:13 AM, Kurt H Maier wrote: > On Sun, Jun 02, 2013 at 10:01:12AM -0700, Skip Tavakkolian wrote: > > but was probably abused as a child. > > > > This is a perfect counterexample to "it takes no skill to make snarky > comments." You clearly need practice; this one was clumsy. > >
Re: [9fans] Raspberry 9
Back in april I wrote: > Plan 9 works just as well on the model A as on the model B, except for > some problems with low-speed usb devices connected directly to the pi. > If you use a hub it should be fine. I've finally found the cause of this and supplied a patch to fix it. If you pull and build a new bcm kernel, it should now work the same on models A and B, with or without a usb hub. I believe the model A pi is now in stock in the US too, so the long standing "$25 computer" claim is now actually true. Caveat: it's for niche applications only - if you need to add an external ethernet dongle or a hub to support more usb devices, it would be cheaper just to get a model B instead.
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
cinap_len...@gmx.de once said: > or GO could just stop using *OMG-OPTIMIZED* SSE memmove() > in the note handler. This is exactly what I did in my patch. This was just a regression. Someone changed memmove a few weeks ago. Nothing to see here. Anthony
Re: [9fans] Fossil disk usage over 100%?
> If you prefer snarky insinuations rather than an attempt to convey > accurate information, I think you're reading the wrong mailing list. hahahahaha
Re: [9fans] test(1) -older bug?
its /n/sources/patch/testolder, also leaks dir in the case: if(rel) n = time(0) - n; if(n < 0) return 0; <- HERE r = dir->mtime < n; free(dir); return r; -- cinap
Re: [9fans] Fossil disk usage over 100%?
> dedicate a machine to the file server. This must be the best way to keep the plebeian hands off the artwork: museums that are only open to curators. This certainly also provided for my technical contribution to this mailing list. >> > my guess is that it's a mutated gene. > but was probably abused as a child. This is unhelpful. I wouldn't even go as far as calling Kurt a troll. You are just hurling off boring insults whereas he was pointing out the sad truth in a joking thus diplomatic manner - subsequently getting supported by your replies - that this mailing list is snarky, unfriendly and often unhelpful. Although I hope this is just you being drunk and attempting to troll yourself.
Re: [9fans] Fossil disk usage over 100%?
On 1 June 2013 04:56, Matthew Veety wrote: > You have more sack than I could ever say I have for putting anything > mildly important on fossil. !ls /n/dump /n/dump/2004 /n/dump/2005 /n/dump/2006 /n/dump/2007 /n/dump/2008 /n/dump/2009 ... This is fossil on venti, on file server hardware that has changed periodically (more than the software). I had more trouble with SSDs than ever with fossil (given venti). I can't remember the last time I had to reset the fossil from venti.
[9fans] gmtime() ulong
a while ago, libc's gmtime() was changed like this:
- hms = tim % 86400L;
- day = tim / 86400L;
+ hms = (ulong)tim % 86400L;
+ day = (ulong)tim / 86400L;
if(hms < 0) {
...
i asked what this change tried to intend here:
http://9fans.net/archive/2013/05/12
anyone?
on the topic, i thought about how to handle the 2038 problem
in general with 9p which uses unsigned 32bit integers for atime
and mtime fields.
whenever we get 32 bit time field that cannot represent time,
we could interpret it in context of the system time.
say, if we get to interpret a mtime or atime filed from (old?)
9p server, we do:
/* new types */
vlong now, mtime;
/*
* get current system time, with some form of new time()
* function returning 64bit signed integer.
*/
now = time(0);
/*
* olddir->mtime being 32bit unsigned integer from legacy system
* and mtime being new 64bit signed integer time
*/
mtime = now + (vlong)(olddir->mtime - (now & 0x));
so whenever we get some old 32 bit long time type, we assume that the
values just wrap arround and we have to interpret it in context
to the current time assuming that the time delta to current time will
be smaller than 2^32 seconds.
does this make any sense?
--
cinap
[9fans] PBSR...EI
Hello everyone, maybe this can be of interest to someone. I have downloaded from 9legacy the old 9spirit iso (the newest uses bell's 9load, doesn't it?) I have installed the system selecting a fat partition with bell's iso. All went right, and I reboot. First thing happens: MBR...PBS1...Bad format or I/O error So I load the CD and disk/format the fat partition with 9load, pbslba and 9pf from the CD. This board has 2 IDE ports and 2 SATA ports. If I have one disk in SATA and other in master of first IDE, 9load of the official plan9 gets confused and can't load the kernel. 9load from the CD boots the kernel, but after 'root is from ...' the kernel crashes with /boot/kfs does not exist All this is about sdC0. It's weird, because once the system is running (the CD) all the disk are recognized right. So first thing learned: let the SATA disk and remove master of primary IDE, or let IDE and remove SATA. (The official iso doesn't boot, no matter if I dance a tango or a bossa-nova with my disks) Now I can boot with the kernel and 9load from the CD. With CD's 9load and bell's 9pf, the system halt with /boot/kfs does ... So I have official plan9 root with 9load, pbslba and 9pf from old 9spirit iso. I know those are patches from erik, so the best would be use his new kernel, but the cpu0:spurious interrupt ... is a little intimidating to an ignorant like me. I will try his new iso, and thanks erik. Regards, trebol.
Re: [9fans] gmtime() ulong
arg, screwed up... that should'v been (long) not (vlong)... too drunk, too late... -- cinap
Re: [9fans] gmtime() ulong
> on the topic, i thought about how to handle the 2038 problem > in general with 9p which uses unsigned 32bit integers for atime > and mtime fields. on the one hand one could just expect long to be always 64-bits by 2038. but that seems timid. i'd rather see the time base switched to nanoseconds. then the bother of the switch might benefit us while we still use the system. :-) 2038 is still 25 years off. a more pressing worry for me is the fact that haswell chipsets, and newer atom motherboards only support xhci. - erik
Re: [9fans] Fossil disk usage over 100%?
On Sun, Jun 2, 2013 at 2:58 PM, hiro <23h...@gmail.com> wrote: > > dedicate a machine to the file server. > > This must be the best way to keep the plebeian hands off the artwork: > museums that are only open to curators. > This certainly also provided for my technical contribution to this mailing > list. > you misunderstand the strength of Plan 9 and use a false premise in regards to the cost. the point of Plan 9 is to have a heterogeneous collection of machines, each dedicated to a finite set of services (resources) that one can import, export and access in a uniform way. you seem to imply that requiring more than one machine is elitist. one can build a RPi Plan 9 cpu for less than $50; hardware that can run an fs (any fs) is cheap-to-free. > > >> > my guess is that it's a mutated gene. > > but was probably abused as a child. > > This is unhelpful. I wouldn't even go as far as calling Kurt a troll. > You are just hurling off boring insults whereas he was pointing out > the sad truth in a joking thus diplomatic manner - subsequently > getting supported by your replies - that this mailing list is snarky, > unfriendly and often unhelpful. Although I hope this is just you being > drunk and attempting to troll yourself. > > please tell us about your Plan 9 setup.
Re: [9fans] Fossil disk usage over 100%?
On Sun Jun 2 17:59:16 EDT 2013, 23h...@gmail.com wrote: > > dedicate a machine to the file server. > > This must be the best way to keep the plebeian hands off the artwork: > museums that are only open to curators. > This certainly also provided for my technical contribution to this mailing > list. it's odd to interpert this as a restriction when i believe this is a common technique, even among people with single-user systems. the reason for this technique is that if one dedicates a machine (or vm) to the file server, than one can be sure that punting the cpu server will leave one's files available and bugs in the cpu server won't leak over. at home, this is very helpful as sometimes the man cpu/auth server gets confused. dns is a common reason. it's good to be able to reboot the cpu server without interrupting my terminal. running out of memory or procs also has no effect on the fs. it is tautology to say that i have access to the file server. a side benefit is this technique scales to very large systems. at work we run a file server(per location) that supports 40+ cpu/terminal machines and many users. in this case direct access to the file server is restricted to those reponsible for keeping it running. the seperate file server allows a policy that many folks can fix the dns server without becoming responsible for any file server issues. > >> > my guess is that it's a mutated gene. > > but was probably abused as a child. > > This is unhelpful. I wouldn't even go as far as calling Kurt a troll. > You are just hurling off boring insults whereas he was pointing out > the sad truth in a joking thus diplomatic manner - subsequently sorry, what point was he making? i saw a clearly false claim unsupported by evidence or anecdote that fossil is not stable. but that's not making a point. - erik
Re: [9fans] test(1) -older bug?
On Sun Jun 2 17:31:05 EDT 2013, cinap_len...@gmx.de wrote: > its /n/sources/patch/testolder, also leaks dir in the case: > > if(rel) > n = time(0) - n; > if(n < 0) > return 0; <- HERE > r = dir->mtime < n; > > free(dir); > return r; thanks. i appreciate the catch. [sources] applied patch: /n/atom/patch/applied/testolder1 email quans...@quanstro.net readme fix memory leak pointed out by cinap removed files /sys/src/cmd/test.c test.c /sys/src/cmd/test.c test.c test.c.orig:373,380 - test.c:373,381 if(rel) n = time(0) - n; if(n < 0) - return 0; - r = dir->mtime < n; + r = 0; + else + r = dir->mtime < n; free(dir); return r; -- merge...backup...copy... cpfile test.c /n/dist/sys/src/cmd/test.c done
Re: [9fans] ARM and u-boot
> > also note, that the kw kernel is bootable without uimage > > support. > > ... and so is any other Plan 9 arm kernel, as long as you > have access to u-boot's console or config variables. > See booting(8). the rpi doesn't use u-boot by default, though, does it? i certainly don't see any indication on my machines. there's something just a little annoying about having a boot loader that is much larger than the kernel than you're loading. :-) - erik
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
> I see Erik answers my question: xmm registers may be clobbered. I > suppose they could be saved in the Go runtime, if absolutely > essential? no, they can not. saving registers is something that is done on context switch by the scheduler, and the go runtime is not involved in context switching; this is a user-level transparent thing. there are things that could be done. but before getting radical in a hurry, is there any place other than runtime·memmove() that would use sse in a note handler? - erik
Re: [9fans] ARM and u-boot
you'll need the uboot sd image that Richard put together (/n/sources/contrib/miller/uboot.img) that's what i use to boot the 9Pi cluster from the file server. On Sun, Jun 2, 2013 at 8:53 PM, erik quanstrom wrote: > > > also note, that the kw kernel is bootable without uimage > > > support. > > > > ... and so is any other Plan 9 arm kernel, as long as you > > have access to u-boot's console or config variables. > > See booting(8). > > the rpi doesn't use u-boot by default, though, does it? > i certainly don't see any indication on my machines. > > there's something just a little annoying about having a boot > loader that is much larger than the kernel than you're loading. :-) > > - erik > >
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
> there are things that could be done. but before getting radical in a > hurry, is there any place other than runtime·memmove() that > would use sse in a note handler? I presumed, perhaps incorrectly, that users are allowed to write their own signal handlers and are not prohibited from using floating point instructions in them. ++L
Re: [9fans] ARM and u-boot
On Sun, Jun 2, 2013 at 6:09 AM, erik quanstrom wrote: > also note, that the kw kernel is bootable without uimage > support. > Sure, though supporting uImage means you get a few things for free, not to mention it isn't ELF. This deserves a proper write up - I'll probably do something for IWP9 if I can manage to complete the port in time. At the very least, it will be WIP. There are a few subtle bits as to why I ended up going with uImages.
[9fans] More Go status
I have applied Anthony's CL 9796043 together with some tweaks to pkg/runtime/sys_plan9_386.s which I will pass on to Anthony as soon as I can; this has made it possible to complete the first set of run.rc tests without the major incidents I used to see. Some tests still fail, but I wasn't expecting miracles: I believe Anthony (and maybe others) are still working on changes I am not familiar with. Still, I think I can report some progress, specially towards being able to run a Go builder for the Plan 9/386 platform. What we are going to do about builders for the various offshoots I can't tell. ++L
