Go assembly syntax (platform specific vs platform independent)

[Daniel Liden]

Hello,

I have a question about the Go asm instructions, is there a reason for not
having a x86 specific syntax and an arm specific syntax?
There are many instructions I would like to use that are x86 specific,
like the
SHLD, SHRD instructions. (in Plan 9 syntax: SHLDQ, SHRDQ, SHLDL, SHRDL etc.)
Would it be possible to have these instructions added?

What are the pros and cons of having a "platform independent" assembly
syntax vs
a platform specific syntax?

--- Platform independent ---

Pros:
* Only have to learn one syntax.
Cons:
* Not as powerful.
- Some platform specific instructions are not available.

--- Platform specific ---

Pros:
* Very powerful.
- Access to all platform specific instructions, which are
useful for
optimizations.
Cons:
* Have to learn more than one syntax.

The reason for implementing a function in pure assembly is normally to
make very
platform specific optimizations possible. Therefor I see no big advantage of
having a platform independent assembly syntax, since you would normally
write a
different implementation for each platform (*_amd64.s, *_386.s, *_arm.s).

I understand that making a change to the assembly syntax would require a
huge
amount of work, but I'm mainly interesting in hearing the possible
advantages
and disadvantages of the current design vs a platform specific syntax.

Thank you for your time.

/Daniel and Robin

[Russ Cox]

The assembly syntax is not really platform-independent. It is,
however, somewhat unified to make things look more regular across
different architectures, primarily for our own sanity. For example,
instruction arguments are always src, dst, regardless of what the
manufacturer's assembler does.

The specific instructions you are looking for already exist. Look in
math/big/arith_amd64.s for DX:AX to find examples. I fully admit you'd
never have guessed that syntax: the assembler is woefully
underdocumented. However, this is also a bit of a special case. Most
of the instructions are easier to find.

Russ

[Daniel Liden]

Hi Ross.

The SHLD instruction ("SHLD-Double Precision Shift Left") [1] was simply
an example of a platform specific instruction which is to my knowledge
only available on x86 processors.

I was unable to locate it in the assembly lexer:
http://golang.org/src/cmd/6a/lex.c

Based on the current naming convention it should probably have been
named something along the lines of "SHLDQ", "SHLDL" and "SHLDW".

Having a unified format for src, dst operands makes sence. Are there any
plans to provide any documentation of the assembly syntax? That would be
very valuable.

[1]: http://download.intel.com/products/processor/manual/253666.pdf
(page: 530)

/Daniel and Robin

[ron minnich]

Maybe I'm missing something but can't the standard as do what you
need? You can write the function entry/exit to conform to what go
expects and then just use it. Or not?

ron

[Ian Lance Taylor]

On Mon, Nov 26, 2012 at 7:28 AM, Daniel Liden <daniel....@gmail.com> wrote:
>
> The SHLD instruction ("SHLD-Double Precision Shift Left") [1] was simply an
> example of a platform specific instruction which is to my knowledge only
> available on x86 processors.
>
> I was unable to locate it in the assembly lexer:
> http://golang.org/src/cmd/6a/lex.c
>
> Based on the current naming convention it should probably have been named
> something along the lines of "SHLDQ", "SHLDL" and "SHLDW".

It's simply called SHLQ. The instruction changes based on the
operands. To get Intel SHLD from 6a, use a DX:AX operand.

In general processor-specific instructions are added as needed.

Ian

[bryanturley]

Yeah I was about to say the same, just use a full assembler and learn how to call into/from go code.


 

[Daniel Liden]

Thank you, this helped me out a lot.
I got the right instruction by using the previously mentioned syntax:
SHLQ $8, AX:BX

It would be great if this was documented in the future.

Cheers
/Daniel and Robin

[minux]

standard as(1) will a generate a .o file but not a Plan 9 object file, while you

can use .syso trick to link that file in, you can't call external functions from Go,

you must add an extra layer of assembly or C function to call the external

function in .syso files.

Maybe we can make a small utility that take a GNU as(1) input, assemble it

and generate a Plan 9 assembly file like this:

TEXT func(SB), 7, $0 // 0 is certainly wrong, but external asm function will

                                   // surely manage its own stack frame

   BYTE $0x??; BYTE $0x??; // some inst

   // ...

   JMP A

   // ...

A:

   BYTE $0x??;

I've been thinking about this utility for some time, and I think it will ease the

task of porting GNU as(1) assembly files to Go.

After this is working, maybe we can get a fully fledged assembler translator

working (it can just use BYTE/WORD pseudo-instruction to replace any

instruction that it doesn't understand).