Re: [9fans] Non-stack-based calling conventions
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 ([url]http://www.osdev.org/wiki/C_PlusPlus[/url] 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.
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.
> On Feb 18, 2008 2:43 PM, erik quanstrom <firstname.lastname@example.org> wrote:[color=green][color=darkred]
>>> how did this get past my erik filter?
>>> wrong, wrong, wrong, wrong.
>>> four out of four as expected.
>> 100% whinage. 0 justification. 0 information. par for the
>> course. ☺
>> since you disagree, i assume you claim that limbo's the hammer and
>> 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
>> 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
>> the runtime or jit?
>> - erik