swarm-support
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: State of Swarm on Mac OS X


From: W . Northcott
Subject: Re: State of Swarm on Mac OS X
Date: Mon, 23 Sep 2002 15:05:05 +1000

>No, 'object_message_send_a_la_GNU()' is the official runtime function
>for sending a message (I just don't have the official name handy). It

It would be glorious, if it was true but I am even more sceptical now I 
spent an hour looking at the source code.

The GNU/Swarm Object.m is a wrapper for the classes in a C library - 
libobjc.  However, when I check the source of the incorporated sendmsg.c, 
I can see no sign of a function to make a Next/Apple style call.

OTOH
The Apple/Darwin Object.m is a wrapper for a collection of assembler code 
- hardly a C function to be seen anywhere.  Once more the names of the 
entry points give no hint of a routine to message a GNU object. 

It seems as if Apple resorted to assembler code to overcome the speed 
problems that caused the Swarm developers to patch the GNU library.  This 
code exists in PPC and x86 forms but nothing for the other platforms on 
which Swarm is used.

As I say, I am not a programmer.  So I may have got this completely wrong, 
but I really cannot see any sign of the functions you are writing about.

While grovelling in the GCC web site, I found the following:
http://gcc.gnu.org/ml/gcc-patches/2001-05/msg01895.html
which refers to patches to speed up the GNU runtime.  It also makes 
comments about the different way that Apple does it.  At this stage I have 
no idea whether those patches  made it into the GNU runtime, never mind 
Swarm.

>But my initial questions remain: Are people interested in replacing the
>foundation objects of Swarm with the Gnustep/Apple foundation objects?

I still don't see the benefit of that.

>And are they interested in cleaning up the code, the way, that direct
>calls to the runtime are focused in just one location?

In principle, that sounds great, but only if it does not involve too great 
a speed penalty.  OO purity is a great objective and would, as you say, 
make the libraries much more portable, but the users have to be able run 
code at an acceptable speed.
It seems to me to be a case of 'Fast, cheap, good - pick any two'.  Apple 
have the resources to do  fast and good.  Swarm is probably stuck with 
fast and cheap.

Bill Northcott

                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]