Re: New ABI NSConstantString

[Stefan Bidigaray]

Hi David,

I'm not entirely sure of how Apple handles the type id field, at the time I thought 16-bits was a decent value and ran with it.

As for which portion is used for the type id, I currently have it split into 2 uint16_t. But I was planning on doing the following:

struct {

       void *isa;

       uint32_t info;

       /* (1<<0) to (1<< 15): TypeID

          (1<<16) to (1<<31): reserved info

       */

};

I do not have to keep this order, so if you would like to use the lower 16 bits for string info, I'm good with that, too. Whatever happens, I'm going to have to modify the corebase code, anyway. That whole thing needs some tlc.

As for the structure you put up, I'm OK with that.

Corebase has not issues with any ObjC object, including GSTinyString. The first thing the functions do is call objc_getClass(), and compare that with the classes registered for toll-free bridging. So a GSTinyString would return as an non-bridged class, and the related ObjC method called. In the future, I would like handle on tiny strings directly.

On Fri, Apr 6, 2018 at 1:41 AM, David Chisnall <address@hidden> wrote:

On 6 Apr 2018, at 00:25, Stefan Bidigaray <address@hidden> wrote:
>
> I use the gmail web interface, which is not great. I'll just comment without quoting.
>
> The thing I'm trying to address is the fact that all CF objects must start with:
> struct {
>         void *isa;
>         uint32_t info;
> };
> That 32-bit info value includes the CFTypeID (a 16-bit value) and 16-bit for general/restricted use.

Which 16 bits are the CFTypeID and which are spare?  Apple (from their open source release) appears to use a 12-bit TypeID (which indexes into a 10-bit table, so leaves two bits spare) and uses the rest for the ref count.

> If that 32-bit (or it could be 64-bit) field could be the same for constant strings, it would allow CFString functions to work directly with ObjC constant strings, instead of having to call the toll-free bridging mechanism. That would be much more efficient for container objects in corebase.
>
> Just to be clear, the CFString structure is currently:
> struct {
>         void *isa;
>         uint32_t info;
>         char *data;
>         long count;
>         long hash;
>         void *allocator;
> };
>
> If the ObjC constant string structure and the CFString structure were similar, they could be used interchangeably in corebase and base.
>
> So my proposal was to arrange the first top-most portion of the new constant string structure as:
> sturct {
>         void *isa;
>         uint64_t info; /* includes both info and hash */
>         char *data;
>         long count;
> };
>
> If I modified the corebase version to match, these structure, with a little help from libobjc, could be exactly the same.

I’d prefer not to pack too many unrelated things into a uint64_t (particularly because that will break things on big-endian platforms), so how about:

struct
{
        Class isa;
        uint32_t flags;
        uint32_t count;
        uint32_t length;
        uint32_t hash;
        const char *data;
};

That gives us 24 bytes on 32-bit, 32 bytes on 64-bit, and 40 bytes on 128-bit, with no padding on any architecture.

Does CoreBase have any issues using GSTinyStrings?  Presumably it has to put up with the fact that they might be generated at run time and handle them already?

David