OSDev.org

What would be needed to add objective C to an existing kernel written in C? How would one implement basic methods like "alloc"?

http://developer.apple.com/documentatio ... rence.html

I have to ask though: Why Objective-C? What benefit do you see it giving you for kernel development?

Point: I really wish people would SEARCH the forum before asking things such as this.

At OP: The Objective C runtime, at bare minimum is more than two orders of magnitude larger in code than that of the standard C abstract machine runtime.

In short, it's a bad idea.

syntropy wrote:In short, it's a bad idea.

Why? There are plenty of people having a C++ kernel. Objective-C cannot be that much more complex, right?


JAL

Colonel Kernel wrote:I have to ask though: Why Objective-C? What benefit do you see it giving you for kernel development?

Because the OP is an Objective-C programmer, and not a C programmer?


JAL

Objective C vs. C for kernel space? links to Objective-C.

That should be enough answers for the OP. Anyone making an "Objective C" page in the Wiki?

jal wrote:

syntropy wrote:In short, it's a bad idea.

Why? There are plenty of people having a C++ kernel. Objective-C cannot be that much more complex, right?


JAL

The runtime is over 800Kb, and requires (safe) dynamic memory allocation, as well as multitasking or some form of concurrency for message dispatch, and frankly, it's just not a good idea. The C abstract machine runtime requires one to align the stack, set up a few registers and then call into _start() or main(). This may take a few lines of assembler totalling a maximum of perhaps a few bytes. Objective-C requires this, and much, much more just to instantiate classes and get started. Objective-C really shines as a much better user space language, especially for an embedded or single purpose device. (Hence why Apple uses it on their platforms.)

Yeah, I've seen that one post before (*points at solar's post*) and was wondering if there was any more insight. Still, from what you guys have said, I think it will be a good idea to stick to pure C for now. Thanks anyways.

syntropy wrote:The runtime is over 800Kb, and requires (safe) dynamic memory allocation, as well as multitasking or some form of concurrency for message dispatch, and frankly, it's just not a good idea. The C abstract machine runtime requires one to align the stack, set up a few registers and then call into _start() or main(). This may take a few lines of assembler totalling a maximum of perhaps a few bytes. Objective-C requires this, and much, much more just to instantiate classes and get started. Objective-C really shines as a much better user space language, especially for an embedded or single purpose device. (Hence why Apple uses it on their platforms.)

It's not about C vs. Objective-C for me, but C++ vs. Objective-C. To implement C++ for a kernel, one can take a very stripped down version, and I would bet (but am in no way certain) that the same goes for Objective-C.


JAL

jal wrote:

syntropy wrote:The runtime is over 800Kb, and requires (safe) dynamic memory allocation, as well as multitasking or some form of concurrency for message dispatch, and frankly, it's just not a good idea. The C abstract machine runtime requires one to align the stack, set up a few registers and then call into _start() or main(). This may take a few lines of assembler totalling a maximum of perhaps a few bytes. Objective-C requires this, and much, much more just to instantiate classes and get started. Objective-C really shines as a much better user space language, especially for an embedded or single purpose device. (Hence why Apple uses it on their platforms.)

It's not about C vs. Objective-C for me, but C++ vs. Objective-C. To implement C++ for a kernel, one can take a very stripped down version, and I would bet (but am in no way certain) that the same goes for Objective-C.


JAL

The argument still holds for C++. After adding initialization/cleanup calls for global constructors/destructors around the call to main(), compiled C++ programs become static code paths. With Objective-C however, this does not hold because the language uses 'message dispatch' as opposed to direct function calls. These messages require concurrency which, at kernel initialization time isn't really the best option, and opens up numerous problems both in design and in implementation. It also means there is significant overhead in dispatching those messages to different objects, and in a kernel that is highly undesirable. Objective-C as a replacement for C++ is like saying apples can replace oranges because they both have skins.

syntropy wrote:With Objective-C however, this does not hold because the language uses 'message dispatch' as opposed to direct function calls. These messages require concurrency

Are you sure? What kind of concurrency? Maybe for cross-process messages that's true, but intra-process messages are basically just lookups in a method cache. It's not as fast as a v-table dispatch in C++, but it's not orders of magnitude slower either.

I agree that it's overkill for a kernel though. I just don't see the need for that much flexibility when you can achieve it in cheaper ways (function pointers or C++ virtual method calls).

Colonel Kernel wrote:

syntropy wrote:With Objective-C however, this does not hold because the language uses 'message dispatch' as opposed to direct function calls. These messages require concurrency

Are you sure? What kind of concurrency? Maybe for cross-process messages that's true, but intra-process messages are basically just lookups in a method cache. It's not as fast as a v-table dispatch in C++, but it's not orders of magnitude slower either.

I agree that it's overkill for a kernel though. I just don't see the need for that much flexibility when you can achieve it in cheaper ways (function pointers or C++ virtual method calls).

EDIT: I have no idea to be honest, it's too late at night to bother with this.

xvedejas wrote:How would one implement basic methods like "alloc"?

The same way you would in C.

Now, let's write a kernel in Haskell!

MessiahAndrw wrote:

xvedejas wrote:How would one implement basic methods like "alloc"?

The same way you would in C.

Now, let's write a kernel in Haskell!

Scheme is better.

What about SNOBOL?