access to go_asm.h

[mmcloughlin]

Filing an issue related to a question from @zeebo regarding access to the g structure. With pure Go assembly this is achieved with

#include "go_asm.h"

which provides macros get_tls() and g(). This is currently not possible in avo.

Note this header is very simple:

// Copyright 2014 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.

#ifdef GOARCH_arm
#define LR R14
#endif

#ifdef GOARCH_amd64
#define	get_tls(r)	MOVQ TLS, r
#define	g(r)	0(r)(TLS*1)
#endif

#ifdef GOARCH_amd64p32
#define	get_tls(r)	MOVL TLS, r
#define	g(r)	0(r)(TLS*1)
#endif

#ifdef GOARCH_386
#define	get_tls(r)	MOVL TLS, r
#define	g(r)	0(r)(TLS*1)
#endif

So we could fix this either by providing access to the header somehow, or re-implementing the macros in avo directly.

Personally, I think providing access to the header would be best. The resulting assembly would be simpler to read, since the macros indicate intent. It would also be more future proof since this header is a supported interface (although the header has basically never been changed).

I don't currently consider this a high priority, but I wanted to make an issue to record it. If this feature would be useful to others, please let me know.

[kilic]

Also, It would be great to have an ability to write functions for header files. For example, there is a 256 bit multiplication function in this one https://github.com/cloudflare/bn256/blob/master/mul_amd64.h Having such a feature would encourage avo users to generate more complex functions, for example, whole elliptic curve addition function in x86 asm. It is still doable with current functionality, however, I don't think that having very long asm function with many duplications is good for debugging and review. If you give me a small brief for that, I would be happy to contribute.

[mmcloughlin]

@kilic I'm not sure I agree with you here. In my mind, the entire point of avo is to replace header files like that. Yes the unrolled assembly for an elliptic curve addition will be long, but the avo code generator should be far easier to understand and review.