Am Donnerstag, 28. September 2006 01:30 schrieb Jonathan Worthington:
> Hi,
>
> Some first thoughts that come to mind after reading leo's two proposals.
> > +with new variants of the C<addattribute> opcode:
> > +
> > + addattribute cs, 'a', .DATATYPE_INT
> > + addattribute cs, 'b', .DATATYPE_CHAR
>
> Certainly preferable to syntax 1.
>
> > +Probably desired and with not much effort TBD 3):
> > +
> > + addattribute(s) cs, <<'DEF'
> > + int a;
> > + char b;
> > + DEF
> But more importantly, all syntax checking is done at PIR compile time,
> whereas the string describing the struct elements and types would not be
> parsed until runtime so typo's in type names or general syntax errors
> aren't detected until then.
That's true. Well, the idea is of course to be able to paste arbitrary C
structures into the PIR and be done with it. (I can imagine that in the
long-run class parsing and construction will be done at BEGIN or IMMEDIATE
time. This might also be done with some external parser and not in C code.)
> > +The generalization of arbitrary attribute names would of course be
> > +possible too, but isn't likely needed.
pdd updated - I ment quoted attr names.
> > + addattribute(s) bar_cs, <<'DEF'
> > + double x;
> > + foo foo; # the foo class is already defined
>
> May I suggest change second foo there to something else?
Done.
> ... But please don't rely too much on knowledge of
> C semantics when describing Parrot ones.
Yep. OTOH are we dealing with C structures here. Pointers to structs vs.
contained structs are very common construct in C code.
> > +=head2 Array Structures Elements
> With bounds checking on accesses to b, right?
Yep. pdd updated.
> I think for safety reasons we will later want to have some way of only
> letting approved code that uses unmanagedstructs run, as with them
> anyone can segfault the VM in no time at all...but that's for a security
> PDD or something.
Indeed.
> Maybe a side issue, but how do you propose dealing with languages that
> allow:
>
> class A {
> private int x;
> ...
> }
>
> class B is A {
> private int x; /* Parent's x not visible, but name is the same. */
> ...
> }
>
> Where methods in A will access the x defined in A and methods in B will
> access the x defined in B?
Parrot allows that already. See also t/pmc/objects_17.pir
> > +consequently that the attribute offsets are calculated differently
> > +depending on type, alignment, and padding. These calculations are
> > +already done in F<unmanagedstruct.pmc>.
>
> I am curious how this hurts our portability. Alignment and padding can
> differ somewhat between platforms.
Sure. Pointer size also differs. But as the offsets are always calculated on
the very same platform this doesn't really matter.
> And don't optimizing compilers
> sometimes re-order struct elements for better packing?
Not as far as I know. This would also cause troubles for C code accessing any
C library.
> (Put another way: how portable is the UnmanagedStruct PMC?)
E.g. the SDL code (using {Un,}ManagedStruct a lot runs on 32 & 64 bit
machines, LE or BE.
> A Good Thing. Also we will want an interface to get hold of the
> attribute names and types...
Yep.
> Another side-thought - if we know the types of the things in the
> attributes of the PMC, can we not auto-generate the mark code for any we
> know are PMC* or STRING*?
Yes. We do that already for ParrotObjects/Classes.
> > +=head2 Locking or opmc->pmc_ext->_synchronize
>
> Why put it before the location that is pointed to? That seems confusing
> to me, and inconsistent with the next_for_gc entry that is placed after
> the flags rather than before the PMC starts.
Well, the idea is to have the very same struct layout, whether the PMC is
shared or not.
> Plus I imagine it
> complicates de-allocation - you have to check the flag and subtract
> sizeof(struct _Sync) if it's set...
Sure. OTOH it's simplifying attribute access.
> That's "all" that comes to me right now. ;-)
Thanks for all your comments and suggestions.
> Thanks,
>
> Jonathan
leo
