Re: New ABI NSConstantString

[David Chisnall]

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