Hi,
for toll-free bridging in CoreBase, I need a way to detect whether the
incoming pointer is a small object encoded in a pointer and act
accordingly (treat it as an ObjC object and avoid reading it).
What is the correct approach?
Thanks!
--
Luboš Doležel
_
The CF_IS_OBJC() macro will correctly identify small objects. The function
objc_getClass() will return a valid ObjC class that isn't toll-free bridged
and so CF_IS_OBJC() should return true. This should work.
On Fri, Jun 7, 2013 at 10:29 AM, Luboš Doležel wrote:
> Hi,
>
> for toll-free bridgi
I see. The problem is in CFGetTypeID() where the pointer is accessed in an
unsafe way (as you noted yourself in the code). I haven't given in much
thought yet, though...
Lubos
Dne 7. června 2013 17:41:15 Stefan Bidi napsal:
The CF_IS_OBJC() macro will correctly identify small objects. The
Ah, I see how this can be a problem. In this case, if I remember
correctly, small objects have the least significant bit set to 1. Checking
for that bit should be sufficient:
if ((0x01 & cf)) return _kCFRuntimeNotATypeID;
On Fri, Jun 7, 2013 at 11:02 AM, Luboš Doležel wrote:
> I see. The pr
On 7 Jun 2013, at 16:29, Luboš Doležel wrote:
> for toll-free bridging in CoreBase, I need a way to detect whether the
> incoming pointer is a small object encoded in a pointer and act accordingly
> (treat it as an ObjC object and avoid reading it).
In objc/runtime.h, there is a constant SMALL
On 7 Jun 2013, at 21:10, David Chisnall wrote:
> On 64-bit platforms, the low 3 bits will always be zero
P.S. I've done some profiling and discovered that in typical desktop
applications 5-20% of objects are small strings (up to 8 7-bit ASCII chars
stored in a pointer). This makes a fairly si
On 06/07/2013 10:10 PM, David Chisnall wrote:
On 7 Jun 2013, at 16:29, Luboš Doležel wrote:
for toll-free bridging in CoreBase, I need a way to detect whether
the incoming pointer is a small object encoded in a pointer and act
accordingly (treat it as an ObjC object and avoid reading it).
In
So I can safely do this? (Macro rewritten as inline function)
static inline __attribute__((always_inline)) BOOL objc_isSmallObject(id obj)
{
return (((intptr_t)obj) & 1) ? YES : NO;
}
在 2013-6-8，上午4:10，David Chisnall 写道：
> On 7 Jun 2013, at 16:29, Luboš Doležel wrote:
>
>> for toll-fr
No. See the email you replied to for why not.
David
On 8 Jun 2013, at 18:20, Maxthon Chan wrote:
> So I can safely do this? (Macro rewritten as inline function)
>
> static inline __attribute__((always_inline)) BOOL objc_isSmallObject(id obj)
> {
> return (((intptr_t)obj) & 1) ? YES : NO
I am expecting a solution that works on both OS X and GNUstep.
发自我的 iPhone
在 2013-6-9，1:28，David Chisnall 写道：
> No. See the email you replied to for why not.
>
> David
>
> On 8 Jun 2013, at 18:20, Maxthon Chan wrote:
>
>> So I can safely do this? (Macro rewritten as inline function)
>>
>>
On Sat, Jun 8, 2013 at 9:55 PM, Chan Maxthon wrote:
> I am expecting a solution that works on both OS X and GNUstep.
>
Why?
This is an implementation detail which can differ on OS X and GNUstep. As
far as I understand it, it's only needed inside CoreBase/Core Foundation.
Why would you need to e
I am sort of looking into the concept of running Objective-C in a kernel of an
operating system, which would require implementing a (partial) libobjc2 and
Foundation that can run on bare metal. Since all my develop machines have clang
I can exchange compiled object files in LLVM bitcode and only
Hi Maxthon,
I believe you'll really want to compile everything on the same platform, or
cross-compile for the target platform. I don't think you'll be able to
easily mix code targeting the GNUstep runtime with code targeting the NeXT
runtime.
The only reason that I can think of why you might have
Well that is why I am using LLVM bit code as the object file format (I have
-emit-llvm lying in my Makefile's CFLAGS) as it is largely ABI and platform
insensitive. And I also have -ffreestanding to make sure that the resulting bit
code is suitable for bare metal execution.
发自我的 iPhone
在 2013-
This has been done. The search term you're looking for is DriverKit.
Graham.
Sent from my David Chisnall .sigfile generator
On 8 Jun 2013, at 22:51, "Chan Maxthon" wrote:
> I am sort of looking into the concept of running Objective-C in a kernel of
> an operating system
___
And as soon as I'd sent that, I remembered reading about a kernel Objective-C
implementation on Linux. Here it is:
http://www.abdn.ac.uk/piprg/wiki/index.php?title=KCSP_an_Environment_for_Component_Based_Development_of_Linux_Kernel_Code
Graham.
Sent from my bed
On 9 Jun 2013, at 08:06, "Graham
I am sort of looking at a microkernel design - inside the kernel there are only
2 drivers: tmpfs (implemented on top of NSDictionary and NSData) and tar (on
top of NSArray and NSData) to make initramfs (which is a simple tar archive of
all pre-filesystem kexts and services) work, and everything
On 8 Jun 2013, at 22:51, Chan Maxthon wrote:
> I am sort of looking into the concept of running Objective-C in a kernel of
> an operating system, which would require implementing a (partial) libobjc2
> and Foundation that can run on bare metal
The question makes even less sense in that context
On 8 Jun 2013, at 23:14, Chan Maxthon wrote:
> I am using LLVM bit code as the object file format (I have -emit-llvm lying
> in my Makefile's CFLAGS) as it is largely ABI and platform insensitive
This is not even slightly true. There is a long document on the LLVM web site
that explains why n
19 matches
Mail list logo
