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 <gnus...@theravensnest.org>
wrote:
> On 6 Apr 2018, at 00:25, Stefan Bidigaray <stefanb...@gmail.com> 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
>
>
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev
