If I include a chunk of assembly .s code in my Go code, does my program pay the CGO transition cost of locking and changing to a C stack?
I'm pretty sure the answer is no. But my knowledge of the Go internals is low enough that I thought I would like confirm that before I go pulling in .s code. Then for numerical work, if I need to call some Fortran 90 compiled library routines, does it not just look like assembly? I suppose not... in the sense that it makes certain assumptions about being able to grow the stack it is running on without running out of space. Are there assumptions beyond the stack that are used? Probably some "standard library" runtime dependencies? So on to my central question: Can the CGO transition stack switching cost be minimized by telling Go to run my main (single threaded) Go routine on a C thread to start with? In other words, can I minimize the CGO switching cost by doing runtime.LockOSThread() or similar? It seems like if we are already on a C thread, then perhaps *some large part* of the cost of Go -> f90 can be avoided. Of course the Go compiler doesn't know we are on a C thread in the general case, right(?), so it probably can't optimize those transitions by omitting change-the-stack code. Returning to the original throught about .s code, what would happen if that code tried to grow the stack too far? Just crash? Is there guidance about how far assembly can grow the stack before it needs to check back with the runtime? Thanks! J -- 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.
