Front page | perl.perl5.porters |
Postings from November 2022
Re: Other op types with _AUX structures
Thread Previous
|
Thread Next
From:
Dave Mitchell
Date:
November 7, 2022 13:32
Subject:
Re: Other op types with _AUX structures
Message ID:
Y2kI3NjEIXzbpWNh@iabyn.com
On Mon, Oct 31, 2022 at 06:31:42PM +0000, Paul "LeoNerd" Evans wrote:
> > I wonder if it might make more sense to make the `op_aux` member just
> > a part of the BASEOP structure so that *any* op can make use of it.
> > This would make UNOP_AUX redundant, so presumably we'd then make it a
> > synonym of UNOP itself.
But then that costs an extra pointer of storage for every op, when only a
few ops need the aux field.
It was always my intention when I added UNOP_AUX, that if anything more
than op_first was needed, then it could be handled by the child pointed to
by the op_first, which could be LOGOP or LISTOP etc
So if you think need a LISTOP_AUX, you just create a UNOP_AUX with a
LISTOP as its only child.
Or for the multiple children case, you can just cheat a bit and have a
UNOP with multiple children: BINOP and LISTOP are just optimisations of a
UNOP which have a second pointer to allow you to access the second/last
element more conveniently. If you don't need that quick access, then a
UNOP is fine. This is in fact what multiconcat does.
> * I don't know why UNOP_AUX_item exists as its own thing. It's a
> union of a few types (PADOFFSET, SV *, IV, UV, char * or SSize_t)
> so as to be a bit more generically useful. But, we already have a
> far more useful union type that can store just about any type. It's
> called "ANY".
Probably just using ANY would have been a better approach. I can't
remember why I didn't use it back then.
> * Most uses of these "ANY" vectors are likely to have only a very
> small number of elements in
Well in their original uses, it was expected that there would be several
elements. For example, $x[1][2] uses 4. Maybe your envisioned uses would
have fewer??
> - maybe just one or two. In these cases
> it'd probably be wasteful to Newx() an entire ANY vector of just
> one or two items. I'm therefore thinking that there should be some
> functions to generate ANY-augmented OPs which take the size of
> the ANY vector required, and if that's "a small number"[1] it would
> just roll that ANY vector into the alloc'ed OP node itself;
> otherwise it could Newx() it separately.
That sounds like a lot of extra complexity? Are you thinking that some
new op types would have a fixed number of fields and so would just access
them directly in the fields of the OP, while other op types would have a
variable number, which if less than N (for some small N) would do a
BODILESS_IV style hack and have op_aux point back to into the op itself,
while for longer, op_aux would point to a malloced buffer??
Given the relatively uncommon frequency of op_aux ops, it seems like a lot
of extra complexity for relatively little memory savings.
--
Overhead, without any fuss, the stars were going out.
-- Arthur C Clarke
Thread Previous
|
Thread Next