The stack requirements are quite important, I think you have to either take care of freeing by adding assembler function that does that, or if you can instead allocate the buffers from Go variable declarations the GC will take care of it, if it is possible to do this (very likely I think yes, since assembler deals mainly with what are essentially arrays of - well, you can say, byte, (u)int(16/32/64), and it will be a flat range of memory as the assembler will expect, on this way you have the other problem making sure the GC didn't discard it before the assembler works with it.
On Saturday, 2 March 2019 00:00:16 UTC+1, Ian Lance Taylor wrote: > > On Fri, Mar 1, 2019 at 2:37 PM Jason E. Aten <j.e....@gmail.com > <javascript:>> wrote: > > > > On Friday, March 1, 2019 at 4:13:49 PM UTC-6, Ian Lance Taylor wrote: > >> > >> Go assembly code is compiled by the Go assembler, cmd/asm. The author > >> of the assembly code is required to specify how much stack space the > >> assembly function requires, in the TEXT pseudo-op that introduces the > >> function. For more about this, see https://golang.org/doc/asm. The > >> cmd/asm program will use that user declaration to insert a function > >> prologue that ensures that enough stack space is available, copying > >> the stack if necessary. The cmd/asm program will also produce a stack > >> map that the garbage collector will use when tracing back the stack; > >> in practice it's quite difficult for the assembler code to define this > >> stack map as anything other than "this stack contains no pointers", > >> but see runtime/funcdata.h. > >> > >> In any case, your Fortran 90 code will have none of that information. > >> Of course, if you know the exact stack usage of your Fortran code, and > >> if the code never stores pointers on the stack, then you could with > >> some effort write Go assembly code that defines the appropriate stack > >> information and then calls the Fortran code. I think that would, but > >> it would require a lot of manual hand-holding. > > > > > > I was thinking I could write a prelude and then launch into the .f90 > compiled routines... that I manually inline > > but I see that the assembler is a little higher level than actual amd64 > machine code. > > > > But there > > does appear to be a BYTE escape hatch in the assembler. So if I compile > my .f90 to machine code and then run > > through each byte and generate a BYTE instruction to the Go assembler, > would that (at least in theory), let > > me call the .f90 code? (Ignoring for the moment that I need to get the > parameters passed in from Go to .f90 in > > a way that the .f90 code expects; I think I will have to hand-craft some > assembly glue to make that work of course.) > > In theory, sure, as long as you accommodate the difference in calling > convention and accurately record the stack requirements. > > Ian > -- 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.
