[go-nuts] Golang asm to real asm table/doc/tool
Is there a table/file/doc/tool to look up e.g. "MOVBU.P" as a real operation e.g. "ldrb (post increment)". Asked on twitter earlier, but here is probably more appropriate. -- 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.
Re: [go-nuts] Golang asm to real asm table/doc/tool
Hi Matt, There isn't any such document, but you can read the source code or use objdump. -- Aram Hăvărneanu -- 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.
Re: [go-nuts] Golang asm to real asm table/doc/tool
Aram, I've been using objdump as a workaround, but it's not very satisfying. Normally I have a reference (architecture manual) when programming in assembly. Where in the source code does it map say MOVBU.P to ldrb post increment? -- 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.
Re: [go-nuts] Golang asm to real asm table/doc/tool
On Tue, Nov 29, 2016 at 8:59 PM, matt wrote: > Where in the source code does it map say MOVBU.P to ldrb post increment? It's complicated, there's no trivial easily-visible mapping (although for this one instruction the actual concrete mapping chosen is probably trivial), there's relatively complex code that decides what to do with an instruction like MOVBU.P. Look in oplook, buildop and asmout. However, for the vast majority of instruction that still doesn't actually say "ldrb post increment" anywhere in the code. You just have to follow the code and functions like oprrr, opmvl, etc, and then read the bits. It's much easier to use objdump if you are unsure of a particular instruction. However, you rarely have to use objdump. Mostly only to add new instructions. Go uses consistent calling convention and syntax between architectures, and a large class of consistent pseudo-instructions like MOVW, MOVD, etc; the only things that vary are the more-specialized instructions and the name of the register. If you need a specialized instruction it's easy. It usually has the same name as the one from the platform manual (there are exceptions). If you don't need specialized instructions, just use generic instructions with whatever addressing mode that you want. If a particular address mode is not supported, or a multi-instruction sequence is not generated for a particular architecture and complex addressing mode the assembler will complain. You can always know what code means semantically, so there's no problem. Sometimes you want to see the actual generated code without any pseudo-instructions, when this is the case, just use objdump. I understand all this is not ideal, but it really isn't that bad. I write more assembly than Go these days, and I never have a problem with the lack of this mapping. That being said, for sparc64 there is indeed a much better documented mapping. -- Aram Hăvărneanu -- 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.
Re: [go-nuts] Golang asm to real asm table/doc/tool
Sorry, where is oplook, buildop and asmout? On Wednesday, November 30, 2016 at 7:43:25 AM UTC+11, Aram Hăvărneanu wrote: > > On Tue, Nov 29, 2016 at 8:59 PM, matt > > wrote: > > Where in the source code does it map say MOVBU.P to ldrb post increment? > > It's complicated, there's no trivial easily-visible mapping (although > for this one instruction the actual concrete mapping chosen is > probably trivial), there's relatively complex code that decides what > to do with an instruction like MOVBU.P. Look in oplook, buildop and > asmout. > > However, for the vast majority of instruction that still doesn't > actually say "ldrb post increment" anywhere in the code. You just have > to follow the code and functions like oprrr, opmvl, etc, and then read > the bits. > > It's much easier to use objdump if you are unsure of a particular > instruction. > > However, you rarely have to use objdump. Mostly only to add new > instructions. Go uses consistent calling convention and syntax between > architectures, and a large class of consistent pseudo-instructions > like MOVW, MOVD, etc; the only things that vary are the > more-specialized instructions and the name of the register. > > If you need a specialized instruction it's easy. It usually has the > same name as the one from the platform manual (there are exceptions). > > If you don't need specialized instructions, just use generic > instructions with whatever addressing mode that you want. If a > particular address mode is not supported, or a multi-instruction > sequence is not generated for a particular architecture and complex > addressing mode the assembler will complain. You can always know what > code means semantically, so there's no problem. > > Sometimes you want to see the actual generated code without any > pseudo-instructions, when this is the case, just use objdump. > > I understand all this is not ideal, but it really isn't that bad. I > write more assembly than Go these days, and I never have a problem > with the lack of this mapping. > > That being said, for sparc64 there is indeed a much better documented > mapping. > > -- > Aram Hăvărneanu > -- 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.