Agreed, except the generated code uses SP and not FP so when using additional
storage it is a bit more difficult to work with IMO
> On Dec 15, 2018, at 5:17 PM, Nathan Fisher <nfis...@junctionbox.ca> wrote:
>
> One trick I’ve used when writing algorithms that use SSE is write it in Go
> first, run go build to output the assembler for the function, and then tweak
> the output manually.
>> On Sat, Dec 15, 2018 at 09:36, Jason E. Aten <j.e.a...@gmail.com> wrote:
>> reflect.Method(i) and reflect.MethodByName("myFunc") have got to be fully
>> dynamic, perhaps they hold a clue.
>>
>>> On Saturday, December 15, 2018 at 8:20:20 AM UTC-6, Robert Engels wrote:
>>> That’s a possibility, but I would think there must be some assembly syntax
>>> to obtain the offset of a method of an interface function table. When you
>>> look at the assembly generated the offsets are constants... otherwise you
>>> need to perform multiple lookups to determine it - ruining the performance.
>>> If I hardcore the constant than any change to the interface breaks the
>>> assembly code, but I guess that’s the same for struct parameters and
>>> parameter order in general.
>>>
>>>> On Dec 15, 2018, at 8:12 AM, Jason E. Aten <j.e....@gmail.com> wrote:
>>>>
>>>>> On Saturday, December 15, 2018 at 1:29:14 AM UTC-6, robert engels wrote:
>>>>> Are there any examples of a hand-written assembly function that accepts
>>>>> an interface and then makes calls on the interface methods?
>>>>>
>>>>> In reviewing the documentation, it seems impossible, as the PCDATA, and
>>>>> FUNCDATA are not documented, and thus, I think the GC scanner ends up
>>>>> barfing when these are omitted.
>>>>>
>>>>> Although, since the interface is passed as a parameter, I would expect
>>>>> that the caller would retain the reference, so adding NO_LOCAL_POINTERS
>>>>> should suffice, but it is failing.
>>>>>
>>>>> Any help would be appreciated. Thanks.
>>>>
>>>> I would try writing what I wanted to do using the `reflect` package, and
>>>> then looking at the disassembly of it.
>>>> --
>>>> You received this message because you are subscribed to the Google Groups
>>>> "golang-nuts" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send an
>>>> email to golang-nuts...@googlegroups.com.
>>
>>>>
>>>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
> --
> - sent from my mobile
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
