Re: [go-nuts] gollvm build failed

[T Odin]

Hi Than,

I see there is malloc.h present in that path.
But, cmake throws one more error even before the mmap issue:

*-- Performing Test SPLIT_STACK_FUNCTIONAL*
*-- Performing Test SPLIT_STACK_FUNCTIONAL - Failed*
*-- trying -fcf-protection=none workaround*
*-- Performing Test SPLIT_STACK_WORKAROUND*
*-- Performing Test SPLIT_STACK_WORKAROUND - Failed*
*CMake Error at tools/gollvm/cmake/modules/AddGollvm.cmake:68 (message):*
*  C compiler does not support -fsplit-stack*
*Call Stack (most recent call first):*
*  tools/gollvm/CMakeLists.txt:22 (include)*

Tried compiling the compile source specified in cmake file manually with 
fsplit-stack and workaround of fcf-protection=none. 
But, linker is unable to find the symbol __morestack:


*ld: error: undefined symbol: __morestack*

Can you please help if I'm missing out any configuration ?

Build environment:
clang 13.0.1 on FreeBSD 12.

On Thursday, 27 January 2022 at 19:15:44 UTC+5:30 th...@google.com wrote:

> Hello,
>
> As I understand it FreeBSD doesn't have any concept of a build essentials 
> package, so in theory /usr/include/malloc.h should always be installed. Are 
> you saying that this file doesn't exist on your system?
>
> Thanks, Than
>
>
> On Thu, Jan 27, 2022 at 5:38 AM T Odin  wrote:
>
>> I'm trying to build gollvm on FreeBSD 13 using the command as mentioned 
>> in gollvm source page.
>>
>> *cmake -DCMAKE_BUILD_TYPE=Debug -DLLVM_USE_LINKER=gold -G Ninja 
>> ../llvm-project/llvm *
>>
>> I observed that during configuration it fails for malloc 
>>
>> *Looking for malloc/malloc.hLooking for malloc/malloc.h - not found*
>>
>> which ends up with subsequent build failures for all the dependencies 
>> libffi, libbacktrace with 
>>
>>
>>
>> *Support for mmap() is required -- setup failed.Call Stack (most recent 
>> call first):tools/gollvm/libgo/CMakeLists.txt:49 (setup_libffi)*
>>
>> I read from the FAQs that support for OS other than Linux wasn't 
>> supported. I'd like to clarify the changes required to be ported for 
>> compiling and supporting on other OS. 
>>
>> -- 
>> 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...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/238a962f-b12e-4ccb-b2d6-0bbd91fb0040n%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/76c04c1c-8e50-43b2-9e88-7378535028b3n%40googlegroups.com.

[go-nuts] Improving on unit test styles

['Markus Zimmermann' via golang-nuts]

Hi Gophers!

We were unhappy with the common unit test styles and we think we found a 
style that has clear advantages. An in-depth comparison can be found here 
https://symflower.com/en/company/blog/2022/better-table-driven-testing.

We also added support for maintaining such tests in our VS Code extension 
https://marketplace.visualstudio.com/items?itemName=symflower.symflower. 
You can either use the command or the context menu item to maintain tests. 
Here is a short introduction video 
https://www.youtube.com/watch?v=mgWLY9DDyDE&ab_channel=Symflower

There are some changes necessary to have better stack traces for 
github.com/stretchr/testify because "t.Run" calls the test function from 
another location. We are in the process of upstreaming them. Until then you 
can find them in our fork at https://github.com/symflower/testify.

Would appreciate your feedback on the style and extension. Would be also 
interesting to hear other approaches and conventions that could help others 
to write better tests.

Cheers,
Markus

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/4c52a6b6-6762-442c-b9b8-82b8f50a732dn%40googlegroups.com.

Re: [go-nuts] Aligning loops in Go assembly

[Ian Lance Taylor]

On Fri, Feb 25, 2022 at 1:25 AM Wojciech Muła  wrote:
>
> Thanks! Didn't know that the assembler is able to do this. TBH, for me, it's 
> not desired behaviour when an assembler program does something extra to a 
> low-level code. I have already observed that Go asm strips a series of NOPs, 
> which is highly unexpected.

For better or for worse, the Go assembler is already a high-level
assembler that fiddles with your low-level code.

Ian

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWCgJA6cxwqVvLW3Y_b%3DGQTGzTSwQeDi7fLYvkj5gFTeg%40mail.gmail.com.

Re: [go-nuts] Is there a way to specify or use the tmp directory used in testing?

