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 wrote:
>
> One trick I’ve used when writing algorithms that use SSE is write it in Go
> first, run go build to output
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 wrote:
> reflect.Method(i) and reflect.MethodByName("myFunc") have got to be fu
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
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 performa
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
> FUNCDAT
