3 ms·
I should add: if you believe these are surmountable problems, please take it out of the forum and write a proposal. Everyone who works on the Go runtime would l
by crawshaw 10y ago
I should add: if you believe these are surmountable problems, please take it out of the forum and write a proposal. Everyone who works on the Go runtime would love to see it radically simplified. We put up with the complexity only because we believe it necessary.
- 4ad 10y ago> I should add: if you believe these are surmountable problems, please take it out of the forum and write a proposal. Yes, I've been wanting to write a proposal for over 5 years now, if only there was more time in the world... Coincidentally, I also have a method for implementing Go stacks (growing and shrinking) that does not involve copying stacks and avoids the hot-split problem. Late edit: In fact, this method would work particularly well for "growing" the stack to call C code in the 1:1 model proposed above. It would make calling a C function, just another function call with some marker on it (like we have NOFRAME and NOSPLIT now). And when we switch to a more ABI-compatible calling convention (which we want to do anyway, irrespective of all this), then we would not even be a need for a C translator written in assembly any more. Quite literally we would get cgo for free.