[Leam Hall]

My apologies for taking so long to respond; a new job and cold weather have 
taken up most of my time.

I have two versions of the application; one CLI and one web. The programs create 
characters for games and fiction, and use data text files relative to the binary ( 
/data/* ) to get names. The reason for not embedding names into the 
binary is so the data files can be altered to suit the user's needs. They may want 
Elven names, or Chinese, or whatever. The web program also uses template files, but 
those could probably be embedded.

The tests for the CLI work 
(https://github.com/makhidkarun/crewgen/blob/master/cmd/teamgen/main_test.go), but I have 
not figured out how to make the web version tests work 
(https://github.com/makhidkarun/crewgen/blob/master/cmd/crewgen/main_test.go). If I 
uncomment lines 38-57 of the web tests and run "go test" in that directory, I 
get:

###
Building crewgen...
Running crewgen tests...
Running in /tmp/TestHandleDocroot84710494/001, with 
/home/leam/lang/git/makhidkarun/crewgen/cmd/crewgen as dir.
open /tmp/go-build3480032656/b001/data/human_male_first.txt: no such file or 
directory
open /tmp/go-build3480032656/b001/data/human_last.txt: no such file or directory
open /tmp/go-build3480032656/b001/data/human_female_first.txt: no such file or 
directory
open /tmp/go-build3480032656/b001/data/human_last.txt: no such file or directory
2022/02/25 04:48:27 open /tmp/go-build3480032656/b001/web/layout.tmpl: no such 
file or directory
--- FAIL: TestHandleDocroot (0.00s)
--- FAIL: TestHandleDocroot/BaseCrewgenRun (0.00s)
main_test.go:53: Response code is 500
###

It seems that identifying the /tmp/go-build* directory would be useful, in that 
I could write testdata files there and do better tests. Otherwise, building in 
a specified pre-existing location so I can make sure the data files are already 
in place.

Thoughts?

Leam



On 2/23/22 09:26, David Finkel wrote:



On Wed, Feb 23, 2022 at 8:53 AM Leam Hall mailto:leamh...@gmail.com>> wrote:

My program uses data and template files located relative to the binary. 
Since go test creates the binary under test in /tmp/go-build., there are no 
data or template files. How do I either specify what directory to build in so I 
can create the files, or get the tmp directory name before the tests are run so 
I can write files to it?


When go test runs tests, they run with the current working directory inside the 
package's directory, so relative paths should work.

Another option that you might want to consider is using //go:embed directives to 
embed those files in your binary. (package doc: https://pkg.go.dev/embed 
)
This way you never need to resolve anything relative to the binary again.

Note: unless you use mlock(2) embedding in the binary shouldn't bloat memory 
usage, since the data will only be paged into memory at first-access.


Thanks!

Leam

-- 
Site Automation Engineer   (reuel.net/resume )

Scribe: The Domici War     (domiciwar.net )
General Ne'er-do-well      (github.com/LeamHall 
)

-- 
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 
.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7d8cf3dc-14ab-315f-ce5a-9e3cca877e17%40gmail.com
 
.



--
Site Automation Engineer   (reuel.net/resume)
Scribe: The Domici War (domiciwar.net)
General Ne'er-do-well  (github.com/LeamHall)

--
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/60b3e74a-13cb-b2f8-2c1f-18ef195ddee2%40gmail.com.

Re: [go-nuts] Aligning loops in Go assembly

['Keith Randall' via golang-nuts]

I don't think PCALIGN is supported for x86. The assembler can parse the 
instruction, but the x86 assembler backend can't generate machine code for 
it.
Wouldn't be hard to add, I think. There's already disabled experimental 
code in there for aligning loops.

On Friday, February 25, 2022 at 1:25:32 AM UTC-8 Wojciech Muła wrote:

> Thanks! Didn't know that the assembler is able to do this. TBH, for me, 
> it's not desired behaviour when an assembler program does something extra 
> to a low-level code. I have already observed that Go asm strips a series of 
> NOPs, which is highly unexpected.
>
> A directive for alignment is way clearer. Not to mention that sometimes we 
> don't need to align jump targets.
>
> w.
> On Friday, February 25, 2022 at 9:35:10 AM UTC+1 Brian Candler wrote:
>
>> It seems to me that there is automatic alignment for loops:
>>
>> https://github.com/golang/go/blob/go1.17.7/src/cmd/internal/obj/x86/asm6.go#L51-L67
>>
>>
>> On Friday, 25 February 2022 at 06:42:23 UTC Wojciech Muła wrote:
>>
>>> The directive is not documented on 
>>> https://pkg.go.dev/cmd/internal/obj/x86. `grep -l -R PCALIGN *` run in 
>>> `cmd/interal/obj` shows for the freshest master:
>>>
>>> arm64/doc.go
>>> arm64/asm7.go
>>> arm64/asm_arm64_test.go
>>> link.go
>>> ppc64/doc.go
>>> ppc64/asm9.go
>>> ppc64/asm_test.go
>>> util.go
>>>
>>> Seems it's not implemented. When tried to use it, I got the following 
>>> error:
>>>
>>> # main
>>> asm: asmins: missing op 0 ()PCALIGN 
>>>$16
>>> asm: assembly failed
>>>
>>> Sample asm code to check this:
>>>
>>> ---asmfun_amd64.s---
>>> #include "textflag.h"
>>>
>>> TEXT ·asmfun(SB), NOSPLIT, $0
>>> PCALIGN $16
>>> RET
>>> ---eof---
>>>
>>> ---main.go---
>>> package main
>>>
>>> // go:noescape
>>> func asmfun()
>>> func main() { asmfun() }
>>> ---eof---
>>>
>>> w.
>>>
>>> On Friday, February 25, 2022 at 2:21:41 AM UTC+1 Ian Lance Taylor wrote:
>>>
 On Thu, Feb 24, 2022 at 9:40 AM Wojciech Muła  
 wrote: 
 > 
 > I'm writing an implementation in x86 assembler and I need to force a 
 certain alignment of blocks of code (as it affects performance). I found 
 that there's PCALIGN directive, but it's only available for the PPC 
 architecture. It does not work for x86. 
 > 
 > Is there any easy way to achieve this for x86? If I had one loop, it 
 won't be a problem --- I'd just put a few `BYTE $0x90` and move on. The 
 problem is my code is huge, partially autogenerated with few variants. 
 > 
 > Any hints? 

 As far as I can tell PCALIGN is implemented for all architectures. 

 Ian 

>>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/dde3fc30-270e-4437-ab19-4307da0f79d3n%40googlegroups.com.

[go-nuts] Re: Environment setup for developing golang/go

[Francesco Mari]

Thanks for sharing this! Picking up on that configuration, I found this 
piece of documentation about gopls [1]. I followed these steps:

   - Check out github.com/golang/go to /Users/frm/src/go.
   - Build the language distribution as described here [2].
   - Create a new VSCode workspace at /Users/frm/src/go.code-workspace 
   (shown below).
   - Add the necessary directories and configuration to the workspace.
   - Restart the language server.
   - Reinstall/Update all the tools.

This is the workspace configuration. I wanted to use the minimum amount of 
configuration, so I could understand what the right options really are.

{
"folders": [
{
"path": "go/src/cmd"
},
{
"path": "go/test"
},
{
"path": "go/src"
}
],
"settings": {
"go.goroot": "/Users/frm/src/go"
}
}

After following the steps above, I managed to have navigation and code 
completion in my editor.

[1]: 
https://github.com/golang/tools/blob/master/gopls/doc/advanced.md#working-on-the-go-source-distribution
[2]: https://go.dev/doc/install/source

On Friday, 25 February 2022 at 01:45:15 UTC+1 Zik Aeroh wrote:

> The way I do it in VS Code is to do something like this from the repo root:
>
> # Get the dev version of Go into PATH for the editor and local dev work
> $ export PATH=$PWD/bin:$PATH
> # Build a baseline version of go and save it to restore if things break, 
> or for comparison
> $ (cd src; GOGC=off ./make.bash) && toolstash save
> # Launch VS Code with the relevant module roots, with PATH set
> $ code ../go.code-workspace
>
> Where go.code-workspace is in the folder above my checkout (as it's not in 
> .gitignore):
>
> {
> "folders": [
> {
> "path": "go/src"
> },
> {
> "path": "go/src/cmd"
> },
> {
> "path": "go/test"
> }
> ],
> "settings": {
> "editor.codeActionsOnSave": {"source.fixAll": false},
> "go.lintOnSave": "off",
> "go.lintTool": "staticcheck",
> "gopls": {
> // "ui.semanticTokens": true,
> "ui.diagnostic.analyses": {
> "unsafeptr": false,
> "simplifycompositelit": false,
> },
> "ui.diagnostic.staticcheck": false,
> },
> "go.languageServerFlags": [
> "-remote=auto;godev",
> ],
> }
> }
>
> Which defines explicitly marks those roots for gopls, and sets a couple of 
> settings that make editing the toolchain a little less annoying (thanks to 
> the extra diagnostics and fixes and such).
>
> It's entirely possible that there's an easier way to do this, or that it's 
> already moot thanks to experimental multi-module stuff / workfile stuff. 
> That'd be nice to know (so I can remove all of this), but for now this is 
> what I do and I'm relatively content
> On Thursday, February 24, 2022 at 4:20:17 PM UTC-8 mari.fr...@gmail.com 
> wrote:
>
>> Hi all,
>>
>> I wanted to dig deeper into Go and start exploring the toolchain and the 
>> standard library. I cloned github.com/golang/go and noticed that the 
>> src/cmd directory contains a go.mod. I opened my editor (Visual Studio Code 
>> + Go plugin) in the src/cmd directory. I expected to be able to navigate 
>> the code like I normally do, but something about that project makes my 
>> editor unhappy.
>>
>> I assume that there are people here that already have their favourite 
>> editor/IDE set up to contribute to the language itself. Can you please 
>> share your setup? Are there any tips and tricks you can share to have code 
>> navigation and autocompletion working in golang/go?
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/feff5d92-1428-48d9-90de-b1a3ecc8893en%40googlegroups.com.

[go-nuts] Re: are Go generics more like C++ or more like Java?

[Markus Heukelom]

Correction:

- it must be possible to express that T is comparable (so that you can use 
map[K]V, were K must be comparable)
- it must be possible restrict T to a concrete list of types (f.e. min(a, b 
T) T must be possible to write)

On Friday, February 25, 2022 at 11:13:01 AM UTC+1 Markus Heukelom wrote:

> I think the consensus in the Go community is to refrain from comparing Go 
> language features with other programming languages. Rationale ~:
>
> - it is highly contentious
> - it is very difficult to answer, it's like asking "is purple more blue or 
> more red"
> - no matter the answer, it will not help you a lot to write better 
> programs or be more productive in Go
>
> However, maybe your real question is more like "what are/were the guiding 
> principals for generics in Go?".   As far as I understand, generics in Go 
> follow the same principles as other language features in Go:
>
> - compilation should be very fast, but trade-offs are allowed so it does 
> not need to be maximally fast
> - language features should be as orthogonal as possible, but trade-offs 
> are allowed so they don't need to be maximally orthogonal
> - it should be a simple as possible but no simpler
> - ... 
>
> For generics this has resulted in:
>
> - exotic use-cases are not supported (for example having an integer 
> *constant* as *generic parameter*, such as you see in C++ fixed size matrix 
> templates, is not supported)
> - it must be possible to express that T is comparable (f.e. min(a, b T) T 
> must be possible to write)
> - it must be possible restrict T to a concrete list of types 
> - it must be possible to restrict T to a type with method set that equals 
> that of some interface (I *personally* think this violates the principle of 
> orthogonality too much and will lead to confusion and design debate)  
>
> Of course, neither list is exhaustive and is only my personal 
> understanding of things.
>
> -Markus
>
> On Wednesday, February 23, 2022 at 9:41:14 PM UTC+1 Jason E. Aten wrote:
>
>> Back in 2009, Russ wrote a blog on generics, talking about the tradeoffs 
>> in providing generics:
>>
>> "The generic dilemma is this: *do you want slow programmers, slow 
>> compilers and bloated binaries, or slow execution times? " -- *
>> https://research.swtch.com/generic
>>
>> I haven't had the bandwidth to follow the generics detailed discussions.  
>> I was just curious, at a high level, for creating a mental model of Go's 
>> generics: which approach was taken?
>>
>> Thanks!
>>
>> J
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/3740af77-31f0-4423-b264-aaeb0cfbe49dn%40googlegroups.com.

[go-nuts] Re: are Go generics more like C++ or more like Java?

[Markus Heukelom]

I think the consensus in the Go community is to refrain from comparing Go 
language features with other programming languages. Rationale ~:

- it is highly contentious
- it is very difficult to answer, it's like asking "is purple more blue or 
more red"
- no matter the answer, it will not help you a lot to write better programs 
or be more productive in Go

However, maybe your real question is more like "what are/were the guiding 
principals for generics in Go?".   As far as I understand, generics in Go 
follow the same principles as other language features in Go:

- compilation should be very fast, but trade-offs are allowed so it does 
not need to be maximally fast
- language features should be as orthogonal as possible, but trade-offs are 
allowed so they don't need to be maximally orthogonal
- it should be a simple as possible but no simpler
- ... 

For generics this has resulted in:

- exotic use-cases are not supported (for example having an integer 
*constant* as *generic parameter*, such as you see in C++ fixed size matrix 
templates, is not supported)
- it must be possible to express that T is comparable (f.e. min(a, b T) T 
must be possible to write)
- it must be possible restrict T to a concrete list of types 
- it must be possible to restrict T to a type with method set that equals 
that of some interface (I *personally* think this violates the principle of 
orthogonality too much and will lead to confusion and design debate)  

Of course, neither list is exhaustive and is only my personal understanding 
of things.

-Markus

On Wednesday, February 23, 2022 at 9:41:14 PM UTC+1 Jason E. Aten wrote:

> Back in 2009, Russ wrote a blog on generics, talking about the tradeoffs 
> in providing generics:
>
> "The generic dilemma is this: *do you want slow programmers, slow 
> compilers and bloated binaries, or slow execution times? " -- *
> https://research.swtch.com/generic
>
> I haven't had the bandwidth to follow the generics detailed discussions.  
> I was just curious, at a high level, for creating a mental model of Go's 
> generics: which approach was taken?
>
> Thanks!
>
> J
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1a82fc73-0916-4619-a22b-ba624ad24eden%40googlegroups.com.

Re: [go-nuts] Aligning loops in Go assembly

[Wojciech Muła]

Thanks! Didn't know that the assembler is able to do this. TBH, for me, 
it's not desired behaviour when an assembler program does something extra 
to a low-level code. I have already observed that Go asm strips a series of 
NOPs, which is highly unexpected.

A directive for alignment is way clearer. Not to mention that sometimes we 
don't need to align jump targets.

w.
On Friday, February 25, 2022 at 9:35:10 AM UTC+1 Brian Candler wrote:

> It seems to me that there is automatic alignment for loops:
>
> https://github.com/golang/go/blob/go1.17.7/src/cmd/internal/obj/x86/asm6.go#L51-L67
>
>
> On Friday, 25 February 2022 at 06:42:23 UTC Wojciech Muła wrote:
>
>> The directive is not documented on 
>> https://pkg.go.dev/cmd/internal/obj/x86. `grep -l -R PCALIGN *` run in 
>> `cmd/interal/obj` shows for the freshest master:
>>
>> arm64/doc.go
>> arm64/asm7.go
>> arm64/asm_arm64_test.go
>> link.go
>> ppc64/doc.go
>> ppc64/asm9.go
>> ppc64/asm_test.go
>> util.go
>>
>> Seems it's not implemented. When tried to use it, I got the following 
>> error:
>>
>> # main
>> asm: asmins: missing op 0 ()PCALIGN 
>>$16
>> asm: assembly failed
>>
>> Sample asm code to check this:
>>
>> ---asmfun_amd64.s---
>> #include "textflag.h"
>>
>> TEXT ·asmfun(SB), NOSPLIT, $0
>> PCALIGN $16
>> RET
>> ---eof---
>>
>> ---main.go---
>> package main
>>
>> // go:noescape
>> func asmfun()
>> func main() { asmfun() }
>> ---eof---
>>
>> w.
>>
>> On Friday, February 25, 2022 at 2:21:41 AM UTC+1 Ian Lance Taylor wrote:
>>
>>> On Thu, Feb 24, 2022 at 9:40 AM Wojciech Muła  
>>> wrote: 
>>> > 
>>> > I'm writing an implementation in x86 assembler and I need to force a 
>>> certain alignment of blocks of code (as it affects performance). I found 
>>> that there's PCALIGN directive, but it's only available for the PPC 
>>> architecture. It does not work for x86. 
>>> > 
>>> > Is there any easy way to achieve this for x86? If I had one loop, it 
>>> won't be a problem --- I'd just put a few `BYTE $0x90` and move on. The 
>>> problem is my code is huge, partially autogenerated with few variants. 
>>> > 
>>> > Any hints? 
>>>
>>> As far as I can tell PCALIGN is implemented for all architectures. 
>>>
>>> Ian 
>>>
>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c6821872-a99d-45af-b119-6b56bdd0fd3cn%40googlegroups.com.

Re: [go-nuts] Aligning loops in Go assembly

[Brian Candler]

Oops, I see it's disabled; but the knob is there if you want to experiment.

On Friday, 25 February 2022 at 08:35:10 UTC Brian Candler wrote:

> It seems to me that there is automatic alignment for loops:
>
> https://github.com/golang/go/blob/go1.17.7/src/cmd/internal/obj/x86/asm6.go#L51-L67
>
>
> On Friday, 25 February 2022 at 06:42:23 UTC Wojciech Muła wrote:
>
>> The directive is not documented on 
>> https://pkg.go.dev/cmd/internal/obj/x86. `grep -l -R PCALIGN *` run in 
>> `cmd/interal/obj` shows for the freshest master:
>>
>> arm64/doc.go
>> arm64/asm7.go
>> arm64/asm_arm64_test.go
>> link.go
>> ppc64/doc.go
>> ppc64/asm9.go
>> ppc64/asm_test.go
>> util.go
>>
>> Seems it's not implemented. When tried to use it, I got the following 
>> error:
>>
>> # main
>> asm: asmins: missing op 0 ()PCALIGN 
>>$16
>> asm: assembly failed
>>
>> Sample asm code to check this:
>>
>> ---asmfun_amd64.s---
>> #include "textflag.h"
>>
>> TEXT ·asmfun(SB), NOSPLIT, $0
>> PCALIGN $16
>> RET
>> ---eof---
>>
>> ---main.go---
>> package main
>>
>> // go:noescape
>> func asmfun()
>> func main() { asmfun() }
>> ---eof---
>>
>> w.
>>
>> On Friday, February 25, 2022 at 2:21:41 AM UTC+1 Ian Lance Taylor wrote:
>>
>>> On Thu, Feb 24, 2022 at 9:40 AM Wojciech Muła  
>>> wrote: 
>>> > 
>>> > I'm writing an implementation in x86 assembler and I need to force a 
>>> certain alignment of blocks of code (as it affects performance). I found 
>>> that there's PCALIGN directive, but it's only available for the PPC 
>>> architecture. It does not work for x86. 
>>> > 
>>> > Is there any easy way to achieve this for x86? If I had one loop, it 
>>> won't be a problem --- I'd just put a few `BYTE $0x90` and move on. The 
>>> problem is my code is huge, partially autogenerated with few variants. 
>>> > 
>>> > Any hints? 
>>>
>>> As far as I can tell PCALIGN is implemented for all architectures. 
>>>
>>> Ian 
>>>
>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/ee7c98ea-849c-4fad-be2a-c41bfeb2e46dn%40googlegroups.com.

Re: [go-nuts] Aligning loops in Go assembly

[Brian Candler]

It seems to me that there is automatic alignment for loops:
https://github.com/golang/go/blob/go1.17.7/src/cmd/internal/obj/x86/asm6.go#L51-L67


On Friday, 25 February 2022 at 06:42:23 UTC Wojciech Muła wrote:

> The directive is not documented on https://pkg.go.dev/cmd/internal/obj/x86. 
> `grep -l -R PCALIGN *` run in `cmd/interal/obj` shows for the freshest 
> master:
>
> arm64/doc.go
> arm64/asm7.go
> arm64/asm_arm64_test.go
> link.go
> ppc64/doc.go
> ppc64/asm9.go
> ppc64/asm_test.go
> util.go
>
> Seems it's not implemented. When tried to use it, I got the following 
> error:
>
> # main
> asm: asmins: missing op 0 ()PCALIGN   
>  $16
> asm: assembly failed
>
> Sample asm code to check this:
>
> ---asmfun_amd64.s---
> #include "textflag.h"
>
> TEXT ·asmfun(SB), NOSPLIT, $0
> PCALIGN $16
> RET
> ---eof---
>
> ---main.go---
> package main
>
> // go:noescape
> func asmfun()
> func main() { asmfun() }
> ---eof---
>
> w.
>
> On Friday, February 25, 2022 at 2:21:41 AM UTC+1 Ian Lance Taylor wrote:
>
>> On Thu, Feb 24, 2022 at 9:40 AM Wojciech Muła  
>> wrote: 
>> > 
>> > I'm writing an implementation in x86 assembler and I need to force a 
>> certain alignment of blocks of code (as it affects performance). I found 
>> that there's PCALIGN directive, but it's only available for the PPC 
>> architecture. It does not work for x86. 
>> > 
>> > Is there any easy way to achieve this for x86? If I had one loop, it 
>> won't be a problem --- I'd just put a few `BYTE $0x90` and move on. The 
>> problem is my code is huge, partially autogenerated with few variants. 
>> > 
>> > Any hints? 
>>
>> As far as I can tell PCALIGN is implemented for all architectures. 
>>
>> Ian 
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/6b449fb0-aee0-4505-a22c-48d5f15a923an%40googlegroups.com.