Usage of BP register in assembly

[Egon Elbre]

Is BP usage reserved or can it be used as a general purpose register.

While discussing it in a slack channel we ended up finding some conflicting information:

https://go-review.googlesource.com/c/go/+/3390/ - seems to suggest that it should be avoided.

https://golang.org/doc/asm - doesn't mention it.

https://github.com/golang/go/blob/master/src/crypto/sha1/sha1block_386.s#L130 - seems to be using as a general purpose register.

https://github.com/golang/go/issues/12100 - seems to indicate it must be preserved.

Does it mean that, it can be used, however it'll break stack unwinding when debugging? Or are there other potential issues?

Should https://golang.org/doc/asm be updated?

Should sha1 implementation avoid BP as well?

+ Egon

[Keith Randall]

Strangely, I've just been working through fixing this.

https://go-review.googlesource.com/c/go/+/248260

https://go-review.googlesource.com/c/go/+/248261

https://go-review.googlesource.com/c/go/+/248262

BP is not reserved, but it should be callee-save. That is, if you clobber it, you must restore it before returning.

The assembler will insert a BP save/restore automatically if the frame size is >0. (That is, in the TEXT line, where you have $x-y, x is >0.)

Nothing really bad happens at the moment if you fail in this task. BP is only used by the kernel for doing stack walking for sampling-based profiling.

I'm working on implementing variable-sized frames, for which keeping an unadulterated BP will help.

Note that this applies to amd64 at the moment. On 386 BP is still a free-for-all.

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/bc1b4c72-6513-4ded-9509-88591ed7e1d4o%40googlegroups.com.

[David Chase]

BP meaning Base Pointer also known as Frame Pointer?

We've (very) recently been discussing using that on all platforms to allow variable-sized stack frames, that is, to internally support something like C alloca.

The main motivation for this is that if we do a "dictionary" style generics implementation (pointers to code instead of cookie-cutter templating out each instantiation),

there will be allocations that escape analysis *could* stack allocate, except that right now it demands known allocation sizes.

(to the inevitable question, "Why do a dictionary-style generics implementation?"

(1) we're worried about binary size;

(2) we're worried about compile times;

(3) it is somewhat more difficult; this helps us find more corner cases before they find us;

(4) we can regard templating as a time optimization (figuring out when/where to use it is a second issue);

(5) it's the more-general technique, having it as a backstop might allow use of more powerful/expressive generics, for example

    (a) methods generic in a method-specific type parameter, currently not part of Go generics because it does not mix well with templating;

    (b) polymorphic recursion, which allows very interesting use of type systems to guarantee program properties (https://en.wikipedia.org/wiki/Polymorphic_recursion).

)

To the other question, "what about assembly language that already uses BP?", we've recently added the ability to support two calling conventions within Go programs, and part of that story includes the ability to autogenerate adapters for assembly language that (by default) uses the "old" ABI.  Assuming we use BP to enable variably-sized stack frames, any assembly language using BP will certainly be accessed through these adapters until it is rewritten.

And of course these are plans, not promises, but it's a (my) best guess at what the future implementation will look like.

[Egon Elbre]

Ah, good to know.

Do you have a pending changeset to asm.html as well?

I didn't find one at least. I can send one if needed.

PS: I noticed BP usage in sha1 amd64 version as well (https://github.com/golang/go/blob/master/src/crypto/sha1/sha1block_amd64.s#L123).

I can make a similar fix as in amd64p32 had, if you haven't already started fixing it.