On Tuesday, June 27, 2000, at 02:14 PM, Ronald Wayne Alford wrote:
> In the end, I can see why one wouldn't want all the language
> characteristics of C++ in a kernel. However, I would not be so quick to
> abandon the powers of OOP. Objective-C is supported, and seems to compile
> c fine. This reduced feature set would seem to work well. I do not know
> about drift though, nor have I done any extensive testing. It is an
> option to look at though.
Well, let me say this about Objective-C (I've been using it for about the
last ten years.)
I *love* this language, but it's showing its age a bit. For one thing, it
doesn't have namespaces.
Method call overhead is not high enough to be a problem in userland, but in the kernal it might be. To look up a method at runtime, Objective-C has to do at least one hash lookup, and may possibly do as many as their are ancestor classes before it finds the method implementation. This price is paid the *first* time a particular method is called, but after that it's cached, and the cost of method dispatch falls to not much more than calling a function through a pointer. It is also possible to look up the method implementation yourself, and call it directly if you really need every bit of possible speed.
The biggest performance issue I would see with Obj-C in the kernal, is the cost of creating and destroying objects. Right now, [Object alloc] ends up calling alloc() (which is a hashtable insert, which can require expanding the table.) Sizing the kernal heap would be a tricky business, because growing it could be time-consuming.
In NeXT's Mach kernal implementation, there was a subset of Obj-C, which they called "Kernal Objective-C."
NeXT had something called "DriverKit", which was an Obj-C framework which made it possible to write drivers in a true OO fashion: you could subclass the generic frame buffer driver, for example, and write *only* the code that had to differ between your implementation and its ancestor.
If EROS went this route, I think it would pretty much eliminate the possibility of using Linux drivers. The trade-off would be, EROS drivers would be very easy to write, but we'd have to write them all.
Keep in mind, I'd *love* to see EROS adopt Obj-C in a big way, (I'd love to see GNUStep on EROS) but I'm not sure it's the right language for the Kernal and drivers.
-jcr
[objC retain];