* [9fans] quote of the day @ 2008-02-13 22:03 erik quanstrom 2008-02-13 23:08 ` Pietro Gagliardi 2008-02-13 23:24 ` [9fans] Google search " dave.l 0 siblings, 2 replies; 107+ messages in thread From: erik quanstrom @ 2008-02-13 22:03 UTC (permalink / raw) To: 9fans from the linux kernel: bootsplash: silent mode. - erik ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] quote of the day 2008-02-13 22:03 [9fans] quote of the day erik quanstrom @ 2008-02-13 23:08 ` Pietro Gagliardi 2008-02-13 23:24 ` [9fans] Google search " dave.l 1 sibling, 0 replies; 107+ messages in thread From: Pietro Gagliardi @ 2008-02-13 23:08 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 286 bytes --] Freenode.net just netsplitted. Here is from the ##c chat room: saparok 17:59 wow. I didnt' realize that dd command could take down all of freenode. On Feb 13, 2008, at 5:03 PM, erik quanstrom wrote: > from the linux kernel: > > bootsplash: silent mode. > > - erik [-- Attachment #2: Type: text/html, Size: 1818 bytes --] ^ permalink raw reply [flat|nested] 107+ messages in thread
* [9fans] Google search of the day 2008-02-13 22:03 [9fans] quote of the day erik quanstrom 2008-02-13 23:08 ` Pietro Gagliardi @ 2008-02-13 23:24 ` dave.l 2008-02-13 23:31 ` Pietro Gagliardi 1 sibling, 1 reply; 107+ messages in thread From: dave.l @ 2008-02-13 23:24 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On 13 Feb 2008, at 22:03, erik quanstrom wrote: > bootsplash: silent mode. :-). (In case anyone hasn't seen this yet ...) In a different part of the that strange dimension known as The Linux Zone, someone cryptically pointed me at a hideous exploit via: http://www.google.com/search?q=jessica_biel_naked_in_my_bed.c which I found amusing in a sick way. DaveL ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Google search of the day 2008-02-13 23:24 ` [9fans] Google search " dave.l @ 2008-02-13 23:31 ` Pietro Gagliardi 2008-02-13 23:41 ` erik quanstrom 2008-02-13 23:59 ` john 0 siblings, 2 replies; 107+ messages in thread From: Pietro Gagliardi @ 2008-02-13 23:31 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs In most /bin/sh variants (I'm not sure about original): :(){:|:};: Quick denial of service. On Feb 13, 2008, at 6:24 PM, dave.l@mac.com wrote: > On 13 Feb 2008, at 22:03, erik quanstrom wrote: > >> bootsplash: silent mode. > > :-). > > (In case anyone hasn't seen this yet ...) > > In a different part of the that strange dimension known as > The Linux Zone, someone cryptically pointed me at a hideous exploit > via: > > http://www.google.com/search?q=jessica_biel_naked_in_my_bed.c > > which I found amusing in a sick way. > > DaveL > ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Google search of the day 2008-02-13 23:31 ` Pietro Gagliardi @ 2008-02-13 23:41 ` erik quanstrom 2008-02-13 23:49 ` Pietro Gagliardi 2008-02-13 23:59 ` john 1 sibling, 1 reply; 107+ messages in thread From: erik quanstrom @ 2008-02-13 23:41 UTC (permalink / raw) To: 9fans On Wed Feb 13 18:32:19 EST 2008, pietro10@mac.com wrote: > In most /bin/sh variants (I'm not sure about original): > > :(){:|:};: > > Quick denial of service. > iirc, there were not functions in the orginal. - erik ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Google search of the day 2008-02-13 23:41 ` erik quanstrom @ 2008-02-13 23:49 ` Pietro Gagliardi 0 siblings, 0 replies; 107+ messages in thread From: Pietro Gagliardi @ 2008-02-13 23:49 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs So I think only in bash. How it works? http://www.cyberciti.biz/faq/understanding-bash-fork-bomb/ It does use :(){ :|: &};:, but I have tried :(){:|:};: and it worked. On Feb 13, 2008, at 6:41 PM, erik quanstrom wrote: > On Wed Feb 13 18:32:19 EST 2008, pietro10@mac.com wrote: >> In most /bin/sh variants (I'm not sure about original): >> >> :(){:|:};: >> >> Quick denial of service. >> > > > iirc, there were not functions in the orginal. > > - erik ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Google search of the day 2008-02-13 23:31 ` Pietro Gagliardi 2008-02-13 23:41 ` erik quanstrom @ 2008-02-13 23:59 ` john 2008-02-14 0:04 ` Pietro Gagliardi 2008-02-14 16:45 ` Douglas A. Gwyn 1 sibling, 2 replies; 107+ messages in thread From: john @ 2008-02-13 23:59 UTC (permalink / raw) To: 9fans > In most /bin/sh variants (I'm not sure about original): > > :(){:|:};: > > Quick denial of service. > This just in: Repeated forks can bring down a system. Story at 11. #include <u.h> #include <libc.h> int main() { for (;;) fork(); } Look ma! John ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Google search of the day 2008-02-13 23:59 ` john @ 2008-02-14 0:04 ` Pietro Gagliardi 2008-02-14 6:11 ` Anant Narayanan 2008-02-15 17:39 ` Skip Tavakkolian 2008-02-14 16:45 ` Douglas A. Gwyn 1 sibling, 2 replies; 107+ messages in thread From: Pietro Gagliardi @ 2008-02-14 0:04 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs That is exactly how that shell attack works. At one point, however, I think that the number of dynamically allocated task objects should run out, and the program should just wind about in an infinite loop of erroneous calls to fork(). What a shame. I'm happy the OS I'm writing does so. It isn't a UNIX-like one, but the semantics are similar. On Feb 13, 2008, at 6:59 PM, john@csplan9.rit.edu wrote: >> In most /bin/sh variants (I'm not sure about original): >> >> :(){:|:};: >> >> Quick denial of service. >> > > This just in: Repeated forks can bring down a system. > Story at 11. > > #include <u.h> > #include <libc.h> > > int main() { > for (;;) > fork(); > } > > Look ma! > > John > ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Google search of the day 2008-02-14 0:04 ` Pietro Gagliardi @ 2008-02-14 6:11 ` Anant Narayanan 2008-02-15 17:39 ` Skip Tavakkolian 1 sibling, 0 replies; 107+ messages in thread From: Anant Narayanan @ 2008-02-14 6:11 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Both the fork bomb and naked jessica (that's what they're calling it now) exploits have been fixed in linux for quite a while now. -- Anant ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Google search of the day 2008-02-14 0:04 ` Pietro Gagliardi 2008-02-14 6:11 ` Anant Narayanan @ 2008-02-15 17:39 ` Skip Tavakkolian 1 sibling, 0 replies; 107+ messages in thread From: Skip Tavakkolian @ 2008-02-15 17:39 UTC (permalink / raw) To: 9fans >> #include <u.h> >> #include <libc.h> >> >> int main() { >> for (;;) >> fork(); >> } >> >> Look ma! >> >> John this is the closest solution i've found: Patient: Doctor, it hurts when I do this. Doctor: Then don't do that! ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Google search of the day 2008-02-13 23:59 ` john 2008-02-14 0:04 ` Pietro Gagliardi @ 2008-02-14 16:45 ` Douglas A. Gwyn 2008-02-14 17:09 ` john 2008-02-14 17:14 ` [9fans] Google search of the day Eris Discordia 1 sibling, 2 replies; 107+ messages in thread From: Douglas A. Gwyn @ 2008-02-14 16:45 UTC (permalink / raw) To: 9fans john@csplan9.rit.edu wrote: > for (;;) > fork(); In genuine UNIX(tm) systems, there is a per-user process limit, so eventually the fork requests start failing. However, this program keeps trying to fork, so if you kill off some of the child processes it will spawn replacements. I don't think it counts as a proper "denial of service" attack, since it affects only the invoking user (well, it does bog down the system with swapping etc. but again, per-user resource bounds can address that). ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Google search of the day 2008-02-14 16:45 ` Douglas A. Gwyn @ 2008-02-14 17:09 ` john 2008-02-14 17:27 ` erik quanstrom 2008-02-14 17:14 ` [9fans] Google search of the day Eris Discordia 1 sibling, 1 reply; 107+ messages in thread From: john @ 2008-02-14 17:09 UTC (permalink / raw) To: 9fans > john@csplan9.rit.edu wrote: >> for (;;) >> fork(); > > In genuine UNIX(tm) systems, there is a per-user process limit, > so eventually the fork requests start failing. However, this > program keeps trying to fork, so if you kill off some of the > child processes it will spawn replacements. > > I don't think it counts as a proper "denial of service" attack, > since it affects only the invoking user (well, it does bog > down the system with swapping etc. but again, per-user resource > bounds can address that). It's a proper denial of service on Plan 9... I ran it while cpu'd into another box and found that somehow it killed *both* machines. IIRC, Plan 9 doesn't really have any kind of resource limiting, does it? (Yeah, I know, not necessary for a terminal, but it should be important for a cpu server) John ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Google search of the day 2008-02-14 17:09 ` john @ 2008-02-14 17:27 ` erik quanstrom 2008-02-15 9:50 ` Douglas A. Gwyn 0 siblings, 1 reply; 107+ messages in thread From: erik quanstrom @ 2008-02-14 17:27 UTC (permalink / raw) To: 9fans > > It's a proper denial of service on Plan 9... I ran it while > cpu'd into another box and found that somehow it killed *both* > machines. IIRC, Plan 9 doesn't really have any kind of resource > limiting, does it? (Yeah, I know, not necessary for a terminal, > but it should be important for a cpu server) > this is a problem for unix and plan 9. as soon as you try resource limiting, you have a new way to dos a machine. force the hostowner (or root) to use up his allotment. okay, the unix guys have thought of this and so they limit the number of ssh connections. the problem is that if you access as root to the box is via ssh, you're still done. i don't see an easy systematic solution to this type of problem. as was discussed a few months ago, any system that has unreserved stack allocation can suffer from similiar problems. the oom killer on linux is a symptom of this kind of problem. - erik ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Google search of the day 2008-02-14 17:27 ` erik quanstrom @ 2008-02-15 9:50 ` Douglas A. Gwyn 2008-02-15 11:49 ` Alf 2008-02-15 13:15 ` erik quanstrom 0 siblings, 2 replies; 107+ messages in thread From: Douglas A. Gwyn @ 2008-02-15 9:50 UTC (permalink / raw) To: 9fans erik quanstrom wrote: > as was discussed a few months ago, any system that has unreserved > stack allocation can suffer from similiar problems. the oom killer > on linux is a symptom of this kind of problem. Speaking of such things: (1) Linux had/has a "feature" where the storage reserved by malloc/sbrk may be over-committed, so that despite a "success" indication from the allocation, when the application gets around to using the storage it could suddenly fail due to there not being enough to satisfay all current processes. I urged (but don't know whether anybody listened) that overcommitment should be disabled by default, with processes that want it (said to include "sparse array" programs, which sounds like bad design but that's another issue) being required to enable it by a specific request, or at least flagged as special in the executable object file. I kludged around this in my portable malloc implementation by having a configuration flag which if set caused malloc to attempt to touch every page before reporting success, trapping SIGSEGV in order to maintain control. (2) C, as well as many other PLs, has always had a problem in that there is no clean, standard mechanism to handle the situation in which a function invocation finds insufficient stack remaining to complete the linkage (instance allocation). This is especially problematic in memory-constrained apps such as many embedded systems, when the algorithm is sufficiently dynamic that it is impossible to predict the maximum nesting depth. At least with malloc failure, the program is informed when there is a problem and can take measures to cope with it. I hope people working on run-time environments will find ways to do better. ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Google search of the day 2008-02-15 9:50 ` Douglas A. Gwyn @ 2008-02-15 11:49 ` Alf 2008-02-15 13:15 ` erik quanstrom 1 sibling, 0 replies; 107+ messages in thread From: Alf @ 2008-02-15 11:49 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs You can turn this off with # echo 2 > /proc/sys/vm/overcommit_memory See also the kernel Documentation directory, files vm/overcommit-accounting and sysctl/vm.txt. Douglas A. Gwyn wrote: > > Speaking of such things: > > (1) Linux had/has a "feature" where the storage reserved by > malloc/sbrk may be over-committed, ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Google search of the day 2008-02-15 9:50 ` Douglas A. Gwyn 2008-02-15 11:49 ` Alf @ 2008-02-15 13:15 ` erik quanstrom 2008-02-15 14:56 ` Brantley Coile 1 sibling, 1 reply; 107+ messages in thread From: erik quanstrom @ 2008-02-15 13:15 UTC (permalink / raw) To: 9fans believe it or not plan 9 does exactly the same thing, as was discussed in august under the subject "plan 9 overcommits memory?". fundamentally, i think the stack problem is an operating system problem not a language problem. (unless you're talking about 8 or 16-bit embedded things.) the thread library, for example does just fine requiring its threads to declare a stack size. in the case of a memory-constrained app on an embedded system, the solution might be to find/write an algorithm that doesn't need a stack. :-) - erik > (1) Linux had/has a "feature" where the storage reserved by > malloc/sbrk may be over-committed, so that despite a "success" > indication from the allocation, when the application gets around > to using the storage it could suddenly fail due to there not > being enough to satisfay all current processes. I urged (but > don't know whether anybody listened) that overcommitment should > be disabled by default, with processes that want it (said to > include "sparse array" programs, which sounds like bad design > but that's another issue) being required to enable it by a > specific request, or at least flagged as special in the > executable object file. I kludged around this in my portable > malloc implementation by having a configuration flag which if > set caused malloc to attempt to touch every page before > reporting success, trapping SIGSEGV in order to maintain > control. > > (2) C, as well as many other PLs, has always had a problem in > that there is no clean, standard mechanism to handle the > situation in which a function invocation finds insufficient > stack remaining to complete the linkage (instance allocation). > This is especially problematic in memory-constrained apps such > as many embedded systems, when the algorithm is sufficiently > dynamic that it is impossible to predict the maximum nesting > depth. At least with malloc failure, the program is informed > when there is a problem and can take measures to cope with it. > > I hope people working on run-time environments will find ways > to do better. ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Google search of the day 2008-02-15 13:15 ` erik quanstrom @ 2008-02-15 14:56 ` Brantley Coile 2008-02-15 15:44 ` Eris Discordia 0 siblings, 1 reply; 107+ messages in thread From: Brantley Coile @ 2008-02-15 14:56 UTC (permalink / raw) To: 9fans >> (2) C, as well as many other PLs, has always had a problem in >> that there is no clean, standard mechanism to handle the >> situation in which a function invocation finds insufficient >> stack remaining to complete the linkage (instance allocation). >> This is especially problematic in memory-constrained apps such >> as many embedded systems, when the algorithm is sufficiently >> dynamic that it is impossible to predict the maximum nesting >> depth. At least with malloc failure, the program is informed >> when there is a problem and can take measures to cope with it. >> >> I hope people working on run-time environments will find ways >> to do better. FORTRAN never had this problem. Its memory needs were fixed at compile time. Neither did COBOL. But then again, you couldn't write recursive programs either; all locals were static storage class. The trade off to get recursion has been worth it and doesn't cause problems actual use. It wasn't a problem with Algol, PL/1, Pascal, and C programs on very small machines. Why should it be a problem with today's memory sizes? Brantley ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Google search of the day 2008-02-15 14:56 ` Brantley Coile @ 2008-02-15 15:44 ` Eris Discordia 2008-02-15 16:07 ` erik quanstrom 0 siblings, 1 reply; 107+ messages in thread From: Eris Discordia @ 2008-02-15 15:44 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Fri, 15 Feb 2008 14:56:57 -0000, Brantley Coile <brantley@coraid.com> wrote: > FORTRAN never had this problem. Its memory needs were fixed at > compile time. Neither did COBOL. But then again, you couldn't > write recursive programs either; all locals were static storage > class. The trade off to get recursion has been worth it anddoesn't > cause problems actual use. My understanding has always been that the stack is a fundamental element of the x86 architecture. SP and BP registers, later ESP and EBP, are all about the stack. All return addresses are stored on the stack. Parameter passing relies on it. And I know of no other means of implementing them. Except by avoiding call/ret instructions and solely jmp'ing around in a true mess of a code. No true "procedures." I am almost sure the modern incarnations of FORTRAN (90, or even 77?) do support both true procedures and recursion. Though, I have not tried them so I do not have a say there. Automatic/scoped variables are allocated on the stack frame for procedure calls and/or nested code blocks (Flat Assembler's rendition of the IA-32 "enter" instruction supports up to 32 stack frames). And without them, programming would be a lot harder. There is also the "growing" heap for implementing dynamic variables which is quite as problematic as the stack because it, too, can grow beyond bounds and give one headaches. > It wasn't a problem with Algol, PL/1, Pascal, and C programs onvery > small machines. Why should it be a problem with today'smemory sizes? I remember getting a lot of "out of stack" errors from QuickBASIC, Turbo C and Borland C on MS-DOS. That was back when my computer had 8 MBs of RAM (a Win32 PE today has a default stack size of 8 MBs!) These days, stack overflows are most likely to cause problems by mingling data (return addresses and/or parameters) with executable code. I suppose segmentation mechanisms are there to precisely solve that problem. Never curse the "segfault" again ;-) -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Google search of the day 2008-02-15 15:44 ` Eris Discordia @ 2008-02-15 16:07 ` erik quanstrom 2008-02-15 16:43 ` maht 2008-02-15 17:39 ` Eris Discordia 0 siblings, 2 replies; 107+ messages in thread From: erik quanstrom @ 2008-02-15 16:07 UTC (permalink / raw) To: 9fans > My understanding has always been that the stack is a fundamental element > of the x86 architecture. SP and BP registers, later ESP and EBP, are all > about the stack. All return addresses are stored on the stack. Parameter > passing relies on it. And I know of no other means of implementing them. > Except by avoiding call/ret instructions and solely jmp'ing around in a > true mess of a code. No true "procedures." while this is true, you are confusing calling convention and architecture. the arch puts some limits on calling convention, but there is no requirement to use the stack if you have one. you could have a calling convention that every function emits a call block with the arguments at callblock+offset and the return value(s) at callblock- offset. doesn't matter if the arch has a stack or not. you are free to ignore it. ' > I am almost sure the modern incarnations of FORTRAN (90, or even 77?) do > support both true procedures and recursion. Though, I have not tried them > so I do not have a say there. fortran 95 supports recursion. this does not imply that the *language* requires a stack. it could be done via heap allocation. i don't know enough fortran to comment intelligently on how its done. > Automatic/scoped variables are allocated on the stack frame for procedure > calls and/or nested code blocks (Flat Assembler's rendition of the IA-32 > "enter" instruction supports up to 32 stack frames). And without them, > programming would be a lot harder. some languages -- notibly c -- assume a stack frame. there are many languages, like fortran that do not. you wouldn't notice what the compiler is doing in those languages. > There is also the "growing" heap for > implementing dynamic variables which is quite as problematic as the stack > because it, too, can grow beyond bounds and give one headaches. this is an entirely different problem as heap allocations in most languages are *explicit* thus allowing the programmer to respond to the situation appropriately. iirc, v7 sort used a binary search algorithm to figure out how much memory it could sbrk(). e.g. int memsize; for(memsize = 1024*1024; memsize >= 4*1024;) if(sbrk(memsize)>0) break; - erik ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Google search of the day 2008-02-15 16:07 ` erik quanstrom @ 2008-02-15 16:43 ` maht 2008-02-15 17:35 ` ron minnich 2008-02-15 17:39 ` Eris Discordia 1 sibling, 1 reply; 107+ messages in thread From: maht @ 2008-02-15 16:43 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs http://en.wikipedia.org/wiki/Stackless_Python Is it the same sort of stack ? It mentions Limbo as an inspiration The threaded / concatanative langauges such as Forth / Joy / Cat / V don't use a call stack, though they still use a stack for parameter manipulation. Charles Moore said that you get about 40 items on the stack in a big program iirc, though that was a few years ago. Still, not much use to C based environments. I'm hoping to get good enough at Forth to take one of these puppies for a walk one day : http://www.intellasys.net/index.php?option=com_content&task=view&id=35&Itemid=63 ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Google search of the day 2008-02-15 16:43 ` maht @ 2008-02-15 17:35 ` ron minnich 2008-02-15 18:14 ` Iruata Souza 2008-02-15 18:37 ` maht 0 siblings, 2 replies; 107+ messages in thread From: ron minnich @ 2008-02-15 17:35 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Fri, Feb 15, 2008 at 8:43 AM, maht <mattmobile@proweb.co.uk> wrote: > Charles Moore said that you get about 40 items on the stack in a big > program iirc, though that was a few years ago. > he musta never done breakpoint in SunOS on a read ... there was so much on the stack you couldn't display it on the screen. ron ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Google search of the day 2008-02-15 17:35 ` ron minnich @ 2008-02-15 18:14 ` Iruata Souza 2008-02-15 18:37 ` maht 1 sibling, 0 replies; 107+ messages in thread From: Iruata Souza @ 2008-02-15 18:14 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Fri, Feb 15, 2008 at 3:35 PM, ron minnich <rminnich@gmail.com> wrote: > On Fri, Feb 15, 2008 at 8:43 AM, maht <mattmobile@proweb.co.uk> wrote: > > > Charles Moore said that you get about 40 items on the stack in a big > > program iirc, though that was a few years ago. > > > > he musta never done breakpoint in SunOS on a read ... > > there was so much on the stack you couldn't display it on the screen. > > ron > that number^2 for some OS X stuff iru ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Google search of the day 2008-02-15 17:35 ` ron minnich 2008-02-15 18:14 ` Iruata Souza @ 2008-02-15 18:37 ` maht 1 sibling, 0 replies; 107+ messages in thread From: maht @ 2008-02-15 18:37 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > he musta never done breakpoint in SunOS on a read ... I assume he meant while running Forth ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Google search of the day 2008-02-15 16:07 ` erik quanstrom 2008-02-15 16:43 ` maht @ 2008-02-15 17:39 ` Eris Discordia 2008-02-15 19:05 ` maht 2008-02-15 23:37 ` [9fans] Non-stack-based calling conventions Lyndon Nerenberg 1 sibling, 2 replies; 107+ messages in thread From: Eris Discordia @ 2008-02-15 17:39 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Fri, 15 Feb 2008 16:07:59 -0000, erik quanstrom <quanstro@quanstro.net> wrote: > while this is true, you are confusing calling convention and > architecture. > the arch puts some limits on calling convention, but there is no > requirement > to use the stack if you have one. > > you could have a calling convention that every function emits a call > block > with the arguments at callblock+offset and the return value(s) at > callblock- > offset. doesn't matter if the arch has a stack or not. you are free to > ignore it. > ' The calling conventions I have seen are the ccall, stdcall (Windows' slightly modified version of the ccall), and pascal. All of them push parameters on the stack. On x86 (the only architecture I have seen), the return address is pushed on the stack as soon as something like "call 0x04500" or "call _myfunc" is executed. Not popping the right number of parameters before executing ret has times over been a problem with my programs. I understand that the push order and marshalling strategy (by-value/by-reference) need not be the same from one language to the other. Still, all "implementations" of languages on x86 (even FORTRAN, according to my copy of Steven Holzner's Advanced Assembly Programming) "have" to push their parameters on stack. I cannot see any other way to keep the bare minimum required for a procedure call: the return address, that is. Probably because I do not understand the notion of a "callblock." > some languages -- notibly c -- assume a stack frame. there are many > languages, > like fortran that do not. you wouldn't notice what the compiler is > doing in > those languages. You mean, if I disassemble a FORTRAN-compiled binary I will not see the classical EBP/ESP manipulation at the beginning of each procedure with automatic variables? I have disassembled C-compiled binaries and seen that (actually did it so that I could do the same in my assemly programs). ----snippet---- ;enter the stack frame push ebp mov ebp, esp ;reserve stack space for a 32-bit automatic variable sub ebp, 04h ;leave the stack frame mov esp, ebp pop ebp ;returning requires the return address ;(the previous value of EIP) pushed on the stack ret ----snippet---- On Fri, 15 Feb 2008 16:43:22 -0000, maht <mattmobile@proweb.co.uk> wrote: > The threaded / concatanative langauges such as Forth / Joy / Cat / V > don't use a call stack, though they still use a stack for parameter > manipulation. I have heard Forth is used for writing bootloaders (FreeBSD's loader was written in Forth last time I checked). If the architecture is x86, then issuing a call (op-code 0x9A+[ModRM]) certainly pushes EIP on the stack. Perhaps they use jmp for branching. > http://en.wikipedia.org/wiki/Stackless_Python > > Is it the same sort of stack ? Python is an "interpreted" language (like Perl). Everything is implemented on a semi-virtual machine (they usually call it the engine). Not sure their stack is the same as the x86 stack segment. "Stackless Python, or Stackless, is an experimental implementation of the Python programming language, so named because it avoids depending on the C call stack for its own stack. The language supports generators, microthreads, and coroutines." --Wikipedia -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Google search of the day 2008-02-15 17:39 ` Eris Discordia @ 2008-02-15 19:05 ` maht 2008-02-15 20:11 ` Eris Discordia 2008-02-15 23:37 ` [9fans] Non-stack-based calling conventions Lyndon Nerenberg 1 sibling, 1 reply; 107+ messages in thread From: maht @ 2008-02-15 19:05 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Forth doesn't use CALL it uses JMP Similar Threaded Interpretive Languages run an inner loop that does this pseudo code : (from Threaded Interpretive Languages: Their Design and Implementation by R. G. Loeliger) COLON: PSH I -> RS WA -> I JMP NEXT SEMI: POP RS -> I NEXT: @I -> WA I += 2 RUN: @WA -> CA WA += 2 CA -> PC RS is the stack PC is the program counter, procedures JMP to NEXT or SEMI when they are done I is the indirection pointer, WA is the word address (the nomenclature for procedure) The 2s are there because this code assumes 16bit addressing, @ is indirection CA is the call address so DUP is a word defined as (it copies the item on the top of the stack back to the top of the stack execute is a type marker, you can also have constant & colon dup: execute POP SP -> A PUSH A -> SP PUSH A -> SP JMP NEXT that's all very well but you then extend the assembler parts with new words made from the WAs (colon is the type marker for this) SEMI is where it JMPs to at the end moddiv: colon divmod swop semi I wrote a TIL in AVR assembler last summer but I've waiting to go on holiday this year so I can write some applications in it now I have a dev board :> ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Google search of the day 2008-02-15 19:05 ` maht @ 2008-02-15 20:11 ` Eris Discordia 2008-02-15 20:18 ` Pietro Gagliardi 2008-02-15 20:49 ` maht 0 siblings, 2 replies; 107+ messages in thread From: Eris Discordia @ 2008-02-15 20:11 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Fri, 15 Feb 2008 19:05:28 -0000, maht <mattmobile@proweb.co.uk> wrote: > Forth doesn't use CALL it uses JMP > > Similar Threaded Interpretive Languages run an inner loop that does this > pseudo code : > (from Threaded Interpretive Languages: Their Design and Implementation > by R. G. Loeliger) > > COLON: > PSH I -> RS > WA -> I > JMP NEXT > SEMI: > POP RS -> I > NEXT: @I -> WA > I += 2 > RUN: @WA -> CA > WA += 2 > CA -> PC > I know nothing about interpreted/interpretive languages but the above pseudo-code is, to my own surprise, quite readable to me. The "indirection pointer" seems to funcionally match the (stack) base pointer on x86, with the word address equalling the stack pointer. So, the above says: - Save the stack base address (PSH is PUSH, I assume). - Set the stack base address to the beginning of the current frame. - Jump to NEXT. - Put the return address on top of the stack. - Reserve space on the stack for one 16-bit (2-byte) address by incerementing the base pointer. On x86 one would decrement the base because the stack grows from higher addresses towards 0x0. - Set the the call address to the beginning of the procedure. - Set the program counter to the procedure ("call" it, in other words). One strange thing is that code and (stack) data seem to both grow from 0x0 towards 0xFFFF unlike x86 where the code sits in low address and the stack grows downwards. You have re-implemented the calling mechanism. You still have a call stack and the pertaining problems, but you have lost the convenience of a simple call instruction. By the way, now I see what Erik Quanstrom meant by "alternative" calling conventions. Your pseudo-code is an example. > that's all very well but you then extend the assembler parts with new > words made from the WAs (colon is the type marker for this) SEMI is > where it JMPs to at the end > > moddiv: > colon > divmod > swop > semi I am genuinely lost, do not understand a word of it. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Google search of the day 2008-02-15 20:11 ` Eris Discordia @ 2008-02-15 20:18 ` Pietro Gagliardi 2008-02-15 20:49 ` maht 1 sibling, 0 replies; 107+ messages in thread From: Pietro Gagliardi @ 2008-02-15 20:18 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Let's get back to humor. Here's from ReactOS 0.3.4's shutdown screen: The End ..... Try the sequel, hit the reset button right now! You can switch off your computer now ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Google search of the day 2008-02-15 20:11 ` Eris Discordia 2008-02-15 20:18 ` Pietro Gagliardi @ 2008-02-15 20:49 ` maht 2008-02-16 23:32 ` Eris Discordia 1 sibling, 1 reply; 107+ messages in thread From: maht @ 2008-02-15 20:49 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs I think the stack direction is just for the pseudocode, the stack in my implementation grew down, it depends on what assembler primitives are available I guess >> >> >> moddiv: >> colon >> divmod >> swop >> semi > > I am genuinely lost, do not understand a word of it. colon tells the inner loop that this is a set of other Words (addresses) not machine instructions so the loop will execute divmod (which does division with modulous and leave the divsor, mod on the stack) swop then reverses the order of the top two stack items semi then jumps to semi to pop the next I before jumping to it It gives you an interactive compiler without linking as you can add new Words at runtime :square dup * would put square : colon dup multiply semi somewhere in memory (called the dictionary) My version uses two stacks, one for args and one for addresses for more analysis I suggest some online reading, I'm not deep enough into either paradigm to offer suitable insights ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Google search of the day 2008-02-15 20:49 ` maht @ 2008-02-16 23:32 ` Eris Discordia 0 siblings, 0 replies; 107+ messages in thread From: Eris Discordia @ 2008-02-16 23:32 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Fri, 15 Feb 2008 20:49:06 -0000, maht <mattmobile@proweb.co.uk> wrote: > for more analysis I suggest some online reading, I'm not deep enough > into either paradigm to offer suitable insights > Wisely said. I really have to read a lot before I understand the ideas you described. Only if the Finsler geometry course allows me ;-) -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ^ permalink raw reply [flat|nested] 107+ messages in thread
* [9fans] Non-stack-based calling conventions 2008-02-15 17:39 ` Eris Discordia 2008-02-15 19:05 ` maht @ 2008-02-15 23:37 ` Lyndon Nerenberg 2008-02-15 23:39 ` Pietro Gagliardi 1 sibling, 1 reply; 107+ messages in thread From: Lyndon Nerenberg @ 2008-02-15 23:37 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > > The calling conventions I have seen are the ccall, stdcall (Windows' > slightly modified version of the ccall), and pascal. All of them > push parameters on the stack. Take a look at the R-call and S-call conventions used on the IBM System 360 architecture. These machines didn't even have a stack. --lyndon ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-15 23:37 ` [9fans] Non-stack-based calling conventions Lyndon Nerenberg @ 2008-02-15 23:39 ` Pietro Gagliardi 2008-02-15 23:47 ` Paweł Lasek 0 siblings, 1 reply; 107+ messages in thread From: Pietro Gagliardi @ 2008-02-15 23:39 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs - DOS interrupt function calls use the registers, not the stack. - SPARC and MIPS registers are provided to pass parameters. On Feb 15, 2008, at 6:37 PM, Lyndon Nerenberg wrote: >> >> The calling conventions I have seen are the ccall, stdcall >> (Windows' slightly modified version of the ccall), and pascal. All >> of them push parameters on the stack. > > Take a look at the R-call and S-call conventions used on the IBM > System 360 architecture. These machines didn't even have a stack. > > --lyndon ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-15 23:39 ` Pietro Gagliardi @ 2008-02-15 23:47 ` Paweł Lasek 2008-02-16 0:23 ` Brantley Coile ` (2 more replies) 0 siblings, 3 replies; 107+ messages in thread From: Paweł Lasek @ 2008-02-15 23:47 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs I don't have latest version of fascicle one (MMIX processor architecture and MMIXAL assembler language, from new version of The Art of Computer Programming) at hand, so I can't confirm it, but I remember that MMIX had a special register which implemented a "border", shifting register numbers to use them for procedure data separation. And as in all RISC architectures, storing as many parameters in the call stack is the way to go. Especially when you have 256 64-bit general purpose registers :-) (Now if only someone implemented a sane architecture using MMIX as main processor...) On 2/16/08, Pietro Gagliardi <pietro10@mac.com> wrote: > - DOS interrupt function calls use the registers, not the stack. > - SPARC and MIPS registers are provided to pass parameters. > > On Feb 15, 2008, at 6:37 PM, Lyndon Nerenberg wrote: > > >> > >> The calling conventions I have seen are the ccall, stdcall > >> (Windows' slightly modified version of the ccall), and pascal. All > >> of them push parameters on the stack. > > > > Take a look at the R-call and S-call conventions used on the IBM > > System 360 architecture. These machines didn't even have a stack. > > > > --lyndon > > -- Paul Lasek ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-15 23:47 ` Paweł Lasek @ 2008-02-16 0:23 ` Brantley Coile 2008-02-16 23:32 ` Eris Discordia 2008-02-22 10:01 ` Douglas A. Gwyn 2008-02-16 8:29 ` Lluís Batlle 2008-02-26 21:30 ` Paweł Lasek 2 siblings, 2 replies; 107+ messages in thread From: Brantley Coile @ 2008-02-16 0:23 UTC (permalink / raw) To: 9fans Early Control Data machines, like many machines of the era, used the return address to fine the parameters. This meant that you put he parameters in the instruction stream right after the call to the subroutine. Here's the calling convention for your entertainment. 1) The calling program would put the parameters into memory locations just past the call to the subroutine. 2) Do a return-jump to the subroutine. This puts the return address in the first word of the subroutine and begins to execute the second word. 3) Parameters are accessed by using and incrementing the return address. 4) With the return address now safely stored in the first word of the subroutine, we can now return to the calling routine just by doing a indirect jump thru the first word of the routine. All this might not make sense to you so here is some code. This is CDC 1830 assembler, the best I can remember it. CDC 6600 works the same, but the code would be more confusing to the unfamiliar. . . * call sub(p1, p2) ena parm1 put the parameter into the A register sta p1 save it in the instruction stream right after the rtj ena parm2 we have two parameters. sta p2 rtj sub save RA at sub, begin executing at sub+1 p1 bss 1 p2 bss 1 jmp error * first address to return to . . . sub bss 1 place to keep the return address ldq sub lda (q) inq 1 point to next parameter lda (q) inq 2 point to last parameter and no error stq sub put parameter back jmp (sub) jmp indirect thru sub--return By convention there we would follow the parameters with a jump to an error handler and have the subroutine increment the RA another time in case the subroutine had no error. The IBM 7094 did a similar trick only it put the return address, or I should say the 2's complement of it, in an index register before it jumped to the subroutine. Parameters were picked up using the index register. (7094 indexes seem strange to us now, but they were *subtracted* from the base address in the instruction.) The subroutine used a form of the transfer instruction that added the number of words to the return address, er, I mean subtracted, to return to the caller. All the memory you would need was known as compile time. Writing assembler meant watching for trying to execute parameters as instructions. This does wonders for the design of the instruction cache. :) ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-16 0:23 ` Brantley Coile @ 2008-02-16 23:32 ` Eris Discordia 2008-02-16 23:41 ` Pietro Gagliardi ` (2 more replies) 2008-02-22 10:01 ` Douglas A. Gwyn 1 sibling, 3 replies; 107+ messages in thread From: Eris Discordia @ 2008-02-16 23:32 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Fri, 15 Feb 2008 23:39:40 -0000, Pietro Gagliardi <pietro10@mac.com> wrote: > - DOS interrupt function calls use the registers, not the stack. > - SPARC and MIPS registers are provided to pass parameters. > > On Feb 15, 2008, at 6:37 PM, Lyndon Nerenberg wrote: > >>> >>> The calling conventions I have seen are the ccall, stdcall (Windows' >>> slightly modified version of the ccall), and pascal. All of them push >>> parameters on the stack. >> >> Take a look at the R-call and S-call conventions used on the IBM System >> 360 architecture. These machines didn't even have a stack. >> >> --lyndon > Good pieces of info. By the way, MS-DOS software interrupts were interrupts after all, i. e. different from procedure calls. Using the stack there would create re-entry problems (?) and a serious performance bottleneck (heh, MS-DOS to performance is Pumpkins to what?). On Sat, 16 Feb 2008 00:23:22 -0000, Brantley Coile <brantley@coraid.com> wrote: > Early Control Data machines, like many machines > of the era, used the return address to fine the parameters. > This meant that you put he parameters in the instruction > stream right after the call to the subroutine. > > Here's the calling convention for your entertainment. > > 1) The calling program would put the parameters into memory > locations just past the call to the subroutine. > 2) Do a return-jump to the subroutine. This puts the return > address in the first word of the subroutine and > begins to execute the second word. > 3) Parameters are accessed by using and incrementing the > return address. > 4) With the return address now safely stored in the first > word of the subroutine, we can now return to the > calling routine just by doing a indirect jump thru > the first word of the routine. > All this might not make sense to you so here is some code. In fact, your explanation made much more sense than the code. To me, of course. The question of why would anyone devise such a weird scheme of calling procedures remains. > All the memory you would need was known as compile time. At the cost of transforming relocation into black magic. Were there binaries on that platform? Did those binaries need relocation? With code and data intermingled, there must have also been serious problems with minimizing binary sizes. All the "empty" words at the beginning of each subroutine had to be written to permanent storage, I guess. The x86 stack consumes zero space on permanent storage. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-16 23:32 ` Eris Discordia @ 2008-02-16 23:41 ` Pietro Gagliardi 2008-02-16 23:49 ` Brantley Coile 2008-02-17 0:04 ` Brantley Coile 2 siblings, 0 replies; 107+ messages in thread From: Pietro Gagliardi @ 2008-02-16 23:41 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 486 bytes --] On Feb 16, 2008, at 6:32 PM, Eris Discordia wrote: > Using the stack there would create re-entry problems Under very specific conditions you can do PUSH Param1 PUSH Param2 PUSH Param3 INT 80h What are those conditions? - Pascal calling convention - You save the registers before PUSHing the first argument For now, my OS does this as a temporary method of avoiding the necessity of managing different numbers of registers. This will change in due time! [-- Attachment #2: Type: text/html, Size: 1720 bytes --] ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-16 23:32 ` Eris Discordia 2008-02-16 23:41 ` Pietro Gagliardi @ 2008-02-16 23:49 ` Brantley Coile 2008-02-17 0:04 ` Brantley Coile 2 siblings, 0 replies; 107+ messages in thread From: Brantley Coile @ 2008-02-16 23:49 UTC (permalink / raw) To: 9fans >> Early Control Data machines, like many machines >> of the era, used the return address to fine the parameters. >> This meant that you put he parameters in the instruction >> stream right after the call to the subroutine. >> >> Here's the calling convention for your entertainment. >> >> 1) The calling program would put the parameters into memory >> locations just past the call to the subroutine. >> 2) Do a return-jump to the subroutine. This puts the return >> address in the first word of the subroutine and >> begins to execute the second word. >> 3) Parameters are accessed by using and incrementing the >> return address. >> 4) With the return address now safely stored in the first >> word of the subroutine, we can now return to the >> calling routine just by doing a indirect jump thru >> the first word of the routine. >> All this might not make sense to you so here is some code. > > In fact, your explanation made much more sense than the code. To me, of > course. The question of why would anyone devise such a weird scheme of > calling procedures remains. This was the dawn of computer time, and the machines had few registers. The basic Wheeler Jump on the EDSAC, the first operational stored program computer, consisted of loading the address of the parameters following the jump into the accumulator before jumping to the subroutine. With so few registers, it is natural to use the return address to get at both the parameters and figure out where to return. In other words, this is what we did before we figured out a better way. Don't ask about index registers. (add 1 to the instruction and execute it.) ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-16 23:32 ` Eris Discordia 2008-02-16 23:41 ` Pietro Gagliardi 2008-02-16 23:49 ` Brantley Coile @ 2008-02-17 0:04 ` Brantley Coile 2008-02-17 13:30 ` Eris Discordia 2008-02-22 10:01 ` Douglas A. Gwyn 2 siblings, 2 replies; 107+ messages in thread From: Brantley Coile @ 2008-02-17 0:04 UTC (permalink / raw) To: 9fans >> All the memory you would need was known as compile time. > > At the cost of transforming relocation into black magic. Were there > binaries on that platform? Did those binaries need relocation? With code > and data intermingled, there must have also been serious problems with > minimizing binary sizes. All the "empty" words at the beginning of each > subroutine had to be written to permanent storage, I guess. The x86 stack > consumes zero space on permanent storage. The relocation formats for the 6600 assembler wasn't that complicated, much less than coff. For the Cyber 17/18 the instructions could be pc relative and didn't have to be relocated when linked together, at least not for the call/return scenario. The 6600 had a field address that was added to the program counter to relocate the program. It also had a field length register to make sure you didn't spill off the end. All was much simpler than today. ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-17 0:04 ` Brantley Coile @ 2008-02-17 13:30 ` Eris Discordia 2008-02-17 15:04 ` erik quanstrom ` (2 more replies) 2008-02-22 10:01 ` Douglas A. Gwyn 1 sibling, 3 replies; 107+ messages in thread From: Eris Discordia @ 2008-02-17 13:30 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Sun, 17 Feb 2008 00:04:31 -0000, Brantley Coile <brantley@coraid.com> wrote: > The relocation formats for the 6600 assembler wasn't that complicated, > much less than coff. For the Cyber 17/18 the instructions could > be pc relative and didn't have to be relocated when linked together, > at least not for the call/return scenario. I remember the necessity of relocation was not limited to where you had to link binaries. On the 80286 + MS-DOS combination, lack of virtual memory hardware (the "real" mode) made relocation inevitable as processes were not isolated and memory was not multiplexed by the hardware and/or OS. Without a flat and isolated address space for each process, every executable had to adjust to where it was being loaded. Hence, the EXE header and relocation table. COFF has had to cope with a certain monster dubbed portability; to adapt to the peculiarities of the many flavors of UNIX (and at least one Microsoft OS, with MS-COFF). So good it has been practically put out of business by ELF or... do Plan 9 compilers output COFF object files? > The 6600 had a field address that was added to the program counter > to relocate the program. It also had a field length register to > make sure you didn't spill off the end. No far jumps/calls? Was the memory model not segmented? > All was much simpler than today. I am actually very grateful for having a flat 32/64 bit address space all to myself. Even though the curse of managing virtual memory and driving the associated hardware has been placed on every OS developer, occasional programmers like me really enjoy the outcome. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-17 13:30 ` Eris Discordia @ 2008-02-17 15:04 ` erik quanstrom 2008-02-17 21:43 ` Uriel 2008-02-17 16:08 ` Anthony Sorace 2008-02-22 10:01 ` Douglas A. Gwyn 2 siblings, 1 reply; 107+ messages in thread From: erik quanstrom @ 2008-02-17 15:04 UTC (permalink / raw) To: 9fans > COFF has had to cope with a certain monster dubbed portability; to adapt > to the peculiarities of the many flavors of UNIX (and at least one > Microsoft OS, with MS-COFF). So good it has been practically put out of > business by ELF or... do Plan 9 compilers output COFF object files? see a.out(6). > COFF has had to cope with a certain monster dubbed portability; to adapt > to the peculiarities of the many flavors of UNIX (and at least one > Microsoft OS, with MS-COFF). So good it has been practically put out of > business by ELF or... do Plan 9 compilers output COFF object files? flat memory model: http://en.wikipedia.org/wiki/CDC_6600#Memory_organization > I am actually very grateful for having a flat 32/64 bit address space all > to myself. Even though the curse of managing virtual memory and driving > the associated hardware has been placed on every OS developer, occasional > programmers like me really enjoy the outcome. it's interesting to note that it is being loaded at a constant address makes the job of loading & generating the code much simplier. the location of allocated memory isn't as important --- those details can often be hidden in an malloc-style function. even on 386 hardware, segments can be used to cover all of memory. as long as your allocator knows where not to step (pci space, for example), this should be good enough. so if you're running without the operating system or your application is the operating system (embedded systems), virtual memory might just get in the way. tlb hardware doesn't do its translation for free. - erik ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-17 15:04 ` erik quanstrom @ 2008-02-17 21:43 ` Uriel 2008-02-17 23:58 ` erik quanstrom 0 siblings, 1 reply; 107+ messages in thread From: Uriel @ 2008-02-17 21:43 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > so if you're running without the operating system or your application > is the operating system (embedded systems), virtual memory might > just get in the way. tlb hardware doesn't do its translation for free. Or if you have moved onto the greener pastures of Limbo... not having to worry about all this saves many headaches when you want to port Inferno to a new arch too. uriel ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-17 21:43 ` Uriel @ 2008-02-17 23:58 ` erik quanstrom 2008-02-18 1:54 ` Bruce Ellis 2008-02-18 4:44 ` Pietro Gagliardi 0 siblings, 2 replies; 107+ messages in thread From: erik quanstrom @ 2008-02-17 23:58 UTC (permalink / raw) To: 9fans >> so if you're running without the operating system or your application >> is the operating system (embedded systems), virtual memory might >> just get in the way. tlb hardware doesn't do its translation for free. > > Or if you have moved onto the greener pastures of Limbo... not having > to worry about all this saves many headaches when you want to port > Inferno to a new arch too. > > uriel the world isn't this simple. just cause you've got the limbo hammer, doesn't mean all the world's a nail. porting limbo to a new architecture requires porting ken's toolchain and the inferno kernel. i don't see how a self-containted operating system/ application would be less work to port. if the work you're doing is performance-sensitive enough that tlb misses make a difference, then you certainly do not want to pay the penalty of a virtual machine. further, if the work you're doing is in the kernel or kernel-level, unless you have hardware implemting dis, you can't write this in a language like limbo which targets a virtual machine. - erik ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-17 23:58 ` erik quanstrom @ 2008-02-18 1:54 ` Bruce Ellis 2008-02-18 3:43 ` erik quanstrom 2008-02-18 6:22 ` Robert William Fuller 2008-02-18 4:44 ` Pietro Gagliardi 1 sibling, 2 replies; 107+ messages in thread From: Bruce Ellis @ 2008-02-18 1:54 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs how did this get past my erik filter? wrong, wrong, wrong, wrong. four out of four as expected. brucee On Feb 18, 2008 10:58 AM, erik quanstrom <quanstro@quanstro.net> wrote: > >> so if you're running without the operating system or your application > >> is the operating system (embedded systems), virtual memory might > >> just get in the way. tlb hardware doesn't do its translation for free. > > > > Or if you have moved onto the greener pastures of Limbo... not having > > to worry about all this saves many headaches when you want to port > > Inferno to a new arch too. > > > > uriel > > the world isn't this simple. just cause you've got the limbo hammer, doesn't > mean all the world's a nail. > > porting limbo to a new architecture requires porting ken's toolchain > and the inferno kernel. i don't see how a self-containted operating system/ > application would be less work to port. > > if the work you're doing is performance-sensitive enough that tlb misses > make a difference, then you certainly do not want to pay the penalty of > a virtual machine. > > further, if the work you're doing is in the kernel or kernel-level, unless you > have hardware implemting dis, you can't write this in a language like limbo > which targets a virtual machine. > > - erik > > ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-18 1:54 ` Bruce Ellis @ 2008-02-18 3:43 ` erik quanstrom 2008-02-18 4:31 ` Bruce Ellis 2008-02-18 6:22 ` Robert William Fuller 1 sibling, 1 reply; 107+ messages in thread From: erik quanstrom @ 2008-02-18 3:43 UTC (permalink / raw) To: 9fans > how did this get past my erik filter? > > wrong, wrong, wrong, wrong. > > four out of four as expected. > > brucee 100% whinage. 0 justification. 0 information. par for the course. ☺ since you disagree, i assume you claim that limbo's the hammer and all computing problems are nails. i'd like to know why limbo's the right thing to run, e.g., on a freescale hc08 microcontroller. i'd also like to know why there is no performance penalty for running dis code over c. do you claim the garbage collection doesn't take any appreciable time? and the there is no overhead dealing with limbo's runtime typechecking? the inferno kernel i know about is written in c. where's the limbo version? how does one run a limbo program on a new architecture without porting the runtime or jit? - erik ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-18 3:43 ` erik quanstrom @ 2008-02-18 4:31 ` Bruce Ellis 2008-02-18 4:40 ` Pietro Gagliardi 0 siblings, 1 reply; 107+ messages in thread From: Bruce Ellis @ 2008-02-18 4:31 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs you've changed your claims! it says elephant! 1) no, limbo is not good for everything. my doorbell is better without it. in the context of the original thread you just dismissed it because you wanted to argue. 2) porting limbo does not require ken's tool chain. have you had experience with this? anything "self-containted" can only blame itself for its blemishes. 3) the performance gain of having a fixed tlb with no context switch penalty is amazing. have you had experience with this? 4) if you are hacking the kernel then you aren't hacking limbo so what is the point of #4. after 41 messages in this thread you'll ask for references. brucee On Feb 18, 2008 2:43 PM, erik quanstrom <quanstro@quanstro.net> wrote: > > how did this get past my erik filter? > > > > wrong, wrong, wrong, wrong. > > > > four out of four as expected. > > > > brucee > > 100% whinage. 0 justification. 0 information. par for the course. ☺ > > since you disagree, i assume you claim that limbo's the hammer and all > computing problems are nails. i'd like to know why limbo's the right > thing to run, e.g., on a freescale hc08 microcontroller. i'd also like to know > why there is no performance penalty for running dis code over c. do > you claim the garbage collection doesn't take any appreciable time? > and the there is no overhead dealing with limbo's runtime typechecking? > the inferno kernel i know about is written in c. where's the limbo version? > how does one run a limbo program on a new architecture without porting > the runtime or jit? > > - erik > > ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-18 4:31 ` Bruce Ellis @ 2008-02-18 4:40 ` Pietro Gagliardi 0 siblings, 0 replies; 107+ messages in thread From: Pietro Gagliardi @ 2008-02-18 4:40 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs New question: can Limbo be compiled to raw binary to run on native hardware? Yes. Will I do it? No. Next question: can C be interpreted like Limbo? Yes. (10th edition Unix has such a program.) Will I do it? No. Someone's ideas on a programming language should not be "forced" onto another's state of mind. I don't like some of the features of Limbo (sys := load Sys Sys->PATH) and I don't think Limbo can be used to write a system kernel without an abundant amount of reductions or compiler hacks (http://www.osdev.org/wiki/C_PlusPlus discusses enough of them for C++ to make one puke). If someone defies those odds, good for them. Also, C can be a pain in the neck at so many times (pointer arithmetic multiplies the difficulty of porting Assembly to C). C can be made to type-check at runtime, but will I do it to C itself? Not when I'm porting about 30 Assembly files to C. I fear I've fallen victim to the complications of Duff's device and the alt construct, so I'll stop. Flame extinguished. On Feb 17, 2008, at 11:31 PM, Bruce Ellis wrote: > you've changed your claims! > > it says elephant! > > 1) no, limbo is not good for everything. my doorbell is better > without it. > in the context of the original thread you just dismissed it because > you wanted to argue. > > 2) porting limbo does not require ken's tool chain. have you had > experience with this? anything "self-containted" can only blame > itself for its blemishes. > > 3) the performance gain of having a fixed tlb with no context switch > penalty is amazing. have you had experience with this? > > 4) if you are hacking the kernel then you aren't hacking limbo so > what is the point of #4. > > after 41 messages in this thread you'll ask for references. > > brucee > > On Feb 18, 2008 2:43 PM, erik quanstrom <quanstro@quanstro.net> wrote: >>> how did this get past my erik filter? >>> >>> wrong, wrong, wrong, wrong. >>> >>> four out of four as expected. >>> >>> brucee >> >> 100% whinage. 0 justification. 0 information. par for the >> course. ☺ >> >> since you disagree, i assume you claim that limbo's the hammer and >> all >> computing problems are nails. i'd like to know why limbo's the right >> thing to run, e.g., on a freescale hc08 microcontroller. i'd also >> like to know >> why there is no performance penalty for running dis code over c. do >> you claim the garbage collection doesn't take any appreciable time? >> and the there is no overhead dealing with limbo's runtime >> typechecking? >> the inferno kernel i know about is written in c. where's the >> limbo version? >> how does one run a limbo program on a new architecture without >> porting >> the runtime or jit? >> >> - erik >> >> ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-18 1:54 ` Bruce Ellis 2008-02-18 3:43 ` erik quanstrom @ 2008-02-18 6:22 ` Robert William Fuller 2008-02-18 7:23 ` Bruce Ellis ` (3 more replies) 1 sibling, 4 replies; 107+ messages in thread From: Robert William Fuller @ 2008-02-18 6:22 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Bruce Ellis wrote: > how did this get past my erik filter? > > wrong, wrong, wrong, wrong. > > four out of four as expected. Erik, Don't let the bastards get you down. Believe me when I say you're not the only one who would vote Bruce off the list if it were an option. The number one barrier to the advancement of Plan9 is some of the louder, more unsavory personalities surrounding the project. 9fans seems to be frequented by more than a few jealous, wanna-be Linus's. They are the project's greatest liability. Regards, Rob ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-18 6:22 ` Robert William Fuller @ 2008-02-18 7:23 ` Bruce Ellis 2008-02-18 8:38 ` Anant Narayanan 2008-02-18 8:30 ` Anant Narayanan ` (2 subsequent siblings) 3 siblings, 1 reply; 107+ messages in thread From: Bruce Ellis @ 2008-02-18 7:23 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs No, the number one barrier is those who answer nearly every thread - with misinformation, usually along the lines of "I don't know what I'm talking about but I'll post anyway". I rarely post and filter me out if you like. To answer Pietro ... Yes, Dis to assembly is common. That's what the JITs are - they are fun and instructive to write. Yes, there was a good C interpreter back in 10th edition days. I was one of the authors. It is still on my micro-vax. To answer Uriel ... I believe shand may have a copy of boyd's stuff. As for Linus, I'm sure he's a nice guy. I'm quite happy with my own life thanks. brucee On Feb 18, 2008 5:22 PM, Robert William Fuller <hydrologiccycle@gmail.com> wrote: > Bruce Ellis wrote: > > how did this get past my erik filter? > > > > wrong, wrong, wrong, wrong. > > > > four out of four as expected. > > Erik, > > Don't let the bastards get you down. Believe me when I say you're not > the only one who would vote Bruce off the list if it were an option. > > The number one barrier to the advancement of Plan9 is some of the > louder, more unsavory personalities surrounding the project. 9fans > seems to be frequented by more than a few jealous, wanna-be Linus's. > They are the project's greatest liability. > > Regards, > > Rob > ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-18 7:23 ` Bruce Ellis @ 2008-02-18 8:38 ` Anant Narayanan 2008-02-22 10:02 ` Douglas A. Gwyn 0 siblings, 1 reply; 107+ messages in thread From: Anant Narayanan @ 2008-02-18 8:38 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Just as an observation (may not be related to the thread), all the executable file formats that Linux currently supports, have page- aligned sections in the file! (Now I know why hexdump always shows me a bunch of zeros in-between). That means, all the loader really does is mmap the sections into the right memory locations. What next, maybe also put in the BSS in the file so you wouldn't have to allocate that either ;) Hence, writing the loader for Plan 9's a.out proved to be a challenge. I ended up writing a user-space program that padded out the required gap between TEXT and DATA before asking the kernel to execute it. Suboptimal, but it works. If anyone has any ideas as to how I can improve the situation, i'll be grateful. Thanks, Anant ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-18 8:38 ` Anant Narayanan @ 2008-02-22 10:02 ` Douglas A. Gwyn 2008-02-22 19:35 ` Anant Narayanan 0 siblings, 1 reply; 107+ messages in thread From: Douglas A. Gwyn @ 2008-02-22 10:02 UTC (permalink / raw) To: 9fans Anant Narayanan wrote: > Just as an observation (may not be related to the thread), all the > executable file formats that Linux currently supports, have page- > aligned sections in the file! ... > That means, all the loader really does is mmap the sections into the > right memory locations. What next, maybe also put in the BSS in the > file so you wouldn't have to allocate that either ;) Ssh, somebody may hear you and decide to do it. Conceptually it's not a bad idea, in environments where you can spare the wasted space. As I recall, using the VM system to map files in Unix goes back to 4BSD; we used to page-align buffer addresses in order to get the kernel to perform faster data transfers. > Hence, writing the loader for Plan 9's a.out proved to be a challenge. > I ended up writing a user-space program that padded out the required > gap between TEXT and DATA before asking the kernel to execute it. > Suboptimal, but it works. > If anyone has any ideas as to how I can improve the situation, i'll be > grateful. I don't understand what good it does to map Plan 9 object code into Linux files. Is there a Linux filetype for Plan 9 that invokes a system-call interpreter, or what? ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-22 10:02 ` Douglas A. Gwyn @ 2008-02-22 19:35 ` Anant Narayanan 0 siblings, 0 replies; 107+ messages in thread From: Anant Narayanan @ 2008-02-22 19:35 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On 22-Feb-08, at 3:32 PM, Douglas A. Gwyn wrote: > I don't understand what good it does to map Plan 9 object code > into Linux files. Is there a Linux filetype for Plan 9 that > invokes a system-call interpreter, or what? No, I just write a handler for interrupt 0x64 that calls either an existing linux syscall (it works for some of them) or a custom in- kernel routine (for the more 'exotic' plan 9 syscalls). Yes, the project is currently aimed at x86 only. -- Anant ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-18 6:22 ` Robert William Fuller 2008-02-18 7:23 ` Bruce Ellis @ 2008-02-18 8:30 ` Anant Narayanan 2008-02-18 8:44 ` Bruce Ellis 2008-02-18 18:50 ` Federico G. Benavento 2008-02-18 22:13 ` LiteStar numnums 3 siblings, 1 reply; 107+ messages in thread From: Anant Narayanan @ 2008-02-18 8:30 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > Don't let the bastards get you down. Believe me when I say you're > not the only one who would vote Bruce off the list if it were an > option. Wow, that makes two of you. Real Impressive. -- Anant ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-18 8:30 ` Anant Narayanan @ 2008-02-18 8:44 ` Bruce Ellis 0 siblings, 0 replies; 107+ messages in thread From: Bruce Ellis @ 2008-02-18 8:44 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs grep impressed /sys/games/lib/fortunes On Feb 18, 2008 7:30 PM, Anant Narayanan <anant@kix.in> wrote: > > Don't let the bastards get you down. Believe me when I say you're > > not the only one who would vote Bruce off the list if it were an > > option. > > Wow, that makes two of you. Real Impressive. > > -- > Anant > ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-18 6:22 ` Robert William Fuller 2008-02-18 7:23 ` Bruce Ellis 2008-02-18 8:30 ` Anant Narayanan @ 2008-02-18 18:50 ` Federico G. Benavento 2008-02-18 21:53 ` Lorenzo Fernando Bivens de la Fuente ` (3 more replies) 2008-02-18 22:13 ` LiteStar numnums 3 siblings, 4 replies; 107+ messages in thread From: Federico G. Benavento @ 2008-02-18 18:50 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs hola, > Don't let the bastards get you down. Believe me when I say you're not > the only one who would vote Bruce off the list if it were an option. > really? I don't even know bruce, but his posts are one of the things that make this list worth reading. > The number one barrier to the advancement of Plan9 is some of the > louder, more unsavory personalities surrounding the project. 9fans > seems to be frequented by more than a few jealous, wanna-be Linus's. > They are the project's greatest liability. wtf is linus? I _had_ to be some wannabe it wouldn't be a linus one, maybe a ken wannabe, but who wants to be a wannabe anyways? -- Federico G. Benavento ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-18 18:50 ` Federico G. Benavento @ 2008-02-18 21:53 ` Lorenzo Fernando Bivens de la Fuente 2008-02-18 22:55 ` y i y u s 2008-02-18 22:14 ` Pietro Gagliardi ` (2 subsequent siblings) 3 siblings, 1 reply; 107+ messages in thread From: Lorenzo Fernando Bivens de la Fuente @ 2008-02-18 21:53 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs This is the best community *ever* Software, hardware, phylosophy, politics, economics... Whatever the discussion is, the best arguments are around this list. It is not perfect, though... But each post, each member, makes it special... (sha-la-la-la-la...) :D On Mon, Feb 18, 2008 at 6:50 PM, Federico G. Benavento <benavento@gmail.com> wrote: > hola, > > > > Don't let the bastards get you down. Believe me when I say you're not > > the only one who would vote Bruce off the list if it were an option. > > > really? I don't even know bruce, but his posts are one of the things that > make this list worth reading. > > > > The number one barrier to the advancement of Plan9 is some of the > > louder, more unsavory personalities surrounding the project. 9fans > > seems to be frequented by more than a few jealous, wanna-be Linus's. > > They are the project's greatest liability. > > wtf is linus? I _had_ to be some wannabe it wouldn't be a linus one, > maybe a ken wannabe, but who wants to be a wannabe anyways? > > -- > Federico G. Benavento > ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-18 21:53 ` Lorenzo Fernando Bivens de la Fuente @ 2008-02-18 22:55 ` y i y u s 2008-02-18 23:46 ` Uriel 0 siblings, 1 reply; 107+ messages in thread From: y i y u s @ 2008-02-18 22:55 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 2008/2/18, Lorenzo Fernando Bivens de la Fuente <lorenzobivens@gmail.com>: > This is the best community *ever* > > Software, hardware, phylosophy, politics, economics... Whatever the > discussion is, the best arguments are around this list. > I agree 100%. As one of the persons subscribed to the list in "read only mode" I have to tell I love it. You are miles ahead of that rtfm catch phrase. When I see a post saying "let's port gcc" I smile thinking "this is going to be funny..." I really learn here, and I love what I call the "uriel/bruce touch" (I have learned now that it is a bit of "boyd touch", but I arrived here a bit too late for that...). I was just waiting to see somebody throwing the first stone to say how I love reading 9fans. keep the good work, -- - yiyus || JGL . ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-18 22:55 ` y i y u s @ 2008-02-18 23:46 ` Uriel 0 siblings, 0 replies; 107+ messages in thread From: Uriel @ 2008-02-18 23:46 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > I agree 100%. As one of the persons subscribed to the list in "read > only mode" I have to tell I love it. You are miles ahead of that rtfm > catch phrase. When I see a post saying "let's port gcc" I smile > thinking "this is going to be funny..." I really learn here, and I > love what I call the "uriel/bruce touch" (I have learned now that it > is a bit of "boyd touch", but I arrived here a bit too late for > that...). You (and everyone) should read the archives, they are pure gold, the quality of the discussion in 9fans has been steadily degenerating over the years... but as fgb pointed out people like brucee still make it worth reading. uriel ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-18 18:50 ` Federico G. Benavento 2008-02-18 21:53 ` Lorenzo Fernando Bivens de la Fuente @ 2008-02-18 22:14 ` Pietro Gagliardi 2008-02-18 22:16 ` Pietro Gagliardi 2008-02-20 11:39 ` maht 2008-02-22 10:02 ` Douglas A. Gwyn 3 siblings, 1 reply; 107+ messages in thread From: Pietro Gagliardi @ 2008-02-18 22:14 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 108 bytes --] On Feb 18, 2008, at 1:50 PM, Federico G. Benavento wrote: > wtf is linus? Vivete sotto una roccia? [-- Attachment #2: Type: text/html, Size: 462 bytes --] ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-18 22:14 ` Pietro Gagliardi @ 2008-02-18 22:16 ` Pietro Gagliardi 2008-02-18 22:32 ` Federico G. Benavento 0 siblings, 1 reply; 107+ messages in thread From: Pietro Gagliardi @ 2008-02-18 22:16 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 213 bytes --] Sorry, intended that to be private. On Feb 18, 2008, at 5:14 PM, Pietro Gagliardi wrote: > On Feb 18, 2008, at 1:50 PM, Federico G. Benavento wrote: > >> wtf is linus? > > Vivete sotto una roccia? > [-- Attachment #2: Type: text/html, Size: 714 bytes --] ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-18 22:16 ` Pietro Gagliardi @ 2008-02-18 22:32 ` Federico G. Benavento 0 siblings, 0 replies; 107+ messages in thread From: Federico G. Benavento @ 2008-02-18 22:32 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > Vivete sotto una roccia? I'm glad I took a latin semester, it helps to decode latin derived languages. -- Federico G. Benavento ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-18 18:50 ` Federico G. Benavento 2008-02-18 21:53 ` Lorenzo Fernando Bivens de la Fuente 2008-02-18 22:14 ` Pietro Gagliardi @ 2008-02-20 11:39 ` maht 2008-02-20 17:19 ` Bruce Ellis 2008-02-22 10:02 ` Douglas A. Gwyn 2008-02-22 10:02 ` Douglas A. Gwyn 3 siblings, 2 replies; 107+ messages in thread From: maht @ 2008-02-20 11:39 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs I'll preceed my invective with something relevant : Forth's calling convention means the stack is used less for nested calls. For the C version there's all sorts of pushing and popping return addresses and arguments on to the stack float sqr(x float) { return x * x; } float hyp(x float, y float) { return sqrt(sqr(x) + sqr(y)); } Whereas in the Forth version, the only thing that gets pushed and popped is the address of the next function, the arguments are on the stack already (assume the FP versions of the Words are used) : :sqr dup * :hyp sqr over sqr + sqrt Now on with the invective lolz, I go away for 3 days and I must have left the back door open because when I came back the place was full of ignorant bitches. I like both of these : grep impressive /sys/games/lib/fortune I'm glad that the "problem" of Plan 9 has been solved at last, it's the people who have been using it for n years. My personal n started on June 7 2000, I guess that day is akin to "the September that Never Ended" to those for whom n > 7. ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-20 11:39 ` maht @ 2008-02-20 17:19 ` Bruce Ellis 2008-02-22 10:02 ` Douglas A. Gwyn 1 sibling, 0 replies; 107+ messages in thread From: Bruce Ellis @ 2008-02-20 17:19 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs http://www.videojug.com/film/how-to-behave-on-an-internet-forum On Feb 20, 2008 10:39 PM, maht <mattmobile@proweb.co.uk> wrote: > ... > > lolz, I go away for 3 days and I must have left the back door open > because when I came back the place was full of ignorant bitches. > > ... ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-20 11:39 ` maht 2008-02-20 17:19 ` Bruce Ellis @ 2008-02-22 10:02 ` Douglas A. Gwyn 1 sibling, 0 replies; 107+ messages in thread From: Douglas A. Gwyn @ 2008-02-22 10:02 UTC (permalink / raw) To: 9fans maht wrote: > For the C version there's all sorts of pushing and popping return > addresses and arguments on to the stack > float > sqr(x float) > { > return x * x; > } > float > hyp(x float, y float) > { > return sqrt(sqr(x) + sqr(y)); > } [Assuming that the code is corrected and the types made compatible with the argument to sqrt.] The extra overhead occurs only because of the support for full recursion, with private instance data. Many C compilers dating back to around 1980 will in-line the calls to sqr, so the effect is: hyp: mul r2,r2,r2 mul r3,r3,r3 add r2,r3,r2 jmp sqrt It's hard to imagine anything more efficient (except when hyp itself can be in-lined.) Details of course depend on the machine architecture and linkage convention; the above is modeled loosely after the M*CORE, which is very nice in this respect. ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-18 18:50 ` Federico G. Benavento ` (2 preceding siblings ...) 2008-02-20 11:39 ` maht @ 2008-02-22 10:02 ` Douglas A. Gwyn 3 siblings, 0 replies; 107+ messages in thread From: Douglas A. Gwyn @ 2008-02-22 10:02 UTC (permalink / raw) To: 9fans "Federico G. Benavento" wrote: > ... but who wants to be a wannabe anyways? Maybe a has-been wannabe has wanted to be? ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-18 6:22 ` Robert William Fuller ` (2 preceding siblings ...) 2008-02-18 18:50 ` Federico G. Benavento @ 2008-02-18 22:13 ` LiteStar numnums 3 siblings, 0 replies; 107+ messages in thread From: LiteStar numnums @ 2008-02-18 22:13 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 1846 bytes --] Hullo, Athens voted to give Socrates a farewell toast; it wasn't particularly useful to anyone involved. brucee might've been acerbic, but you risk having your statements answered acerbically on teh interwebs & off. I, for one, enjoy reading almost 100% of what's posted to 9fans, and of the few times that I have written brucee, all have been met with the same courteous, if terse, style. I'd hate to lose anyone who posts to 9fans, not the least of whom would be Erik nor brucee. Cheers, -- LS On Feb 18, 2008 1:22 AM, Robert William Fuller <hydrologiccycle@gmail.com> wrote: > Bruce Ellis wrote: > > how did this get past my erik filter? > > > > wrong, wrong, wrong, wrong. > > > > four out of four as expected. > > Erik, > > Don't let the bastards get you down. Believe me when I say you're not > the only one who would vote Bruce off the list if it were an option. > > The number one barrier to the advancement of Plan9 is some of the > louder, more unsavory personalities surrounding the project. 9fans > seems to be frequented by more than a few jealous, wanna-be Linus's. > They are the project's greatest liability. > > Regards, > > Rob > -- "By cosmic rule, as day yields night, so winter summer, war peace, plenty famine. All things change. Air penetrates the lump of myrrh, until the joining bodies die and rise again in smoke called incense." "Men do not know how that which is drawn in different directions harmonises with itself. The harmonious structure of the world depends upon opposite tension like that of the bow and the lyre." "This universe, which is the same for all, has not been made by any god or man, but it always has been, is, and will be an ever-living fire, kindling itself by regular measures and going out by regular measures" -- Heraclitus [-- Attachment #2: Type: text/html, Size: 2275 bytes --] ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-17 23:58 ` erik quanstrom 2008-02-18 1:54 ` Bruce Ellis @ 2008-02-18 4:44 ` Pietro Gagliardi 2008-02-18 4:46 ` Pietro Gagliardi 1 sibling, 1 reply; 107+ messages in thread From: Pietro Gagliardi @ 2008-02-18 4:44 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 271 bytes --] One more thing: On Feb 17, 2008, at 6:58 PM, erik quanstrom wrote: > porting limbo to a new architecture requires porting ken's toolchain > and the inferno kernel. /n/sources/contrib/pietro/limbo.tgz The only thing ported was the source code and mkfiles. [-- Attachment #2: Type: text/html, Size: 929 bytes --] ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-18 4:44 ` Pietro Gagliardi @ 2008-02-18 4:46 ` Pietro Gagliardi 2008-02-18 5:03 ` Uriel 0 siblings, 1 reply; 107+ messages in thread From: Pietro Gagliardi @ 2008-02-18 4:46 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 569 bytes --] And if you're going to rebut and say that limbo needs dis, then check this out: /n/sources/contrib/andrey/dis.tar.gz (or something) Also works with the Plan 9 toolchain, but you may need to change some files now. On Feb 17, 2008, at 11:44 PM, Pietro Gagliardi wrote: > One more thing: > > On Feb 17, 2008, at 6:58 PM, erik quanstrom wrote: > >> porting limbo to a new architecture requires porting ken's toolchain >> and the inferno kernel. > > /n/sources/contrib/pietro/limbo.tgz > > The only thing ported was the source code and mkfiles. > [-- Attachment #2: Type: text/html, Size: 1521 bytes --] ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-18 4:46 ` Pietro Gagliardi @ 2008-02-18 5:03 ` Uriel 0 siblings, 0 replies; 107+ messages in thread From: Uriel @ 2008-02-18 5:03 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Time to reach for the 92FS... Dear pietro, if you don't even know that the Plan 9 toolchain *is* ken's toolchain, and your other comments are totally irrelevant, why don't you just shut the fuck up? And this obviously doesn't mean erik was right, brucee as usual hit every nail straight in the head. uriel - trying to do a boyd On Feb 18, 2008 5:46 AM, Pietro Gagliardi <pietro10@mac.com> wrote: > > And if you're going to rebut and say that limbo needs dis, then check this > out: > > /n/sources/contrib/andrey/dis.tar.gz (or something) > > Also works with the Plan 9 toolchain, but you may need to change some files > now. > > > > On Feb 17, 2008, at 11:44 PM, Pietro Gagliardi wrote: > > One more thing: > > On Feb 17, 2008, at 6:58 PM, erik quanstrom wrote: > > porting limbo to a new architecture requires porting ken's toolchain > and the inferno kernel. > > /n/sources/contrib/pietro/limbo.tgz > > The only thing ported was the source code and mkfiles. > > > ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-17 13:30 ` Eris Discordia 2008-02-17 15:04 ` erik quanstrom @ 2008-02-17 16:08 ` Anthony Sorace 2008-02-17 22:03 ` Charles Forsyth 2008-02-22 10:01 ` Douglas A. Gwyn 2 siblings, 1 reply; 107+ messages in thread From: Anthony Sorace @ 2008-02-17 16:08 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On 2/17/08, Eris Discordia <eris.discordia@gmail.com> wrote: > do Plan 9 compilers output COFF object files? not typically, but some of the linkers can be instructed to. see the -Hn argument in 2l(1). the list of what the linkers can generate isn't documented, but look for HEADTYPE in /sys/src/cmd/[12578kqv]l/obj.c. i haven't had a machine to try the output on in several years, but vl's documented ability to produce IRIX coff executables at least used to work. ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-17 16:08 ` Anthony Sorace @ 2008-02-17 22:03 ` Charles Forsyth 0 siblings, 0 replies; 107+ messages in thread From: Charles Forsyth @ 2008-02-17 22:03 UTC (permalink / raw) To: 9fans >> do Plan 9 compilers output COFF object files? > never. ken thompson's paper tells enough, if not all. ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-17 13:30 ` Eris Discordia 2008-02-17 15:04 ` erik quanstrom 2008-02-17 16:08 ` Anthony Sorace @ 2008-02-22 10:01 ` Douglas A. Gwyn 2008-02-22 14:07 ` Iruata Souza 2 siblings, 1 reply; 107+ messages in thread From: Douglas A. Gwyn @ 2008-02-22 10:01 UTC (permalink / raw) To: 9fans Eris Discordia wrote: > do Plan 9 compilers output COFF object files? No, it has its own format. Actually Plan 9 is interesting in that some of the work traditionally done by the compiler was made the responsibility of the linker. ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-22 10:01 ` Douglas A. Gwyn @ 2008-02-22 14:07 ` Iruata Souza 0 siblings, 0 replies; 107+ messages in thread From: Iruata Souza @ 2008-02-22 14:07 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Fri, Feb 22, 2008 at 7:01 AM, Douglas A. Gwyn <DAGwyn@null.net> wrote: > Eris Discordia wrote: > > do Plan 9 compilers output COFF object files? > > No, it has its own format. Actually Plan 9 is interesting > in that some of the work traditionally done by the compiler > was made the responsibility of the linker. > like douglas said, the linkers will do the job and output COFF for you. iru ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-17 0:04 ` Brantley Coile 2008-02-17 13:30 ` Eris Discordia @ 2008-02-22 10:01 ` Douglas A. Gwyn 1 sibling, 0 replies; 107+ messages in thread From: Douglas A. Gwyn @ 2008-02-22 10:01 UTC (permalink / raw) To: 9fans Brantley Coile wrote: > ... For the Cyber 17/18 the instructions could > be pc relative and didn't have to be relocated when linked together, > at least not for the call/return scenario. Also, the 1700 linking and program loading were done at the same time, the linker had to traverse threaded references and perform relocation on those that needed it. I created a portable implementation of the linker some time ago (the assembler is on hold until my retirement). > All was much simpler than today. Although in a virtual-memory environment no relocation is needed at program load time. ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-16 0:23 ` Brantley Coile 2008-02-16 23:32 ` Eris Discordia @ 2008-02-22 10:01 ` Douglas A. Gwyn 1 sibling, 0 replies; 107+ messages in thread From: Douglas A. Gwyn @ 2008-02-22 10:01 UTC (permalink / raw) To: 9fans Brantley Coile wrote: > Early Control Data machines, like many machines > of the era, used the return address to find the parameters. > This meant that you put he parameters in the instruction > stream right after the call to the subroutine. > ... Yes, a lot of minicomputers did that in those days. Even on the PDP-11, which had nice support for stack operations, some system- call conventions involved embedding parameters in-line. Unix did that too, although at some point an "indirect" call was added to fetch the parameter block from a pointed-to location. If you have and CDC Cyber 18 (or 1700) system software, I am desperate to obtain a copy for use with my 1700 emulation. ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-15 23:47 ` Paweł Lasek 2008-02-16 0:23 ` Brantley Coile @ 2008-02-16 8:29 ` Lluís Batlle 2008-02-17 23:09 ` Chad Dougherty ` (2 more replies) 2008-02-26 21:30 ` Paweł Lasek 2 siblings, 3 replies; 107+ messages in thread From: Lluís Batlle @ 2008-02-16 8:29 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Talking about The Art of Computer Programming... this non-stack based calling convention made me think of Knuth's Coroutines. I'm quite interested on them, but although I've seen libraries for managing them, I've never seen a real useful program based on them. I think they could be used with advantages over the thread or normal function call abstractions. Maybe someone in this list can provide a good example of coroutines use? 2008/2/16, Paweł Lasek <pawel.lasek@gmail.com>: > I don't have latest version of fascicle one (MMIX processor > architecture and MMIXAL assembler language, from new version of The > Art of Computer Programming) at hand, so I can't confirm it, but I > remember that MMIX had a special register which implemented a > "border", shifting register numbers to use them for procedure data > separation. > > And as in all RISC architectures, storing as many parameters in the > call stack is the way to go. Especially when you have 256 64-bit > general purpose registers :-) (Now if only someone implemented a sane > architecture using MMIX as main processor...) > > > On 2/16/08, Pietro Gagliardi <pietro10@mac.com> wrote: > > - DOS interrupt function calls use the registers, not the stack. > > - SPARC and MIPS registers are provided to pass parameters. > > > > On Feb 15, 2008, at 6:37 PM, Lyndon Nerenberg wrote: > > > > >> > > >> The calling conventions I have seen are the ccall, stdcall > > >> (Windows' slightly modified version of the ccall), and pascal. All > > >> of them push parameters on the stack. > > > > > > Take a look at the R-call and S-call conventions used on the IBM > > > System 360 architecture. These machines didn't even have a stack. > > > > > > --lyndon > > > > > > > -- > Paul Lasek > ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-16 8:29 ` Lluís Batlle @ 2008-02-17 23:09 ` Chad Dougherty 2008-02-18 21:50 ` Pietro Gagliardi 2008-02-22 10:02 ` Douglas A. Gwyn 2 siblings, 0 replies; 107+ messages in thread From: Chad Dougherty @ 2008-02-17 23:09 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Lluís Batlle wrote: > Maybe someone in this list can provide a good example of coroutines use? > I found Russ's recent post about Duff's device and the PuTTY coroutine example that it referenced interesting: <http://research.swtch.com/2008/01/on-duffs-device-and-coroutines.html> -Chad ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-16 8:29 ` Lluís Batlle 2008-02-17 23:09 ` Chad Dougherty @ 2008-02-18 21:50 ` Pietro Gagliardi 2008-02-22 10:02 ` Douglas A. Gwyn 2 siblings, 0 replies; 107+ messages in thread From: Pietro Gagliardi @ 2008-02-18 21:50 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs It says here that setjmp can be used to make coroutines: http://my.execpc.com/~geezer/osd/tasks/index.htm On Feb 16, 2008, at 3:29 AM, Lluís Batlle wrote: > Talking about The Art of Computer Programming... this non-stack based > calling convention made me think of Knuth's Coroutines. I'm quite > interested on them, but although I've seen libraries for managing > them, I've never seen a real useful program based on them. I think > they could be used with advantages over the thread or normal function > call abstractions. > > Maybe someone in this list can provide a good example of coroutines > use? > > 2008/2/16, Paweł Lasek <pawel.lasek@gmail.com>: >> I don't have latest version of fascicle one (MMIX processor >> architecture and MMIXAL assembler language, from new version of The >> Art of Computer Programming) at hand, so I can't confirm it, but I >> remember that MMIX had a special register which implemented a >> "border", shifting register numbers to use them for procedure data >> separation. >> >> And as in all RISC architectures, storing as many parameters in the >> call stack is the way to go. Especially when you have 256 64-bit >> general purpose registers :-) (Now if only someone implemented a sane >> architecture using MMIX as main processor...) >> >> >> On 2/16/08, Pietro Gagliardi <pietro10@mac.com> wrote: >>> - DOS interrupt function calls use the registers, not the stack. >>> - SPARC and MIPS registers are provided to pass parameters. >>> >>> On Feb 15, 2008, at 6:37 PM, Lyndon Nerenberg wrote: >>> >>>>> >>>>> The calling conventions I have seen are the ccall, stdcall >>>>> (Windows' slightly modified version of the ccall), and pascal. All >>>>> of them push parameters on the stack. >>>> >>>> Take a look at the R-call and S-call conventions used on the IBM >>>> System 360 architecture. These machines didn't even have a stack. >>>> >>>> --lyndon >>> >>> >> >> >> -- >> Paul Lasek >> ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-16 8:29 ` Lluís Batlle 2008-02-17 23:09 ` Chad Dougherty 2008-02-18 21:50 ` Pietro Gagliardi @ 2008-02-22 10:02 ` Douglas A. Gwyn 2 siblings, 0 replies; 107+ messages in thread From: Douglas A. Gwyn @ 2008-02-22 10:02 UTC (permalink / raw) To: 9fans Lluís Batlle wrote: > Maybe someone in this list can provide a good example of coroutines use? Check out http://en.wikipedia.org/wiki/Coroutine for examples and discussion. ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-15 23:47 ` Paweł Lasek 2008-02-16 0:23 ` Brantley Coile 2008-02-16 8:29 ` Lluís Batlle @ 2008-02-26 21:30 ` Paweł Lasek 2008-02-26 22:00 ` maht 2008-02-27 4:26 ` lucio 2 siblings, 2 replies; 107+ messages in thread From: Paweł Lasek @ 2008-02-26 21:30 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs I've got some time to delve into Fascicle One again and indeed, MMIX doesn't have any stack at all. When you need stack, you implement it yourself. Anyone knows of other CPU's using this method for stack (i.e. no in-built support for stack in memory)? There is stack based on registers, though. On Sat, Feb 16, 2008 at 12:47 AM, Paweł Lasek <pawel.lasek@gmail.com> wrote: > I don't have latest version of fascicle one (MMIX processor > architecture and MMIXAL assembler language, from new version of The > Art of Computer Programming) at hand, so I can't confirm it, but I > remember that MMIX had a special register which implemented a > "border", shifting register numbers to use them for procedure data > separation. > > And as in all RISC architectures, storing as many parameters in the > call stack is the way to go. Especially when you have 256 64-bit > general purpose registers :-) (Now if only someone implemented a sane > architecture using MMIX as main processor...) > > > > > On 2/16/08, Pietro Gagliardi <pietro10@mac.com> wrote: > > - DOS interrupt function calls use the registers, not the stack. > > - SPARC and MIPS registers are provided to pass parameters. > > > > On Feb 15, 2008, at 6:37 PM, Lyndon Nerenberg wrote: > > > > >> > > >> The calling conventions I have seen are the ccall, stdcall > > >> (Windows' slightly modified version of the ccall), and pascal. All > > >> of them push parameters on the stack. > > > > > > Take a look at the R-call and S-call conventions used on the IBM > > > System 360 architecture. These machines didn't even have a stack. > > > > > > --lyndon > > > > > > > -- > Paul Lasek > -- Paul Lasek ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-26 21:30 ` Paweł Lasek @ 2008-02-26 22:00 ` maht 2008-02-26 22:32 ` Brantley Coile 2008-02-26 22:33 ` Brantley Coile 2008-02-27 4:26 ` lucio 1 sibling, 2 replies; 107+ messages in thread From: maht @ 2008-02-26 22:00 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs I'm quoting out of context as they were discussing the design of the Inferno VM but Phil Winterbottom & Rob Pike mention in http://www.vitanuova.com/inferno/papers/hotchips.html : "One might argue that a stack-based processor design would mitigate the difficulties, but our experience with the implementation of a stack machine in the AT&T Crisp microprocessor [5] leads us to believe that stack architectures are inherently slower than register-based machines. Their design lengthens the critical path by replacing simple registers with a complex stack cache mechanism." 5. Ditzel, D. R. and McLellan, R., ``Register Allocation for Free: The C Machine Stack Cache'', Proc. of Symp. on Architectural Support for Programming Languages and Operating Systems, March, 1982, pp. 48-56. I found the paper at http://portal.acm.org/citation.cfm?id=960120.801825 but you have to have a paid account so I have no idea of their conclusions beyond Rob & Phil's comment It is a widely cited paper though, so it must be a good read. (and I did find loads of other great stuff while trying to find it) The Crisp sounds like something interesting, anyone know much about it? I found this again at acm Design tradeoffs to support the C programming language in the CRISP microprocessor http://portal.acm.org/citation.cfm?id=36198&coll=portal&dl=ACM and this at ieee CRISP: a pipelined 32-bit microprocessor with 13-kbit of cache memory http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel5/4/22616/01052813.pdf seems that information doesn't want to be free today > I've got some time to delve into Fascicle One again and indeed, MMIX > doesn't have any stack at all. When you need stack, you implement it > yourself. Anyone knows of other CPU's using this method for stack > (i.e. no in-built support for stack in memory)? There is stack based > on registers, though. > ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-26 22:00 ` maht @ 2008-02-26 22:32 ` Brantley Coile 2008-02-26 23:15 ` Uriel 2008-02-26 22:33 ` Brantley Coile 1 sibling, 1 reply; 107+ messages in thread From: Brantley Coile @ 2008-02-26 22:32 UTC (permalink / raw) To: 9fans > I'm quoting out of context as they were discussing the design of the > Inferno VM but Phil Winterbottom & Rob Pike mention in > http://www.vitanuova.com/inferno/papers/hotchips.html : > > "One might argue that a stack-based processor design would mitigate the > difficulties, but our experience with the implementation of a stack > machine in the AT&T Crisp microprocessor [5] leads us to believe that > stack architectures are inherently slower than register-based machines. > Their design lengthens the critical path by replacing simple registers > with a complex stack cache mechanism." I haven't been following the Non-stack-based calling thread closely, but this comment is not about using the stack in procedure calls. They are talking about stack *machines*. push value push value add pop value The Pacal P-machine, the Lillith microcode and the Java Byte machine all come to mind. Note about calling. Intersting in any case. Ken Thompson seemed to be absent at most Usenix conferences, but at one I saw him line up at the mike after the talk on the BSD packet filter. He asked why they had used a stack machine. The poor fellow, who recognized who was asking the question looked like a deer suddenly lit by the headlights of a Peterbuilt. `It's faster?' `No, it's not!' End of questions. ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-26 22:32 ` Brantley Coile @ 2008-02-26 23:15 ` Uriel 0 siblings, 0 replies; 107+ messages in thread From: Uriel @ 2008-02-26 23:15 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > Ken Thompson seemed to be absent at most Usenix conferences, but at > one I saw him line up at the mike after the talk on the BSD > packet filter. He asked why they had used a stack machine. The > poor fellow, who recognized who was asking the question looked > like a deer suddenly lit by the headlights of a Peterbuilt. > > `It's faster?' > > `No, it's not!' > > End of questions. I would pay good money for a video of this exchange... uriel ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-26 22:00 ` maht 2008-02-26 22:32 ` Brantley Coile @ 2008-02-26 22:33 ` Brantley Coile 2008-02-26 22:46 ` Bruce Ellis 1 sibling, 1 reply; 107+ messages in thread From: Brantley Coile @ 2008-02-26 22:33 UTC (permalink / raw) To: 9fans > 5. Ditzel, D. R. and McLellan, R., ``Register Allocation for Free: The C > Machine Stack Cache'', Proc. of Symp. on Architectural Support for > Programming Languages and Operating Systems, March, 1982, pp. 48-56. Some where in my junk I still have the description of the C70 machine from BBN. No assembler. Calls to odd addresses called microcode. Just an aside. ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-26 22:33 ` Brantley Coile @ 2008-02-26 22:46 ` Bruce Ellis 0 siblings, 0 replies; 107+ messages in thread From: Bruce Ellis @ 2008-02-26 22:46 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Dis on a Chip is not stack based. There are no stacks at all. A very real advantage is that there are hence no restartable faults. If my memory serves me right this was the reason that the C compiler for the Cray XMP had segmented stacks. (A call would check if there was enough left in the current segment and if not malloc and link another segment - yes it was fast enough to get away with this.) brucee ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-26 21:30 ` Paweł Lasek 2008-02-26 22:00 ` maht @ 2008-02-27 4:26 ` lucio 2008-02-27 6:52 ` ron minnich 1 sibling, 1 reply; 107+ messages in thread From: lucio @ 2008-02-27 4:26 UTC (permalink / raw) To: 9fans > I've got some time to delve into Fascicle One again and indeed, MMIX > doesn't have any stack at all. When you need stack, you implement it > yourself. Anyone knows of other CPU's using this method for stack > (i.e. no in-built support for stack in memory)? There is stack based > on registers, though. Current or obsolete architectures? The Sperry Univac 1100 Series, designed by Seymour Craye (sp? it's been a long time) had no hardware supported stack, although it had a bit in the 36-bit instruction that caused the signed upper half of the selected index register to be added to the lower half. I don't remember whether it was before or after applying the index to the base address in the lower 16 bits of the instruction, it would need to be fixed one way (post-increment, I think) because it was unlikely to check the sign of the upper half before deciding. Bloody marvellous, it was. Specially as it was the first computer I ever worked on. I have extremely fond memories of it. I can easily wax nostalgic about it. Hm, maybe I should look for a simulator for it, anyone know of one? ++L ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-27 4:26 ` lucio @ 2008-02-27 6:52 ` ron minnich 2008-02-27 17:57 ` lucio 2008-02-28 9:33 ` Bill Gunshannon 0 siblings, 2 replies; 107+ messages in thread From: ron minnich @ 2008-02-27 6:52 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Tue, Feb 26, 2008 at 8:26 PM, <lucio@proxima.alt.za> wrote: > Current or obsolete architectures? The Sperry Univac 1100 Series, > designed by Seymour Craye (sp? Cray. I had no idea he designed it. It had a great front panel -- the lights were switches. I operated an 1108 as a student at E.I. Dupont de Nemours et. ci. in WIlmington, DE. Among other things, it ran "the Freon simulation", which evidently helped make up Dupont's mind on the ozone. Ours had a drum memory. The drum was about 20 feet long, two per cabinet, moving them required creating a hole in the side of the building and moving them with a crane. I once slipped while emptying the card reader and hit about 30 switches at once with my upper arm. The machine locked up. That's where I learned an important lesson: figure out if anyone saw you, walk away slowly, make no eye contact, "must be that software bug again" ... works every time. > Bloody marvellous, it was. Specially as it was the first computer I > ever worked on. I have extremely fond memories of it. I can easily > wax nostalgic about it. Hm, maybe I should look for a simulator for > it, anyone know of one? That would be fun, but you'd have to find Exec 8, right? Ah, the days of lights and switches. Today's machines have no soul. ron ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-27 6:52 ` ron minnich @ 2008-02-27 17:57 ` lucio 2008-02-28 9:33 ` Bill Gunshannon 1 sibling, 0 replies; 107+ messages in thread From: lucio @ 2008-02-27 17:57 UTC (permalink / raw) To: 9fans > That would be fun, but you'd have to find Exec 8, right? Well, I suppose, if only because the EXEC subset of the assembler language was so unfamiliar :-) But the head of computing at the University of Cape Town used to be an international expert on Exec 8, so he may still have a copy. Now that you remind me, "load function in channel" never really meant a thing to me, so I think I'll skip being clever. Oh, as for the drum, at UCT we had frequency fluctuations in the mains, causing the synchronous motors of the drum to speed up and slow down, causing parity errors. Given that the exec code lived on drum, swapping it in under such conditions caused lock ups. Took many months to pin it down to supply problems. ++L ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-27 6:52 ` ron minnich 2008-02-27 17:57 ` lucio @ 2008-02-28 9:33 ` Bill Gunshannon 2008-02-28 9:58 ` Charles Forsyth 2008-02-28 14:15 ` Bill Gunshannon 1 sibling, 2 replies; 107+ messages in thread From: Bill Gunshannon @ 2008-02-28 9:33 UTC (permalink / raw) To: 9fans In article <2ca539b9873bc2cd75592dc3b1e40eb8@proxima.alt.za>, lucio@proxima.alt.za writes: >> That would be fun, but you'd have to find Exec 8, right? > > Well, I suppose, if only because the EXEC subset of the assembler > language was so unfamiliar :-) > > But the head of computing at the University of Cape Town used to be an > international expert on Exec 8, so he may still have a copy. > > Now that you remind me, "load function in channel" never really meant > a thing to me, so I think I'll skip being clever. > > Oh, as for the drum, at UCT we had frequency fluctuations in the > mains, causing the synchronous motors of the drum to speed up and slow > down, causing parity errors. Given that the exec code lived on drum, > swapping it in under such conditions caused lock ups. Took many > months to pin it down to supply problems. Exec8, drum, sounds like you are talking about a Univac-1100 (I came in late, sorry). I worked with one of those back in the 80's. We had a motor-generator between the mains and the computer that took care of keeping what the computer saw flat and smooth. I always thought that was a standard Univac installation. Hey, while I have your attention. I am looking for something from those days that we ran on the Univac at that sight and UCT being an edu may have also had it. Ever heard of The Software Tools Virtual Operating System? Any chance you have a 9-track with this on it still hanging around? I would love to get my hands on a copy again. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves billg999@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include <std.disclaimer.h> ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-28 9:33 ` Bill Gunshannon @ 2008-02-28 9:58 ` Charles Forsyth 2008-02-28 14:15 ` Bill Gunshannon 1 sibling, 0 replies; 107+ messages in thread From: Charles Forsyth @ 2008-02-28 9:58 UTC (permalink / raw) To: 9fans > an edu may have also had it. Ever heard of The Software Tools > Virtual Operating System? Any chance you have a 9-track with this > on it still hanging around? I would love to get my hands on a copy > again. the Software Tools (begun by Kernighan and Plauger's book of the same name) can be found in: http://www.geocities.com/SiliconValley/Lab/9247/lang/stugbasic.tgz http://www.geocities.com/SiliconValley/Lab/9247/lang/stugtoys.tgz the latter includes a LISP written in Ratfor ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Non-stack-based calling conventions 2008-02-28 9:33 ` Bill Gunshannon 2008-02-28 9:58 ` Charles Forsyth @ 2008-02-28 14:15 ` Bill Gunshannon 1 sibling, 0 replies; 107+ messages in thread From: Bill Gunshannon @ 2008-02-28 14:15 UTC (permalink / raw) To: 9fans In article <4b3dfa84b440e0780f7cf1472ed6f93b@terzarima.net>, forsyth@terzarima.net (Charles Forsyth) writes: >> an edu may have also had it. Ever heard of The Software Tools >> Virtual Operating System? Any chance you have a 9-track with this >> on it still hanging around? I would love to get my hands on a copy >> again. > > the Software Tools (begun by Kernighan and Plauger's book of the same name) can be found in: > > http://www.geocities.com/SiliconValley/Lab/9247/lang/stugbasic.tgz > http://www.geocities.com/SiliconValley/Lab/9247/lang/stugtoys.tgz > > the latter includes a LISP written in Ratfor > Slight (and quite common) misunderstanding. This is not the K&P Software Tools. This was a graduate project that built on the ideas of K&P to create an API that at its peak ran on at least 50 different systems. It was covered in Communications of the ACM September 80. http://www.dcs.gla.ac.uk/~joe/auxiliary/ papers/Personal/VirtualOS.pdf After its release it took on a life of its own for many years. There was even a Users Group talking about it and building on it. Georgia Tech did the version for Pr1me computers. U Wisconsin - Madison did the Univac-1100 version. Etc. It was pretty slick but unfortunately, like too many parts of our industry, is seems to have all but disappeared. It is one of the things I am trying to salvage not only for posterity, but also because I think it might have some utility as technology has eliminated its worst shortcomings with its natural advancements. Think of this as what later went on to be called POSIX. The big difference being STVOS actually worked. :-) bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves billg999@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include <std.disclaimer.h> ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Google search of the day 2008-02-14 16:45 ` Douglas A. Gwyn 2008-02-14 17:09 ` john @ 2008-02-14 17:14 ` Eris Discordia 2008-02-14 17:28 ` Fco. J. Ballesteros 2008-02-14 17:51 ` Iruata Souza 1 sibling, 2 replies; 107+ messages in thread From: Eris Discordia @ 2008-02-14 17:14 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Thu, 14 Feb 2008 16:45:02 -0000, Douglas A. Gwyn <DAGwyn@null.net> wrote: > john@csplan9.rit.edu wrote: >> for (;;) >> fork(); > > In genuine UNIX(tm) systems, there is a per-user process limit, > so eventually the fork requests start failing. However, this > program keeps trying to fork, so if you kill off some of the > child processes it will spawn replacements. > That is not limited to UNIX proper. FreeBSD (and relatives, I suppose) all have the /etc/login.conf where one can set limits on virtually all aspects of user priviliges (cputime, filesize, datasize, stacksize, coredumpsize, memoryuse, maxproc, openfiles, sbsize, etc) for arbitrary user classes. I think it will be possible to kill the spawned children, because they are all bound to have pids larger than a certain number. I do not know if Linux has similar facilities. As for Plan 9, the book by Francisco Ballesteros mentions a piece of code worse than the above and points out that the only way to get rid of it would be to reboot the system (which is quite as funny as the "bootsplash: silent mode," by the way). ----snippet---- /* rabbits.c */ #include <u.h> #include <libc.h> void main(int, char*[]) { // just like rabbits... while(fork()) ; exits(nil); } ----snippet---- -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Google search of the day 2008-02-14 17:14 ` [9fans] Google search of the day Eris Discordia @ 2008-02-14 17:28 ` Fco. J. Ballesteros 2008-02-14 20:14 ` Eris Discordia 2008-02-14 17:51 ` Iruata Souza 1 sibling, 1 reply; 107+ messages in thread From: Fco. J. Ballesteros @ 2008-02-14 17:28 UTC (permalink / raw) To: 9fans Children die soon in that one. This one is worse, even the child starts spawning and so on... while(1) fork(); > ----snippet---- > /* rabbits.c */ > > #include <u.h> > #include <libc.h> > > void > main(int, char*[]) > { > // just like rabbits... > while(fork()) > ; > exits(nil); > } > ----snippet---- > > -- > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Google search of the day 2008-02-14 17:28 ` Fco. J. Ballesteros @ 2008-02-14 20:14 ` Eris Discordia 2008-02-14 20:30 ` Patrick Kristiansen 0 siblings, 1 reply; 107+ messages in thread From: Eris Discordia @ 2008-02-14 20:14 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Thu, 14 Feb 2008 17:28:03 -0000, Fco. J. Ballesteros <nemo@lsub.org> wrote: > Children die soon in that one. This one is worse, > even the child starts spawning and so on... > > while(1) fork(); > I mistook your reference in the book and copy-pasted the code for the more benign runaway process. And, thanks for having written the book and made it available online. I could not have begun learning Plan 9 without your book. On Thu, 14 Feb 2008 17:51:59 -0000, Iruata Souza <iru.muzgo@gmail.com> wrote: > not if the pids are randomized as in OpenBSD. Did not know that. On FreeBSD it seems like the pids tend to grow as the number of processes grows. Had someone known the highest pid before the runaway process was executed, they could have killed any process with a higher pid. On Thu, 14 Feb 2008 17:27:19 -0000, erik quanstrom <quanstro@coraid.com> wrote: > i don't see an easy systematic solution to this type of problem. Some sort of rate control? Say, at most 5 processes per second. Of course, that would also interfere with a busy webserver that spawns worker threads/child processes for new connections. That could be solved by running the webserver as a user belonging to the legitimately busy class. Perhaps the question is, "what, other than human discretion, differentiates a runaway process from a normal albeit busy one?" There is very little evidence to distinguish a loop striving to compute the largest prime number from a loop computing the factorial of 1234567890, an altogether more useless task :-) -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Google search of the day 2008-02-14 20:14 ` Eris Discordia @ 2008-02-14 20:30 ` Patrick Kristiansen 2008-02-14 20:38 ` Eris Discordia 0 siblings, 1 reply; 107+ messages in thread From: Patrick Kristiansen @ 2008-02-14 20:30 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 371 bytes --] 2008/2/14, Eris Discordia <eris.discordia@gmail.com>: > > There is > very little evidence to distinguish a loop striving to compute the largest > prime number from a loop computing the factorial of 1234567890, an > altogether more useless task :-) I would say that trying to compute THE largest prime number would be quite pointless. -Patrick Kristiansen. [-- Attachment #2: Type: text/html, Size: 634 bytes --] ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Google search of the day 2008-02-14 20:30 ` Patrick Kristiansen @ 2008-02-14 20:38 ` Eris Discordia 2008-02-14 22:09 ` Pietro Gagliardi 0 siblings, 1 reply; 107+ messages in thread From: Eris Discordia @ 2008-02-14 20:38 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Thu, 14 Feb 2008 20:30:22 -0000, Patrick Kristiansen <patrick.kasserer@gmail.com> wrote: > 2008/2/14, Eris Discordia <eris.discordia@gmail.com>: >> >> There is >> very little evidence to distinguish a loop striving to compute the >> largest >> prime number from a loop computing the factorial of 1234567890, an >> altogether more useless task :-) > > > I would say that trying to compute THE largest prime number would be > quite > pointless. > > -Patrick Kristiansen. These days hardly anyone is ignorant enough to not know there are infinitely many prime numbers. I was kidding. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Google search of the day 2008-02-14 20:38 ` Eris Discordia @ 2008-02-14 22:09 ` Pietro Gagliardi 2008-02-15 9:00 ` Eris Discordia 0 siblings, 1 reply; 107+ messages in thread From: Pietro Gagliardi @ 2008-02-14 22:09 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Here's what I think is the best solution: statically allocate the maximum number of tasks per process: struct JobControlBlock { /* the name my OS uses for the info field of a process (job) */ Task *mainTask; /* task == thread */ Task *jobTasks[400]; /* pointers to entry in an array of statically allocated tasks */ }; A Task runs a function; it does not continue executing at the current point. Returning from that function halts the task. Returning from the main task halts all tasks. Now a SpawnTask() (fork()) can only be done to create up to 400 tasks with the exception of the main task. ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Google search of the day 2008-02-14 22:09 ` Pietro Gagliardi @ 2008-02-15 9:00 ` Eris Discordia 0 siblings, 0 replies; 107+ messages in thread From: Eris Discordia @ 2008-02-15 9:00 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Thu, 14 Feb 2008 22:09:04 -0000, Pietro Gagliardi <pietro10@mac.com> wrote: > Here's what I think is the best solution: statically allocate the > maximum number of tasks per process: > > struct JobControlBlock { /* the name my OS uses for the info field of a > process (job) */ > Task *mainTask; /* task == thread */ > Task *jobTasks[400]; /* pointers to entry in an array of statically > allocated tasks */ > }; > > A Task runs a function; it does not continue executing at the current > point. Returning from that function halts the task. Returning from the > main task halts all tasks. > That parallels Microsoft NT's concept of threads (aka, lightweight processes): //ThreadProc is the "function" the thread runs hThread = CreateThread (&security_attributes, dwStackSize, ThreadProc, pParam, dwFlags, &idThread); Which is rather old, by the way. The same concept re-surfaced later on in .NET as the Thread and ThreadPool classes in System.Threading namespace. Sidenote: despite the negative hype, Windows programming is jolly merry. > Now a SpawnTask() (fork()) can only be done to create up to 400 tasks > with the exception of the main task. > As Erik Quanstrom pointed out, setting a limit for the total number of processes/tasks/threads would create another vulnerability. That is, inability to create any more processes because some malicious/poorly-written process is consuming all the quota. I am wondering which magical property of the number 400 has made it suitable as the limit to the number of tasks. Four hundred tasks may be amenable on your platform but wreak havoc on somebody else's poor old PC. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Google search of the day 2008-02-14 17:14 ` [9fans] Google search of the day Eris Discordia 2008-02-14 17:28 ` Fco. J. Ballesteros @ 2008-02-14 17:51 ` Iruata Souza 2008-02-15 9:31 ` sqweek 1 sibling, 1 reply; 107+ messages in thread From: Iruata Souza @ 2008-02-14 17:51 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Thu, Feb 14, 2008 at 3:14 PM, Eris Discordia <eris.discordia@gmail.com> wrote: > I think it will be possible to kill the spawned children, because they are > all bound to have pids larger than a certain number. > not if the pids are randomized as in OpenBSD. iru ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Google search of the day 2008-02-14 17:51 ` Iruata Souza @ 2008-02-15 9:31 ` sqweek 2008-02-18 9:48 ` Douglas A. Gwyn 0 siblings, 1 reply; 107+ messages in thread From: sqweek @ 2008-02-15 9:31 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Fri, Feb 15, 2008 at 2:51 AM, Iruata Souza <iru.muzgo@gmail.com> wrote: > On Thu, Feb 14, 2008 at 3:14 PM, Eris Discordia > <eris.discordia@gmail.com> wrote: > > I think it will be possible to kill the spawned children, because they are > > all bound to have pids larger than a certain number. > > not if the pids are randomized as in OpenBSD. Easy to take care of in unix, just don't kill anything until you've suspended all the fork happy procs. Is there a fork analog in plan 9? -sqweek, who should just read proc(3) but since he's commenting anyway... ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Google search of the day 2008-02-15 9:31 ` sqweek @ 2008-02-18 9:48 ` Douglas A. Gwyn 2008-02-18 9:57 ` Gorka Guardiola 2008-02-19 9:17 ` sqweek 0 siblings, 2 replies; 107+ messages in thread From: Douglas A. Gwyn @ 2008-02-18 9:48 UTC (permalink / raw) To: 9fans sqweek wrote: > Is there a fork analog in plan 9? rfork, which is more general in that the program can specify in more detail which resources are to be shared and which are to be copied. ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Google search of the day 2008-02-18 9:48 ` Douglas A. Gwyn @ 2008-02-18 9:57 ` Gorka Guardiola 2008-02-19 9:17 ` sqweek 1 sibling, 0 replies; 107+ messages in thread From: Gorka Guardiola @ 2008-02-18 9:57 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Feb 18, 2008 10:48 AM, Douglas A. Gwyn <DAGwyn@null.net> wrote: > sqweek wrote: > > Is there a fork analog in plan 9? > > rfork, which is more general in that the program can specify > in more detail which resources are to be shared and which are > to be copied. > Or even better, fork(2) which is a library function enveloping rfork(2): int fork(void) { return rfork(RFPROC|RFFDG|RFREND); } -- - curiosity sKilled the cat ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] Google search of the day 2008-02-18 9:48 ` Douglas A. Gwyn 2008-02-18 9:57 ` Gorka Guardiola @ 2008-02-19 9:17 ` sqweek 1 sibling, 0 replies; 107+ messages in thread From: sqweek @ 2008-02-19 9:17 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Feb 18, 2008 6:48 PM, Douglas A. Gwyn <DAGwyn@null.net> wrote: > sqweek wrote: > > Is there a fork analog in plan 9? > > rfork, which is more general in that the program can specify > in more detail which resources are to be shared and which are > to be copied. Er, right. I knew that, I meant to ask if there was a SIGSTOP analog. I've since glanced at proc(3) which told me "echo stop >/proc/XXXX/ctl". -sqweek ^ permalink raw reply [flat|nested] 107+ messages in thread
* [9fans] quote of the day @ 2009-12-25 9:43 erik quanstrom 2009-12-25 18:48 ` Patrick Kelly 2009-12-26 5:44 ` Jamie Gavahan 0 siblings, 2 replies; 107+ messages in thread From: erik quanstrom @ 2009-12-25 9:43 UTC (permalink / raw) To: 9fans "Do not spend too much time trying to figure out why this math works. The basis for the computation is complicated; the important point is that this is how Microsoft operating systems do it, and it works. Note, however, that this math does not work perfectly." - Microsoft EFI FAT32 File System Specification, p. 32 - erik ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] quote of the day 2009-12-25 9:43 [9fans] quote " erik quanstrom @ 2009-12-25 18:48 ` Patrick Kelly 2009-12-26 5:44 ` Jamie Gavahan 1 sibling, 0 replies; 107+ messages in thread From: Patrick Kelly @ 2009-12-25 18:48 UTC (permalink / raw) To: 'Fans of the OS Plan 9 from Bell Labs' >-----Original Message----- >From: 9fans-bounces@9fans.net [mailto:9fans-bounces@9fans.net] On Behalf Of erik quanstrom >Sent: Friday, December 25, 2009 4:43 AM >To: 9fans@9fans.net >Subject: [9fans] quote of the day >"Do not spend too much time trying to figure out why this math works. >The basis for the computation is complicated; the important point is that this is how Microsoft operating systems do it, and it works. Note, however, that this math does not work perfectly." > - Microsoft EFI FAT32 File System Specification, p. 32 -_-` Oh boy... >- erik ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] quote of the day 2009-12-25 9:43 [9fans] quote " erik quanstrom 2009-12-25 18:48 ` Patrick Kelly @ 2009-12-26 5:44 ` Jamie Gavahan 2009-12-26 5:50 ` Bruce Ellis 1 sibling, 1 reply; 107+ messages in thread From: Jamie Gavahan @ 2009-12-26 5:44 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Fri, Dec 25, 2009 at 03:43, erik quanstrom <quanstro@quanstro.net> wrote: > "Do not spend too much time trying to figure out why this math works. > The basis for the computation is complicated; the important point is > that this is how Microsoft operating systems do it, and it works. Note, > however, that this math does not work perfectly." > - Microsoft EFI FAT32 File System Specification, p. 32 Even better is that it is referred to as "a clever piece of arithmetic" two pages earlier. - jamie ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] quote of the day 2009-12-26 5:44 ` Jamie Gavahan @ 2009-12-26 5:50 ` Bruce Ellis 2009-12-26 6:42 ` Akshat Kumar 0 siblings, 1 reply; 107+ messages in thread From: Bruce Ellis @ 2009-12-26 5:50 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs it doesn't work, it doesn't have to, and it's secret! perfect documentation for shitware. brucee On 12/26/09, Jamie Gavahan <redpike@gmail.com> wrote: > On Fri, Dec 25, 2009 at 03:43, erik quanstrom <quanstro@quanstro.net> wrote: > > "Do not spend too much time trying to figure out why this math works. > > The basis for the computation is complicated; the important point is > > that this is how Microsoft operating systems do it, and it works. Note, > > however, that this math does not work perfectly." > > - Microsoft EFI FAT32 File System Specification, p. 32 > > Even better is that it is referred to as "a clever piece of arithmetic" two > pages earlier. > > - jamie > > ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] quote of the day 2009-12-26 5:50 ` Bruce Ellis @ 2009-12-26 6:42 ` Akshat Kumar 2009-12-26 6:49 ` Bruce Ellis 0 siblings, 1 reply; 107+ messages in thread From: Akshat Kumar @ 2009-12-26 6:42 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs So... mm... Where's the working AMD 64 port again? oh, ok ak On Sat, Dec 26, 2009 at 6:50 AM, Bruce Ellis <bruce.ellis@gmail.com> wrote: > it doesn't work, it doesn't have to, and it's secret! > > perfect documentation for shitware. > > brucee > ^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [9fans] quote of the day 2009-12-26 6:42 ` Akshat Kumar @ 2009-12-26 6:49 ` Bruce Ellis 0 siblings, 0 replies; 107+ messages in thread From: Bruce Ellis @ 2009-12-26 6:49 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs answer in one. On 12/26/09, Akshat Kumar <akumar@mail.nanosouffle.net> wrote: > So... mm... > > Where's the working AMD 64 port again? > > > oh, ok > ak > > On Sat, Dec 26, 2009 at 6:50 AM, Bruce Ellis <bruce.ellis@gmail.com> wrote: > > it doesn't work, it doesn't have to, and it's secret! > > > > perfect documentation for shitware. > > > > brucee > > > > ^ permalink raw reply [flat|nested] 107+ messages in thread
end of thread, other threads:[~2009-12-26 6:49 UTC | newest] Thread overview: 107+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-02-13 22:03 [9fans] quote of the day erik quanstrom 2008-02-13 23:08 ` Pietro Gagliardi 2008-02-13 23:24 ` [9fans] Google search " dave.l 2008-02-13 23:31 ` Pietro Gagliardi 2008-02-13 23:41 ` erik quanstrom 2008-02-13 23:49 ` Pietro Gagliardi 2008-02-13 23:59 ` john 2008-02-14 0:04 ` Pietro Gagliardi 2008-02-14 6:11 ` Anant Narayanan 2008-02-15 17:39 ` Skip Tavakkolian 2008-02-14 16:45 ` Douglas A. Gwyn 2008-02-14 17:09 ` john 2008-02-14 17:27 ` erik quanstrom 2008-02-15 9:50 ` Douglas A. Gwyn 2008-02-15 11:49 ` Alf 2008-02-15 13:15 ` erik quanstrom 2008-02-15 14:56 ` Brantley Coile 2008-02-15 15:44 ` Eris Discordia 2008-02-15 16:07 ` erik quanstrom 2008-02-15 16:43 ` maht 2008-02-15 17:35 ` ron minnich 2008-02-15 18:14 ` Iruata Souza 2008-02-15 18:37 ` maht 2008-02-15 17:39 ` Eris Discordia 2008-02-15 19:05 ` maht 2008-02-15 20:11 ` Eris Discordia 2008-02-15 20:18 ` Pietro Gagliardi 2008-02-15 20:49 ` maht 2008-02-16 23:32 ` Eris Discordia 2008-02-15 23:37 ` [9fans] Non-stack-based calling conventions Lyndon Nerenberg 2008-02-15 23:39 ` Pietro Gagliardi 2008-02-15 23:47 ` Paweł Lasek 2008-02-16 0:23 ` Brantley Coile 2008-02-16 23:32 ` Eris Discordia 2008-02-16 23:41 ` Pietro Gagliardi 2008-02-16 23:49 ` Brantley Coile 2008-02-17 0:04 ` Brantley Coile 2008-02-17 13:30 ` Eris Discordia 2008-02-17 15:04 ` erik quanstrom 2008-02-17 21:43 ` Uriel 2008-02-17 23:58 ` erik quanstrom 2008-02-18 1:54 ` Bruce Ellis 2008-02-18 3:43 ` erik quanstrom 2008-02-18 4:31 ` Bruce Ellis 2008-02-18 4:40 ` Pietro Gagliardi 2008-02-18 6:22 ` Robert William Fuller 2008-02-18 7:23 ` Bruce Ellis 2008-02-18 8:38 ` Anant Narayanan 2008-02-22 10:02 ` Douglas A. Gwyn 2008-02-22 19:35 ` Anant Narayanan 2008-02-18 8:30 ` Anant Narayanan 2008-02-18 8:44 ` Bruce Ellis 2008-02-18 18:50 ` Federico G. Benavento 2008-02-18 21:53 ` Lorenzo Fernando Bivens de la Fuente 2008-02-18 22:55 ` y i y u s 2008-02-18 23:46 ` Uriel 2008-02-18 22:14 ` Pietro Gagliardi 2008-02-18 22:16 ` Pietro Gagliardi 2008-02-18 22:32 ` Federico G. Benavento 2008-02-20 11:39 ` maht 2008-02-20 17:19 ` Bruce Ellis 2008-02-22 10:02 ` Douglas A. Gwyn 2008-02-22 10:02 ` Douglas A. Gwyn 2008-02-18 22:13 ` LiteStar numnums 2008-02-18 4:44 ` Pietro Gagliardi 2008-02-18 4:46 ` Pietro Gagliardi 2008-02-18 5:03 ` Uriel 2008-02-17 16:08 ` Anthony Sorace 2008-02-17 22:03 ` Charles Forsyth 2008-02-22 10:01 ` Douglas A. Gwyn 2008-02-22 14:07 ` Iruata Souza 2008-02-22 10:01 ` Douglas A. Gwyn 2008-02-22 10:01 ` Douglas A. Gwyn 2008-02-16 8:29 ` Lluís Batlle 2008-02-17 23:09 ` Chad Dougherty 2008-02-18 21:50 ` Pietro Gagliardi 2008-02-22 10:02 ` Douglas A. Gwyn 2008-02-26 21:30 ` Paweł Lasek 2008-02-26 22:00 ` maht 2008-02-26 22:32 ` Brantley Coile 2008-02-26 23:15 ` Uriel 2008-02-26 22:33 ` Brantley Coile 2008-02-26 22:46 ` Bruce Ellis 2008-02-27 4:26 ` lucio 2008-02-27 6:52 ` ron minnich 2008-02-27 17:57 ` lucio 2008-02-28 9:33 ` Bill Gunshannon 2008-02-28 9:58 ` Charles Forsyth 2008-02-28 14:15 ` Bill Gunshannon 2008-02-14 17:14 ` [9fans] Google search of the day Eris Discordia 2008-02-14 17:28 ` Fco. J. Ballesteros 2008-02-14 20:14 ` Eris Discordia 2008-02-14 20:30 ` Patrick Kristiansen 2008-02-14 20:38 ` Eris Discordia 2008-02-14 22:09 ` Pietro Gagliardi 2008-02-15 9:00 ` Eris Discordia 2008-02-14 17:51 ` Iruata Souza 2008-02-15 9:31 ` sqweek 2008-02-18 9:48 ` Douglas A. Gwyn 2008-02-18 9:57 ` Gorka Guardiola 2008-02-19 9:17 ` sqweek 2009-12-25 9:43 [9fans] quote " erik quanstrom 2009-12-25 18:48 ` Patrick Kelly 2009-12-26 5:44 ` Jamie Gavahan 2009-12-26 5:50 ` Bruce Ellis 2009-12-26 6:42 ` Akshat Kumar 2009-12-26 6:49 ` 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).