I think that sounds perfectly reasonable, as Toon says a lot of it is vestigial.
On Sun, Jun 26, 2022 at 6:38 AM snek <[email protected]> wrote: > Thanks for the info. Looking at the intrinsics, there are not a lot and it > makes sense to me to turn them into interpreter opcodes instead. > Alternatively refactoring them them to get rid of their confusion with > runtime functions could be an option if the count is expected to grow but > looking at the current ones that seems pretty unlikely to me. If no one > disagrees I could probably find some time to work on changing them into > opcodes and deleting the intrinsic code. > > On Friday, June 24, 2022 at 7:23:09 AM UTC-7 Toon Verwaest wrote: > >> I believe part of it is just left-over from self-hosted JS where we had >> %_f() syntax. I started looking into removing this but it was a little too >> messy to be worth it. If someone wants to give it a try again I'm happy to >> support it :) >> >> On Wed, Jun 22, 2022 at 3:15 PM Caitlin Potter <[email protected]> wrote: >> >>> Somebody stop me if my reasoning is not completely accurate, but: >>> >> >> Sounds close enough, thanks :) >> >> >>> >>> 1) simplicity -- intrinsics provide a way to add essentially a new >>> opcode to the interpreter, without needing to handle it in >>> bytecode-graph-builder (or nowadays, also not need to handle it in the >>> baseline jit). So this lends itself to a more incremental implementation >>> process. >>> >>> 2) size -- When the goal of the bytecode format is in part memory >>> savings, operations which are less frequent may have been placed in >>> intrinsics rather than risking needing a wider opcode byte. I believe this >>> is no longer an issue, but I remember being told this at some point. >>> >> >> I do believe we could host the number of intrinsics we have directly in >> the bytecode. >> >> >>> >>> 3) performance -- prior to the conservative scanning gc, there would be >>> a significant cost invoking C code across an exit frame, so for things >>> which could happen a lot, why not stay in the interpreter and handle the >>> operation from there? >>> >> >> Right, these calls aren't runtime function calls but builtin calls. >> >> >>> >>> 4) May have been needed to avoid performance regressions when migrating >>> to ignition from the old fullcodegen inline runtime functions. >>> >> >>> I'm sure this isn't entirely accurate, but it makes sense to me. Hope >>> someone more knowledgable chimes in. >>> >>> On Jun 22, 2022, at 3:08 AM, snek <[email protected]> wrote: >>> >>> >>> hiya. i was looking at some code and i got side tracked into interpreter >>> intrinsics. We appear to be inventing fake runtime function ids which refer >>> to actual runtime function ids except that they are emitted as dynamic >>> dispatch instead of direct calls to the runtime functions? I don't >>> understand at all why we would want to do this so hopefully someone can >>> expand on this :) >>> >>> Thanks! >>> >>> -- >>> -- >>> v8-dev mailing list >>> [email protected] >>> http://groups.google.com/group/v8-dev >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "v8-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/v8-dev/d5c57707-67fc-4b89-8977-a71957f7c5ffn%40googlegroups.com >>> <https://groups.google.com/d/msgid/v8-dev/d5c57707-67fc-4b89-8977-a71957f7c5ffn%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> -- >>> -- >>> v8-dev mailing list >>> [email protected] >>> http://groups.google.com/group/v8-dev >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "v8-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> >> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/v8-dev/E83412FC-53C0-46F5-9784-3F8785A17AEA%40igalia.com >>> <https://groups.google.com/d/msgid/v8-dev/E83412FC-53C0-46F5-9784-3F8785A17AEA%40igalia.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- > -- > v8-dev mailing list > [email protected] > http://groups.google.com/group/v8-dev > --- > You received this message because you are subscribed to the Google Groups > "v8-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/v8-dev/0c953ad9-e968-40cf-bde3-692f5096c8fbn%40googlegroups.com > <https://groups.google.com/d/msgid/v8-dev/0c953ad9-e968-40cf-bde3-692f5096c8fbn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/CAGRskv_PVxRPAd1uCZ17_g9wRJDVqwO8%2BO%3D%2Bq6xWLqk_Fbj0gg%40mail.gmail.com.
