From mboxrd@z Thu Jan 1 00:00:00 1970 Mime-Version: 1.0 (Apple Message framework v753) In-Reply-To: <775b8d190802172031t11f30a4bjed66c9f1db773ce2@mail.gmail.com> References: <775b8d190802171754k725b9696pdd7692590eaf731f@mail.gmail.com> <94760cd3c80e898a9e8fbb6e5f58e8fd@quanstro.net> <775b8d190802172031t11f30a4bjed66c9f1db773ce2@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed Message-Id: <988D77EE-5F2B-4584-B5AE-F3C13088C3BF@mac.com> Content-Transfer-Encoding: quoted-printable From: Pietro Gagliardi Subject: Re: [9fans] Non-stack-based calling conventions Date: Sun, 17 Feb 2008 23:40:42 -0500 To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Topicbox-Message-UUID: 5836a6c6-ead3-11e9-9d60-3106f5b1d025 New question: can Limbo be compiled to raw binary to run on native =20 hardware? Yes. Will I do it? No. Next question: can C be interpreted like Limbo? Yes. (10th edition =20 Unix has such a program.) Will I do it? No. Someone's ideas on a programming language should not be "forced" onto =20= another's state of mind. I don't like some of the features of Limbo =20 (sys :=3D load Sys Sys->PATH) and I don't think Limbo can be used to =20 write a system kernel without an abundant amount of reductions or =20 compiler hacks (http://www.osdev.org/wiki/C_PlusPlus discusses enough =20= of them for C++ to make one puke). If someone defies those odds, good =20= for them. Also, C can be a pain in the neck at so many times (pointer =20= arithmetic multiplies the difficulty of porting Assembly to C). C can =20= be made to type-check at runtime, but will I do it to C itself? Not =20 when I'm porting about 30 Assembly files to C. I fear I've fallen =20 victim to the complications of Duff's device and the alt construct, =20 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 =20 > 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 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 =20 >> course. =E2=98=BA >> >> since you disagree, i assume you claim that limbo's the hammer and =20= >> 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 =20= >> 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 =20 >> typechecking? >> the inferno kernel i know about is written in c. where's the =20 >> limbo version? >> how does one run a limbo program on a new architecture without =20 >> porting >> the runtime or jit? >> >> - erik >> >>