Ben Crowhurst wrote:
> Loïc Grenié wrote:
>> 2007/11/29, Ben Crowhurst <[EMAIL PROTECTED]>:
>>
>>> Has Objective-C ever been considered for kernel development?
>>>
>>> regards,
>>> BPC
>>>
>>
I have tried it in a toy kernel. Oskit style. The code reuse is very
high specially with string ops
Ben Crowhurst wrote:
Loïc Grenié wrote:
2007/11/29, Ben Crowhurst [EMAIL PROTECTED]:
Has Objective-C ever been considered for kernel development?
regards,
BPC
I have tried it in a toy kernel. Oskit style. The code reuse is very
high specially with string ops and driver interfaces.
Willy Tarreau wrote:
Hi Avi,
On Tue, Dec 04, 2007 at 11:07:05PM +0200, Avi Kivity wrote:
Willy Tarreau wrote:
With 10Gbit/s ethernet working you start to care about every cycle.
If you have 10M packets/sec no amount of cycle-saving will help
Diego Calleja wrote:
El Tue, 4 Dec 2007 22:47:45 +0100, "J.A. Magallón" <[EMAIL PROTECTED]> escribió:
That is what I like of C++, with good placement of high level features
like const's and & (references) one can gain fine control over what
gets copied or not.
But...if there's some way Linux
On Tue, 2007-12-04 at 12:50 -0500, Lennart Sorensen wrote:
> On Mon, Dec 03, 2007 at 02:35:31PM +0200, Gilboa Davara wrote:
> > Intel's newest dual 10GbE NIC can easily (?) throw ~14M packets per
> > second. (theoretical peak at 1514bytes/frame)
> > Granted, installing such a device on a single
On Tue, 2007-12-04 at 12:50 -0500, Lennart Sorensen wrote:
On Mon, Dec 03, 2007 at 02:35:31PM +0200, Gilboa Davara wrote:
Intel's newest dual 10GbE NIC can easily (?) throw ~14M packets per
second. (theoretical peak at 1514bytes/frame)
Granted, installing such a device on a single
Willy Tarreau wrote:
Hi Avi,
On Tue, Dec 04, 2007 at 11:07:05PM +0200, Avi Kivity wrote:
Willy Tarreau wrote:
With 10Gbit/s ethernet working you start to care about every cycle.
If you have 10M packets/sec no amount of cycle-saving will help
Diego Calleja wrote:
El Tue, 4 Dec 2007 22:47:45 +0100, J.A. Magallón [EMAIL PROTECTED] escribió:
That is what I like of C++, with good placement of high level features
like const's and (references) one can gain fine control over what
gets copied or not.
But...if there's some way Linux can
Hi Avi,
On Tue, Dec 04, 2007 at 11:07:05PM +0200, Avi Kivity wrote:
> Willy Tarreau wrote:
>
>
> >>>With 10Gbit/s ethernet working you start to care about every cycle.
> >>>
> >>>
> >>If you have 10M packets/sec no amount of cycle-saving will help you.
> >>You need
El Tue, 4 Dec 2007 22:47:45 +0100, "J.A. Magallón" <[EMAIL PROTECTED]> escribió:
> That is what I like of C++, with good placement of high level features
> like const's and & (references) one can gain fine control over what
> gets copied or not.
But...if there's some way Linux can get "language
On Mon, 3 Dec 2007 21:57:27 +, Alan Cox <[EMAIL PROTECTED]> wrote:
> > You could write an equally effcient kernel in languages like C++,
> > using C++ abstractions as a high level organization, where
>
> It's very very hard to generate good C code because of the numerous ways
> objects get
On Tue, 4 Dec 2007 12:54:13 -0500, [EMAIL PROTECTED] (Lennart Sorensen) wrote:
> On Sat, Dec 01, 2007 at 12:19:50AM +0100, J.A. Magall??n wrote:
> > I think BeOS was C++ and OSX is C+ObjectiveC (and runs on an iPhone).
> > Original MacOS (fron 6 to 9) was Pascal (and a mac SE was very near
> > to
Lennart Sorensen wrote:
But kmalloc is implemented by the kernel. Who implements 'new'?
The kernel.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Willy Tarreau wrote:
With 10Gbit/s ethernet working you start to care about every cycle.
If you have 10M packets/sec no amount of cycle-saving will help you.
You need high level optimizations like TSO. I'm not saying we should
sacrifice cycles like there's no tomorrow,
On Sat, Dec 01, 2007 at 12:19:50AM +0100, J.A. Magall??n wrote:
> I think BeOS was C++ and OSX is C+ObjectiveC (and runs on an iPhone).
> Original MacOS (fron 6 to 9) was Pascal (and a mac SE was very near
> to embedded hardware :) ).
>
> I do not advocate to rewrite Linux in C++, but don't say a
On Mon, Dec 03, 2007 at 02:35:31PM +0200, Gilboa Davara wrote:
> Intel's newest dual 10GbE NIC can easily (?) throw ~14M packets per
> second. (theoretical peak at 1514bytes/frame)
> Granted, installing such a device on a single CPU/single core machine is
> absurd - but even on an 8 core machine
On Mon, Dec 03, 2007 at 02:35:31PM +0200, Gilboa Davara wrote:
Intel's newest dual 10GbE NIC can easily (?) throw ~14M packets per
second. (theoretical peak at 1514bytes/frame)
Granted, installing such a device on a single CPU/single core machine is
absurd - but even on an 8 core machine (2 x
On Sat, Dec 01, 2007 at 12:19:50AM +0100, J.A. Magall??n wrote:
I think BeOS was C++ and OSX is C+ObjectiveC (and runs on an iPhone).
Original MacOS (fron 6 to 9) was Pascal (and a mac SE was very near
to embedded hardware :) ).
I do not advocate to rewrite Linux in C++, but don't say a
Willy Tarreau wrote:
With 10Gbit/s ethernet working you start to care about every cycle.
If you have 10M packets/sec no amount of cycle-saving will help you.
You need high level optimizations like TSO. I'm not saying we should
sacrifice cycles like there's no tomorrow,
Lennart Sorensen wrote:
But kmalloc is implemented by the kernel. Who implements 'new'?
The kernel.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 4 Dec 2007 12:54:13 -0500, [EMAIL PROTECTED] (Lennart Sorensen) wrote:
On Sat, Dec 01, 2007 at 12:19:50AM +0100, J.A. Magall??n wrote:
I think BeOS was C++ and OSX is C+ObjectiveC (and runs on an iPhone).
Original MacOS (fron 6 to 9) was Pascal (and a mac SE was very near
to
On Mon, 3 Dec 2007 21:57:27 +, Alan Cox [EMAIL PROTECTED] wrote:
You could write an equally effcient kernel in languages like C++,
using C++ abstractions as a high level organization, where
It's very very hard to generate good C code because of the numerous ways
objects get
El Tue, 4 Dec 2007 22:47:45 +0100, J.A. Magallón [EMAIL PROTECTED] escribió:
That is what I like of C++, with good placement of high level features
like const's and (references) one can gain fine control over what
gets copied or not.
But...if there's some way Linux can get language
Hi Avi,
On Tue, Dec 04, 2007 at 11:07:05PM +0200, Avi Kivity wrote:
Willy Tarreau wrote:
With 10Gbit/s ethernet working you start to care about every cycle.
If you have 10M packets/sec no amount of cycle-saving will help you.
You need high level optimizations like
> You could write an equally effcient kernel in languages like C++,
> using C++ abstractions as a high level organization, where
It's very very hard to generate good C code because of the numerous ways
objects get temporarily created, and the week aliasing rules (as with C).
There are reasons
On Mon, 3 Dec 2007 22:13:53 +0100, Willy Tarreau <[EMAIL PROTECTED]> wrote:
...
>
> It just depends how many times a second it happens. For instance, consider
> this trivial loop (fct is a two-function array which just return 1 or 2) :
>
> i = 0;
> for (j = 0; j < (1 << 28);
On Mon, Dec 03, 2007 at 01:46:45PM +0200, Avi Kivity wrote:
> Andi Kleen wrote:
> >>Even these (with the exception of the page fault path) are hardly "we
> >>care about a single instruction" material suggested above. Even with a
> >>
> >
> >With 10Gbit/s ethernet working you start to care
On Sat, Dec 01, 2007 at 09:59:31PM +0200, Avi Kivity wrote:
> C also requires a (very minimal) runtime. And I don't see how having a
> runtime disqualifies a language from being usable in a kernel; the
> runtime is just one more library, either supplied by the compiler or by
> the kernel.
Well
--- Gilboa Davara <[EMAIL PROTECTED]> wrote:
>
> On Mon, 2007-12-03 at 07:12 +0200, Avi Kivity wrote:
> > Andi Kleen wrote:
> > > Avi Kivity <[EMAIL PROTECTED]> writes:
> > >
> > >> [I really doubt there are that many of these; syscall
> > >> entry/dispatch/exit, interrupt dispatch, context
On Mon, 2007-12-03 at 14:35 +0200, Gilboa Davara wrote:
> Intel's newest dual 10GbE NIC can easily (?) throw ~14M packets per
> second. (theoretical peak at 1514bytes/frame)
> Granted, installing such a device on a single CPU/single core machine is
> absurd - but even on an 8 core machine (2 x
On Mon, 2007-12-03 at 07:12 +0200, Avi Kivity wrote:
> Andi Kleen wrote:
> > Avi Kivity <[EMAIL PROTECTED]> writes:
> >
> >> [I really doubt there are that many of these; syscall
> >> entry/dispatch/exit, interrupt dispatch, context switch, what else?]
> >>
> >
> > Networking, block IO,
On Mon, Dec 03, 2007 at 01:46:45PM +0200, Avi Kivity wrote:
> If you have 10M packets/sec no amount of cycle-saving will help you.
> You need high level optimizations like TSO. I'm not saying we should
> sacrifice cycles like there's no tomorrow, but the big wins are elsewhere.
Both high and
Andi Kleen wrote:
Even these (with the exception of the page fault path) are hardly "we
care about a single instruction" material suggested above. Even with a
With 10Gbit/s ethernet working you start to care about every cycle.
If you have 10M packets/sec no amount of cycle-saving
> Even these (with the exception of the page fault path) are hardly "we
> care about a single instruction" material suggested above. Even with a
With 10Gbit/s ethernet working you start to care about every cycle.
Similar with highend routing or in some latency sensitive network
applications
Even these (with the exception of the page fault path) are hardly we
care about a single instruction material suggested above. Even with a
With 10Gbit/s ethernet working you start to care about every cycle.
Similar with highend routing or in some latency sensitive network
applications (e.g.
Andi Kleen wrote:
Even these (with the exception of the page fault path) are hardly we
care about a single instruction material suggested above. Even with a
With 10Gbit/s ethernet working you start to care about every cycle.
If you have 10M packets/sec no amount of cycle-saving
On Mon, Dec 03, 2007 at 01:46:45PM +0200, Avi Kivity wrote:
If you have 10M packets/sec no amount of cycle-saving will help you.
You need high level optimizations like TSO. I'm not saying we should
sacrifice cycles like there's no tomorrow, but the big wins are elsewhere.
Both high and low
On Mon, 2007-12-03 at 07:12 +0200, Avi Kivity wrote:
Andi Kleen wrote:
Avi Kivity [EMAIL PROTECTED] writes:
[I really doubt there are that many of these; syscall
entry/dispatch/exit, interrupt dispatch, context switch, what else?]
Networking, block IO, page fault, ... But
On Mon, 2007-12-03 at 14:35 +0200, Gilboa Davara wrote:
Intel's newest dual 10GbE NIC can easily (?) throw ~14M packets per
second. (theoretical peak at 1514bytes/frame)
Granted, installing such a device on a single CPU/single core machine is
absurd - but even on an 8 core machine (2 x Xeon
--- Gilboa Davara [EMAIL PROTECTED] wrote:
On Mon, 2007-12-03 at 07:12 +0200, Avi Kivity wrote:
Andi Kleen wrote:
Avi Kivity [EMAIL PROTECTED] writes:
[I really doubt there are that many of these; syscall
entry/dispatch/exit, interrupt dispatch, context switch, what else?]
On Sat, Dec 01, 2007 at 09:59:31PM +0200, Avi Kivity wrote:
C also requires a (very minimal) runtime. And I don't see how having a
runtime disqualifies a language from being usable in a kernel; the
runtime is just one more library, either supplied by the compiler or by
the kernel.
Well the
On Mon, Dec 03, 2007 at 01:46:45PM +0200, Avi Kivity wrote:
Andi Kleen wrote:
Even these (with the exception of the page fault path) are hardly we
care about a single instruction material suggested above. Even with a
With 10Gbit/s ethernet working you start to care about every
On Mon, 3 Dec 2007 22:13:53 +0100, Willy Tarreau [EMAIL PROTECTED] wrote:
...
It just depends how many times a second it happens. For instance, consider
this trivial loop (fct is a two-function array which just return 1 or 2) :
i = 0;
for (j = 0; j (1 28); j++) {
You could write an equally effcient kernel in languages like C++,
using C++ abstractions as a high level organization, where
It's very very hard to generate good C code because of the numerous ways
objects get temporarily created, and the week aliasing rules (as with C).
There are reasons that
Andi Kleen wrote:
Avi Kivity <[EMAIL PROTECTED]> writes:
[I really doubt there are that many of these; syscall
entry/dispatch/exit, interrupt dispatch, context switch, what else?]
Networking, block IO, page fault, ... But only the fast paths in these
cases. A lot of the kernel is
Alan Cox wrote:
Well, original C allowed you to do what you wanted with pointers (I used
to teach that back when K was "the" C manual). Now people which about
having pointers outside the array, which is a crock in practice, as long
as you don't actually /use/ an out of range value.
On Sat, 1 December 2007 21:59:31 +0200, Avi Kivity wrote:
>
> Object orientation in C leaves much to be desired; see the huge number
> of void pointers and container_of()s in the kernel.
While true, this isn't such a bad problem. A language really sucks when
it tries to disallow something
Avi Kivity <[EMAIL PROTECTED]> writes:
>
> [I really doubt there are that many of these; syscall
> entry/dispatch/exit, interrupt dispatch, context switch, what else?]
Networking, block IO, page fault, ... But only the fast paths in these
cases. A lot of the kernel is slow path code and could
Avi Kivity [EMAIL PROTECTED] writes:
[I really doubt there are that many of these; syscall
entry/dispatch/exit, interrupt dispatch, context switch, what else?]
Networking, block IO, page fault, ... But only the fast paths in these
cases. A lot of the kernel is slow path code and could
On Sat, 1 December 2007 21:59:31 +0200, Avi Kivity wrote:
Object orientation in C leaves much to be desired; see the huge number
of void pointers and container_of()s in the kernel.
While true, this isn't such a bad problem. A language really sucks when
it tries to disallow something useful.
Alan Cox wrote:
Well, original C allowed you to do what you wanted with pointers (I used
to teach that back when KR was the C manual). Now people which about
having pointers outside the array, which is a crock in practice, as long
as you don't actually /use/ an out of range value.
Andi Kleen wrote:
Avi Kivity [EMAIL PROTECTED] writes:
[I really doubt there are that many of these; syscall
entry/dispatch/exit, interrupt dispatch, context switch, what else?]
Networking, block IO, page fault, ... But only the fast paths in these
cases. A lot of the kernel is slow
Kyle Moffett wrote:
In the kernel though, there are many codepaths where *every* *single*
instruction counts; that could be a serious performance hit.
Write *those* *codepaths* in *C* or *assembly*. But only after you
manage to measure a difference compared to the object-oriented systems
Lennart Sorensen wrote:
On Thu, Nov 29, 2007 at 12:14:16PM +, Ben Crowhurst wrote:
Has Objective-C ever been considered for kernel development?
Doesn't objective C essentially require a runtime to provide a lot of
the features of the language? If it does (as I suspect) then it is
Al Viro wrote:
On Sat, Dec 01, 2007 at 12:19:50AM +0100, J.A. Magall??n wrote:
An vtable in C++ takes exactly the same space that the function
table pointer present in every driver nowadays... and probably
the virtual method call that C++ does itself with
> Well, original C allowed you to do what you wanted with pointers (I used
> to teach that back when K was "the" C manual). Now people which about
> having pointers outside the array, which is a crock in practice, as long
> as you don't actually /use/ an out of range value.
Actually the
Alan Cox wrote:
BCPL was typeless, as was the successor B (between Bell Labs and GE we
B isn't quite typeless. It has minimal inbuilt support for concepts like
strings (although you can of course multiply a string by an array
pointer ;))
It also had some elegances that C lost, notably
Chris Snook wrote:
Ben Crowhurst wrote:
Has Objective-C ever been considered for kernel development?
No. Kernel programming requires what is essentially assembly language
with a lot of syntactic sugar, which C provides.
I somewhat disagree. Kernel programming requires and deserves the
Chris Snook wrote:
Ben Crowhurst wrote:
Has Objective-C ever been considered for kernel development?
No. Kernel programming requires what is essentially assembly language
with a lot of syntactic sugar, which C provides.
I somewhat disagree. Kernel programming requires and deserves the
Well, original C allowed you to do what you wanted with pointers (I used
to teach that back when KR was the C manual). Now people which about
having pointers outside the array, which is a crock in practice, as long
as you don't actually /use/ an out of range value.
Actually the standards
Alan Cox wrote:
BCPL was typeless, as was the successor B (between Bell Labs and GE we
B isn't quite typeless. It has minimal inbuilt support for concepts like
strings (although you can of course multiply a string by an array
pointer ;))
It also had some elegances that C lost, notably
Al Viro wrote:
On Sat, Dec 01, 2007 at 12:19:50AM +0100, J.A. Magall??n wrote:
An vtable in C++ takes exactly the same space that the function
table pointer present in every driver nowadays... and probably
the virtual method call that C++ does itself with
Lennart Sorensen wrote:
On Thu, Nov 29, 2007 at 12:14:16PM +, Ben Crowhurst wrote:
Has Objective-C ever been considered for kernel development?
Doesn't objective C essentially require a runtime to provide a lot of
the features of the language? If it does (as I suspect) then it is
Kyle Moffett wrote:
In the kernel though, there are many codepaths where *every* *single*
instruction counts; that could be a serious performance hit.
Write *those* *codepaths* in *C* or *assembly*. But only after you
manage to measure a difference compared to the object-oriented systems
On Sat, 1 Dec 2007 00:31:19 +, Al Viro <[EMAIL PROTECTED]> wrote:
> On Sat, Dec 01, 2007 at 12:19:50AM +0100, J.A. Magall??n wrote:
> > An vtable in C++ takes exactly the same space that the function
> > table pointer present in every driver nowadays... and probably
> > the virtual method
On Sat, Dec 01, 2007 at 12:31:19AM +, Al Viro wrote:
> somehow be reassigned back and forth, according to the value of this. The
s/this/thing/, of course
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
On Sat, Dec 01, 2007 at 12:19:50AM +0100, J.A. Magall??n wrote:
> An vtable in C++ takes exactly the same space that the function
> table pointer present in every driver nowadays... and probably
> the virtual method call that C++ does itself with
>
> thing->do_something(with,this)
>
> like
Em Fri, Nov 30, 2007 at 11:40:13PM +, Alan Cox escreveu:
> > BCPL was typeless, as was the successor B (between Bell Labs and GE we
>
> B isn't quite typeless. It has minimal inbuilt support for concepts like
> strings (although you can of course multiply a string by an array
> pointer ;))
>
On Sat, 2007-12-01 at 00:19 +0100, J.A. Magallón wrote:
> An vtable in C++ takes exactly the same space that the function
> table pointer present in every driver nowadays... and probably
> the virtual method call that C++ does itself with
>
> thing->do_something(with,this)
>
> like
>
> BCPL was typeless, as was the successor B (between Bell Labs and GE we
B isn't quite typeless. It has minimal inbuilt support for concepts like
strings (although you can of course multiply a string by an array
pointer ;))
It also had some elegances that C lost, notably
case 1..5:
On Fri, 30 Nov 2007 11:29:55 +0100, "Loïc Grenié" <[EMAIL PROTECTED]> wrote:
> 2007/11/29, Ben Crowhurst <[EMAIL PROTECTED]>:
> > Has Objective-C ever been considered for kernel development?
> >
> > regards,
> > BPC
>
Well, I really would like to learn some things here, could we
keep this
David Newall wrote:
Jan Engelhardt wrote:
On Nov 30 2007 11:20, Xavier Bestel wrote:
On Fri, 2007-11-30 at 19:09 +0900, KOSAKI Motohiro wrote:
Has Objective-C ever been considered for kernel development?
Why not C# instead ?
Why not Haskell nor Erlang instead ? :-D
On Fri, 30 Nov 2007 19:09:45 +0900, KOSAKI Motohiro <[EMAIL PROTECTED]> wrote:
> > > Has Objective-C ever been considered for kernel development?
> >
> > Why not C# instead ?
>
> Why not Haskell nor Erlang instead ? :-D
>
Flash
http://www.lagmonster.info/humor/windowsrg.html
--
J.A.
On Nov 30, 2007, at 13:40:07, H. Peter Anvin wrote:
Kyle Moffett wrote:
With that said, there is a significant performance penalty as all
Objective-C method calls are looked up symbolically at runtime for
every single call.
GACK!
At least C++ has vtables.
In a tight loop there is a way
Kyle Moffett wrote:
With that said, there is a significant performance penalty as all
Objective-C method calls are looked up symbolically at runtime for every
single call.
GACK!
At least C++ has vtables.
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On Nov 30, 2007, at 09:34:45, Lennart Sorensen wrote:
On Thu, Nov 29, 2007 at 12:14:16PM +, Ben Crowhurst wrote:
Has Objective-C ever been considered for kernel development?
Doesn't objective C essentially require a runtime to provide a lot
of the features of the language? If it does
Ben Crowhurst wrote:
Has Objective-C ever been considered for kernel development?
No. Kernel programming requires what is essentially assembly language with a
lot of syntactic sugar, which C provides. Higher-level languages abstract away
too much detail to be suitable for the sort of
On Fri, Nov 30, 2007 at 11:16:14AM +, Ben Crowhurst wrote:
> But are embedded systems not rapidly moving on. Turning to stare at the
> ADSL X6 modem with MB's of ram.
Some embedded systems run on batteries, so the less ram they have to
power the better, and the less cpu cycles that have to
On Thu, Nov 29, 2007 at 12:14:16PM +, Ben Crowhurst wrote:
> Has Objective-C ever been considered for kernel development?
Doesn't objective C essentially require a runtime to provide a lot of
the features of the language? If it does (as I suspect) then it is
totally unsiatable for kernel
Jan Engelhardt wrote:
On Nov 30 2007 11:20, Xavier Bestel wrote:
On Fri, 2007-11-30 at 19:09 +0900, KOSAKI Motohiro wrote:
Has Objective-C ever been considered for kernel development?
Why not C# instead ?
Why not Haskell nor Erlang instead ? :-D
I heard of
On Thu, Nov 29, 2007 at 12:14:16PM +, Ben Crowhurst wrote:
> Has Objective-C ever been considered for kernel development?
>
> regards,
> BPC
To my recall: Never.
Some limited subset of C++ was tried, but was soon abandoned.
Overall the kernel data structures are done in objectish-manner,
On 30/11/2007, Ben Crowhurst <[EMAIL PROTECTED]> wrote:
> Loïc Grenié wrote:
> > 2007/11/29, Ben Crowhurst <[EMAIL PROTECTED]>:
> >
> >> Has Objective-C ever been considered for kernel development?
> >>
> > Lots of people will think of better reasons why ObjC is not used...
> >
> >
Loïc Grenié wrote:
2007/11/29, Ben Crowhurst <[EMAIL PROTECTED]>:
Has Objective-C ever been considered for kernel development?
regards,
BPC
No, it has not. Any language that looks remotely like an OO language
has not ever been considered for (Linux) kernel development and for
On Nov 30 2007 11:20, Xavier Bestel wrote:
>On Fri, 2007-11-30 at 19:09 +0900, KOSAKI Motohiro wrote:
>> > > Has Objective-C ever been considered for kernel development?
>> >
>> > Why not C# instead ?
>>
>> Why not Haskell nor Erlang instead ? :-D
>
>I heard of a bash compiler. That would
2007/11/29, Ben Crowhurst <[EMAIL PROTECTED]>:
> Has Objective-C ever been considered for kernel development?
>
> regards,
> BPC
No, it has not. Any language that looks remotely like an OO language
has not ever been considered for (Linux) kernel development and for
most, if not all, other
On Fri, 2007-11-30 at 19:09 +0900, KOSAKI Motohiro wrote:
> > > Has Objective-C ever been considered for kernel development?
> >
> > Why not C# instead ?
>
> Why not Haskell nor Erlang instead ? :-D
I heard of a bash compiler. That would enable development time
rationalization and maximize the
> > Has Objective-C ever been considered for kernel development?
>
> Why not C# instead ?
Why not Haskell nor Erlang instead ? :-D
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Thu, 2007-11-29 at 12:14 +, Ben Crowhurst wrote:
> Has Objective-C ever been considered for kernel development?
Why not C# instead ?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Has Objective-C ever been considered for kernel development?
regards,
BPC
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
On Thu, 2007-11-29 at 12:14 +, Ben Crowhurst wrote:
Has Objective-C ever been considered for kernel development?
Why not C# instead ?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Fri, 30 Nov 2007 11:29:55 +0100, Loïc Grenié [EMAIL PROTECTED] wrote:
2007/11/29, Ben Crowhurst [EMAIL PROTECTED]:
Has Objective-C ever been considered for kernel development?
regards,
BPC
Well, I really would like to learn some things here, could we
keep this off-topic thread
On Sat, 1 Dec 2007 00:31:19 +, Al Viro [EMAIL PROTECTED] wrote:
On Sat, Dec 01, 2007 at 12:19:50AM +0100, J.A. Magall??n wrote:
An vtable in C++ takes exactly the same space that the function
table pointer present in every driver nowadays... and probably
the virtual method call that
On Sat, Dec 01, 2007 at 12:31:19AM +, Al Viro wrote:
somehow be reassigned back and forth, according to the value of this. The
s/this/thing/, of course
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
BCPL was typeless, as was the successor B (between Bell Labs and GE we
B isn't quite typeless. It has minimal inbuilt support for concepts like
strings (although you can of course multiply a string by an array
pointer ;))
It also had some elegances that C lost, notably
case 1..5:
On Sat, Dec 01, 2007 at 12:19:50AM +0100, J.A. Magall??n wrote:
An vtable in C++ takes exactly the same space that the function
table pointer present in every driver nowadays... and probably
the virtual method call that C++ does itself with
thing-do_something(with,this)
like
David Newall wrote:
Jan Engelhardt wrote:
On Nov 30 2007 11:20, Xavier Bestel wrote:
On Fri, 2007-11-30 at 19:09 +0900, KOSAKI Motohiro wrote:
Has Objective-C ever been considered for kernel development?
Why not C# instead ?
Why not Haskell nor Erlang instead ? :-D
On Fri, 30 Nov 2007 19:09:45 +0900, KOSAKI Motohiro [EMAIL PROTECTED] wrote:
Has Objective-C ever been considered for kernel development?
Why not C# instead ?
Why not Haskell nor Erlang instead ? :-D
Flash
http://www.lagmonster.info/humor/windowsrg.html
--
J.A. Magallon
On Nov 30, 2007, at 13:40:07, H. Peter Anvin wrote:
Kyle Moffett wrote:
With that said, there is a significant performance penalty as all
Objective-C method calls are looked up symbolically at runtime for
every single call.
GACK!
At least C++ has vtables.
In a tight loop there is a way
Kyle Moffett wrote:
With that said, there is a significant performance penalty as all
Objective-C method calls are looked up symbolically at runtime for every
single call.
GACK!
At least C++ has vtables.
-hpa
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
Em Fri, Nov 30, 2007 at 11:40:13PM +, Alan Cox escreveu:
BCPL was typeless, as was the successor B (between Bell Labs and GE we
B isn't quite typeless. It has minimal inbuilt support for concepts like
strings (although you can of course multiply a string by an array
pointer ;))
It
1 - 100 of 114 matches
Mail list logo
