Go: 모두: WebAssembly("wasm") 지원

@cherrymui 와 나는 wasm GC 포트의 가능성에 대해 오랫동안 논의했습니다.
지난 며칠:

우리의 현재 결론은 효과적인 구현 방법이 없다는 것입니다.
현재 setjmp/longjmp 기능이므로 실행 가능한 대상이 아닙니다.
gc 포트의. 실제 스택이 풀릴 때까지 기다려야 하고
예외 처리 지원.

다른 모든 측면은 괜찮아 보였고 wasm에서 Go ABI까지 설계했습니다.
(wasm 스택에서 g 및 SP를 전달하고 에뮬레이트된 Go 스택에서 다른 모든 것을 전달) 및
MIPS를 에뮬레이트하여 wasm을 지원하도록 현재 MIPS 백엔드를 수정하는 방법
wasm 지역 변수로 등록합니다.

아마도 GopherJS는 wass를 더 쉽게 지원할 수 있습니다.

gopherjs/gopherjs#432에서:

그러나 GopherJS가 사용할 수 있는 기술은 아닙니다. GopherJS는 기계어 수준이 아닌 AST 수준에서 컴파일합니다.

WebAssembly는 일반 Go 컴파일러의 백엔드로 사용될 수 있습니다.

@minux 스레드 또는 비동기 i/o의 부족은 wasm quirks 때문에 우리가 해야 하는 ABI 해결 방법보다 더 큰 문제인 것 같습니다.

@minux , @cherrymui
당신이 한 일과 성취한 일을 더 자세히 어딘가에 게시할 수 있습니까?
아시다시피 go-interpreter 커뮤니티는 LLVM 또는 wasm 바이트코드를 기반으로 하는 인터프리터 작성을 고려하고 있습니다.
(우리는 GSoC 학생이 wasm 바이트코드 인터프리터 [1] 작업을 하고 있을 수도 있으므로 "Go 기반 툴체인을 통한 바이트코드 생성" 부분이 아닌 "바이트코드 소비" 부분만 사용할 수 있습니다.

중복된 노력의 양과 다양한 구성 요소 간의 임피던스 불일치를 최소화하는 것이 좋습니다.

전략적인 기능으로 적극 추천합니다. 불과 몇 년 안에 웹 프로그래머가 웹 어셈블리로 컴파일할 언어를 선택하기 위해 무리를 지어 몰려들 것이라는 점을 고려하십시오. 경주에 빨리 참가할수록 좋습니다. Mozilla는 Rust를 웹 어셈블리 언어로 강력하게 밀어붙이고 있습니다...

@RaananHadar 가 말한 두 번째입니다. 사양이 Go의 요구에 맞지 않는다면, 특히 Go의 런타임이 고유할 수 있다는 점을 고려할 때 유감입니다.

편집: 이 댓글의 MeToo 특성에 대해 사과드립니다 :) 포인터 Brad에게 감사드립니다.

알림: https://golang.org/wiki/NoMeToo

WebAssembly 스택 머신 컨텍스트는 선형 메모리와 작업 스택으로 구성됩니다. IIUC, VM 컨텍스트 저장은 다음을 저장하여 수행할 수 있습니다.

1. 현재 PC, 바이트 코드 문자열
2. 선형 메모리 및
3. 작업 스택

VM 컨텍스트 구조체에 저장된 컨텍스트의 전역 목록(있는 경우).

따라서 setjump는 단순히 이러한 값을 복원하고 평소와 같이 인터프리터 루프를 계속해야 합니다(이는 emacs 바이트코드 VM이 신호를 구현하는 방식과 유사합니다: https://github.com/emacs-mirror/emacs/blob/master/src /bytecode.c#L785). 이 위에 예외 시스템을 구현할 수 있지만 이것이 얼마나 성능이 좋을지는 모르겠습니다.

또한 웹 어셈블리 사양 은 바이트 코드의 모든 순간의 스택 높이가 정적으로 알려져 있으므로 모든 스택 작업을 스택의 각 위치에 고유한 레지스터 작업과 동일하게 만든다고 언급합니다. 이 문서 에서는 스택 머신 코드를 네이티브 코드로 변환하기 위한 스택 -> 레지스터 매핑을 달성하는 방법을 설명하고 평소처럼 setjmp/longjmp를 사용할 수 있습니다.

편집: panic() 및 recover() 를 예외 신호에 특별한 WasmException{} 값과 함께 사용하는 것은 어떻습니까? recover 는 이미 스택 해제라는 어려운 작업을 수행하므로 catch된 예외에서 복구한 후 인터프리터 루프를 복원하는 것이 어렵지 않아야 합니다.

네, 기본적으로 @cherrymui와의 토론에서도 비슷한 결과가 나왔습니다.

@cherrymui 를 사용한 초기 디자인은 다음과 같습니다.
(이 단계는 $GOROOT/test/sieve.go가 작동하도록 하는 데 중점을 두며 비동기 IO는
존경받는.)
MIPS 포트를 재사용하여 31개의 MIPS 레지스터를 WASM 로컬로 매핑합니다.
변수 및 WASM 스택만 사용
중간 결과를 위해. WASM의 함수 호출 메커니즘을 사용할 수 없습니다.
대부분의 Go 기능 때문에
스택 해제 지원 부족.
mips objlink(cmd/internal/obj)를 변경하여 각 MIPS 명령어를 에뮬레이트합니다.
각각의 WASM 지침과 함께.
이것은 setjmp/longjmp(일명 runtime.gogo) 구현을 간단하게 만들고
기존 노력을 많이 재사용합니다.

Go는 이미 WASM 스택과 별도로 자체 스택을 구현해야 합니다.
Go는 복사 가능해야 하기 때문에
스택, 스택 포인터 맵 및 스택 해제 지원,
WASM에서 사용할 수 있습니다.
(이 전략은 LLVM 포트와도 일치하므로 LLVM 스택을 사용할 수 없습니다.
거의 같은 이유
(스택 포인터를 인코딩하는 데 적절한 LLVM에 사용자 정의 백엔드 패스를 추가하지 않는 한
지도).)

간접 점프를 스레드하려면 큰 스위치를 사용해야 합니까? 이것은
NestedVM의 접근 방식과 유사합니다.
http://nestedvm.ibex.org/

네이티브 WASM 백엔드를 구현하기로 결정했다면 다음과 같이 할 수 있습니다.
Go ABI는 다음과 같습니다.
(에뮬레이트된) Go 스택의 모든 매개변수(결과 포함),
함수 항목에서 다음은 WASM 스택에 있습니다.
에뮬레이트된 SP, g.

토론은 한 달 이상 전에 있었고 아마도 일부를 잊어 버렸을 것입니다.
이 시점에서 세부 사항.

IIUC, WASM 스택을 완전히 폐기할 수 있습니다(사양에 따라). 확장 가능하고 복사 가능한 go 스택은 여전히 ​​조사해야 할 사항입니다.

네, 제가 언급한 초기 디자인은 WASM 스택만 사용합니다.
계산에 사용되는 중간체. 모든 데이터는 Go 힙(선형
메모리) 또는 WASM 지역 변수의 의사 레지스터.

WASM 사양이 이동/분할 및 복사 스택을 통합할 것으로 기대하지 않습니다.
WASM의 대상이 되는 주류 언어에서는 거의 사용되지 않습니다.

@bradfitz @minux @vibhavp golang에서 wasm의 현재 상태는 무엇입니까? 3월 13일 이후로 아무 일도 일어나지 않았습니다! 미래에 golang을 wass로 변환하는 것이 가능합니까? 아마도 그 경로 맵이 있습니까?

누군가가 was 지원을 구현하기로 결정하면 비전역적 작업에 시간을 할애할 수 있습니다.

@SerkanSipahi , 아무도 이것에 대해 작업하지 않습니다. 이 버그는 LongTerm으로 표시됩니다. 어떤 일이 일어나기 시작하면 여기에서 업데이트를 볼 수 있습니다.

좋은 로드맵?

GUI로 golang을 디버깅하기 위한 DELVE 및 GDLV가 있습니다. 모든 데스크탑에서도 잘 작동하며 성능도 뛰어납니다.
https://github.com/derekparker/delve
https://github.com/aarzilli/gdlv

이제 GDLV는 멋진 추상화로 빛나는 NUCULAR를 기반으로 합니다.
https://github.com/aarzilli/nucular

그래서 저는 이것이 이미 여기에서 수행된 작업을 수행하기 위한 좋은 기초가 될 것이라고 생각했습니다.

• 데모: http://shi-yan.github.io/AssortedWidgets/
• 코드: https://github.com/shi-yan/AssortedWidgets

이제 5개의 WASM go 라이브러리도 있습니다.
https://github.com/search?l=Go&q=webassembly&ref=simplesearch&type=Repositories&utf8=%E2%9C%93

NaCl이 종료되었습니다 - https://blog.chromium.org/2017/05/goodbye-pnacl-hello-webassembly.html
따라서 이것은 아마도 정리되어야 합니다 - https://github.com/golang/go/tree/master/misc/nacl

바둑 생태계의 다양한 부분에서 NaCl이 사용된다고 생각합니다. 즉, Chrome에서만 사용되는 것은 아닙니다. 그리고 어쨌든 블로그 발표는 PNaCl에 관한 것인데, 이는 NaCl과 유사한 기능을 제공하지만 실제로는 다른 기술을 기반으로 하는 완전히 다른 제품입니다. 따라서 Go에서 NaCl 지원을 제거하는 것은 현재 시기상조입니다.

어쨌든 Go에서 NaCl을 제거하는지 여부는 웹 어셈블리에 대한 지원을 추가하는지 여부와 관련이 없습니다.

PNaCl은 플랫폼 독립적인 코드 https://developer.chrome.com/native-client/nacl-and-pnacl 를 제공하기 위해 NaCl에 대한 확장일 뿐이라고 말하고 싶습니다. 여기서 NaCl 사용 중단에 대해 질문 했습니다. com/d/topic/native-client-discuss/wgN2ketXybQ/discussion

NaCl이 여전히 사용되는 Go 생태계의 다양한 부분 목록을 얻을 수 있다면?
하나씩 살펴보면 WebAssembly로의 전환이 더욱 흥미로워질 것입니다.

PNaCl은 NaCl에 대한 확장일 뿐입니다.

당신이 원하는 것은 무엇이든 말할 수 있지만 그것이 당신이 옳다는 것을 의미하지는 않습니다. 그것들은 완전히 다른 ISA이고 NaCL은 약간의 제한이 있는 대상 ISA(x86/arm)일 뿐인 반면 PNaCl은 추상 시스템에 대한 완전히 다른 ISA입니다.

Go는 PNaCL을 지원한 적이 없으며 Go NaCL 포트는 어쨌든 Chrome에 적합하지 않았습니다. 크롬과는 관련이 없었고 브라우저에서 사용할 수 없었습니다. Chrome이 NaCL을 포기하는지 PNaCL을 포기하는지 여부는 Go와 관련이 없습니다. 나다, nil, no 관련성 . 이 말을 몇 번을 더 해야 할까? 물론 NaCL이 완전히 포기되면 Go도 언젠가는 포기해야 합니다.

Go의 WebAssembly 지원은 NaCL과 전혀 관련이 없습니다. Go는 WebAssembly 지원을 받을 수도 있고 받지 않을 수도 있습니다. 이러한 지원을 받을 수 있는 경우 또는 NaCL 포트의 상태와 관련이 없습니다.

다음은 nacl을 사용하는 생태계의 매우 중요한 부분입니다. https://play.golang.org/p/MfJIq8wb5-

(nacl-in-a-browser가 아닌 서버 측에서 실행)

Chrome이 NaCL을 포기하는지 PNaCL을 포기하는지 여부는 Go와 관련이 없습니다. 나다, nil, 관련 없음.

그러면 누가 샌드박스 로더와 툴체인을 지원할 것입니까? WebAssembly로 노력을 전환한 Chrome 프로젝트에서 가져옵니다. Go 플레이그라운드가 이미 NaCl 샌드박스에서 WebAssembly 샌드박스로 이식될 수 있는지 확인하는 것이 현명하지 않을까요? 서버 측에서도 실행할 수 있습니다.

나는 모두가 WebAssembly를 지원하는 것에 찬성한다고 생각합니다.

NaCl에서 벗어나는 것에 대해 논의할 시간은 WebAssembly가 완전히 작동한 후입니다. 그 전에 논의할 가치가 없습니다.

@ianlancetaylor , "WebAssembly가 완전히 작동한 후"를 명확히 할 수 있습니까?

얼핏 보면 webassembly.org 에 "WebAssembly의 초기 버전이 브라우저 간 합의에 도달했습니다"라고 나와 있으며 wasm은 모든 브라우저 공급업체 의 현재 또는 미래 브라우저 버전에서 사용할 수 있습니다.

@vine77 내 말은 WebAssembly가 Go 프로그램에서 완전히 작동한 후 적어도 NaCl이 오늘날 작동하는 것처럼 말입니다.

그렇다면 WebAssembly가 Go 프로그램에서 작동하기 위해 통과해야 하는 다음 테스트는 무엇입니까?

@techtonik 여기에 약간의 혼란이 있는 것 같습니다. WebAssembly가 Go 프로그램에서 작동해야 한다는 말은 Go 컴파일러가 브라우저에서 실행할 수 있는 WebAssembly 코드를 생성해야 한다는 의미입니다. 우리는 GOOS=wasm go build hello.go 와 같은 것을 작성할 수 있어야 하고 브라우저 내에서 실행할 수 있는 프로그램을 얻을 수 있어야 한다는 것을 의미합니다. 우리는 거기에 아주 가깝지도 않습니다. 시작도 하지 않았습니다. 따라서 "다음 테스트"는 없습니다. 해야 할 일이 많습니다. 그리고 내가 아는 한 아무도 그것에 대해 적극적으로 노력하고 있지 않습니다.

@ 이안랜스테일러
golang에는 4가지 구현이 있습니다. 하나는 심각하게 인상적입니다. 링크에 대한 내 이전 의견을 참조하십시오.

Boy 이 스레드는 뒷좌석에서 아이들이 "우리 아직 거기에 있어"라고 소리치는 모습을 본 Chevy Chase 자동차와 같습니다. :)

@joeblew99 : 그 어떤 링크도 Go to WebAssembly를 컴파일할 수 있는 것이 아닙니다.
그들은 Go로 작성된 WebAssembly -> amd64 컴파일러와 같은 것입니다.

당신이 그렇게 말할까봐 두려웠어요. 그럴 수 있지.
그렇다면 "기름"에 필요한 것은 무엇입니까? 그래서 다들 알죠...
Gopherjs는 컴파일러 도구 체인 아키텍처/코드 생성에서 올바른 수준에 있지 않은 것과 같은 실수를 저질렀습니까?

긴 목록이 있습니다. 대부분은 어떤 식으로든 가비지 수집과 관련이 있습니다.

• SSA 백엔드에서 WebAssembly 코드를 생성합니다. 백엔드는 머신을 등록하는 데 사용되며 WebAssembly의 스택 머신에 적응하려면 약간의 작업이 필요합니다.
• 포인터가 뭔가요? WebAssembly에는 포인터 유형이 없습니다.
• 스택을 어떻게 내부 조사합니까? 물론 가비지 수집을 위해 필요하지만 패닉/복구, 역추적 인쇄 등에도 필요합니다.
• 고루틴을 어떻게 일시중단/재개하나요?
• 어떻게 힙을 배치할 수 있습니까? WebAssembly는 본질적으로 sbrk만 제공합니다. 보다 일반적인 주소 공간 레이아웃이 필요합니다. 범위, ptr/nonptr 비트 등에 대한 정보를 어디에 저장합니까?
• 멀티스레딩. WebAssembly에는 현재 스레드에 대한 개념이 없습니다. 예를 들어 동시 GC를 수행해야 하는 경우입니다. 잠금과 원자적 연산도 필요합니다.
• os 및 net과 같은 패키지에 대해 외부 세계에 대한 액세스를 어떻게 제공합니까?
• WebAssembly는 "goto"를 지원하지 않습니다.

그것은 아마도 완전한 목록이 아닐 것입니다.

WebAssembly가 Go 프로그램에서 작동해야 한다는 말은 Go 컴파일러가 브라우저에서 실행할 수 있는 WebAssembly 코드를 생성해야 한다는 의미입니다.

@ianlancetaylor 웹이 아닌 대상을 먼저 타겟팅하는 것이 더 쉬울까요? NaCl도 브라우저에서 먼저 실행되도록 설계되었지만 현재 Go에서 사용하는 브라우저 독립 로더가 있습니다. 브라우저가 없는 WebAssembly - http://webassembly.org/docs/non-web/ - 테스트를 위한 최소 셸에 대해 설명합니다.

@ randall77 이 목록에서 실행 가능한 체크리스트를 가져올 수 있습니까? 각 측면을 더 자세히 조사하는 문제에 대한 링크가 있는 마스터 문제처럼?

@techtonik wrt non-web: @vibhavp 는 내가 위의 몇 가지 게시물에서 언급한 GSoC 인턴십의 맥락에서 작업하고 있습니다.
저쪽에 있어요: https://github.com/go-interpreter/wagon

@techtonik : 그런 체크리스트에 대한 적절한 장소는 wasm 지원에 대한 제안 문서라고 생각합니다. 이러한 제안이 수락되고 사람들이 적극적으로 작업에 참여하면 개별 작업에 문제를 사용할 수 있습니다. 현재로서는 시기상조입니다. (제안이나 코드) 적극적으로 작업하는 사람이 아무도 없다는 것을 알고 있습니다.

제안 문서에 동의합니다.
내가 하는 모든/모순은 이 스레드에 있으며 위험/보상 균형을 단계적으로 허용하는 로드맵과 함께 함께 포장되기만 하면 됩니다.

나는 또한 그것이 나에게 아픈 엄지손가락처럼 튀어나와 있기 때문에 그래픽을 다루는 것을 보고 싶습니다.

저는 Go to JavaScript의 컴파일러인 GopherJS 의 저자입니다. 나는 브라우저에서 자바스크립트를 사용하는 것에 대한 대안, Go 및 기타와 같은 대안이 있어야 한다고 강력히 믿기 때문에 그 프로젝트를 작성했습니다. 나는 컴파일러, SSA, 기계 아키텍처 등에 대해 상당한 지식을 가지고 있지만 아직 기계 코드에 대한 컴파일러 백엔드를 작성하지 않았기 때문에 많은 세부 사항을 놓치고 있을 것입니다. 이것이 내가 완전한 제안 문서를 작성할 자격이 없다고 느끼는 이유입니다. 그래도 Go와 WebAssembly에 대한 제 생각에 대해 비판적인 피드백을 받고 싶습니다.

WebAssembly를 보면 x86이나 arm과 같은 일반적인 기계어 코드 대상과 매우 다르다는 것을 알 수 있습니다. 예를 들어 아키텍처는 레지스터 머신 대신 스택 머신입니다. 이것은 x86 및 친구들 옆에 있는 Go 컴파일러의 마지막 단계에서 단순히 또 다른 대상으로 즉시 적합하지 않다는 것을 의미합니다. 한 가지 솔루션은 거기에 두지 않고 WebAssembly 생성에 대해 상당히 다른 접근 방식을 사용하는 것일 수 있습니다. 이 접근 방식을 위한 코드는 기존 컴파일러 단계 외에 있어야 하므로 전혀 좋지 않습니다. 이 시나리오에서 컴파일러의 포크를 고려할 수도 있습니다. 요컨대: 나는 이것이 일어나는 것을 보지 못한다.

대안이 있을 수 있습니다. 필요한 것을 모방합니다. 스택 머신을 사용하여 레지스터 머신을 에뮬레이트하고 합리적으로 성능이 좋은 방식으로 수행할 수 있습니다. WebAssembly에는 로드 및 저장 명령이 있는 선형 메모리가 있어 좋습니다. 우리는 WebAssembly의 call 명령어를 전혀 사용하지 않고 대신 자체 스택 관리 및 호출 메커니즘을 사용합니다. 스택은 해당 선형 메모리에 존재하며 Go 런타임에 의해 관리됩니다. 스택 포인터는 전역 변수가 됩니다. 모든 코드는 단일 WebAssembly 함수에 있습니다. 최상위 수준은 각 기능에 대해 하나의 분기가 있는 거대한 switch 문(또는 WebAssembly의 br_table 기반 등가물)이 될 것입니다. 각 기능에는 SSA 기본 블록당 하나의 분기가 있는 또 다른 스위치 문이 있습니다. 여기서 생략하고 있는 몇 가지 세부 사항이 있지만 큰 그림에서 이것은 나에게 괜찮은 레지스터 기계처럼 보입니다. 물론 이것의 성능은 WebAssembly가 이러한 구성을 실제 기계 코드로 얼마나 잘 변환할 수 있는지에 크게 의존합니다.

그러니 말해주세요. 제가 완전히 순진하고 미쳤습니까? 그런 다음 더 많은 것을 배울 때까지 생각을 미루게 되어 기쁩니다. 그렇지 않은 경우 실제 제안 문서의 시작점이 될 수 있습니다. 감사 해요.

Go 측에서 필요한 모든 작업 외에도 Go 런타임이 대상을 지정하기 전에 WebAssembly가 필요할 수 있는 몇 가지 사항이 있습니다.

WebAssembly에는 아직 스레드가 없지만 로드맵에 있고 사양이 있습니다. https://github.com/WebAssembly/threads

가비지 수집과 관련하여 Lin Clark의 대화 https://youtu.be/HktWin_LPf4?t=28m31s 에 따르면 향후 여러 옵션이 있을 수 있을 것 같습니다.

28:31
따라서 오늘, 원한다면 코드와 함께 자신의 가비지 수집기를 제공할 수 있지만
몇 가지 이유로 느리고 커뮤니티 그룹에서 WebAssembly 코드를 가능하게 만들고 있습니다.
브라우저에 최적화된 내장 GC와 함께 사용
작업 중이므로 빠르게 실행되고 통합이 가능합니다.

gomobile과 마찬가지로 알아낼 언어 다리가 있습니다.

@randall77 은 또한 GC의 요구 사항으로 스레드를 언급했습니다. 이것이 정말 첫 번째 버전에 대한 어려운 요구 사항입니까? 동시성은 단일 스레드에서도 수행할 수 있습니다.

GC 구현과 관련하여 내 개인적인 의견은 하나의 GC가 모든 것을 지배한다고 믿지 않는다는 것입니다. Go에 Go 관련 GC가 있고 Python에 Python 관련 GC가 있는 것을 선호합니다. WebAssembly의 선형 메모리에서 자체 힙과 스택을 완전히 관리함으로써 현재 볼 수 있는 한 Go가 이미 가지고 있는 GC를 사용할 수 있어야 합니다.

@neelance 네, 여러 개의 실제 WebAssembly 스레드가 있으면 좋은 것이지 엄격한 요구 사항은 아닙니다.

WebAssembly에 대한 GC 제안은 아직 진행 중입니다. 관심 있는 당사자는 여기에서 참여할 수 있습니다.

https://github.com/WebAssembly/gc

@neelance , 컴파일러, SSA, 기계 아키텍처 등에 대해 아는 것이 없습니다. 설명하신 내용이 바이너리 크기에 어떤 영향을 미치는지 말씀해 주시겠습니까? 내가 올바르게 이해하고 있다면 크기 효율성은 WebAssembly의 상위 수준 목표 중 하나였습니다. 이 Go->WebAssembly 컴파일러도 우선 순위 중 하나여야 합니다. 맞죠?

@alxkchr 내 경험에 따르면 코드 생성 상용구로 인한 반복은 gzip을 적용하여 많이 보상될 수 있습니다. 그래도 내 제안은 바이너리 크기와 관련하여 가장 효율적인 솔루션이 아닙니다. 그래도 합리적인 시간 안에 구현할 수 있는 솔루션은 솔루션이 없는 것보다 낫지 않습니까? ;-) 또한 개인적으로 바이너리 크기는 최우선 순위가 아닙니다.

참고로 저는 이것을 구현하기 시작했습니다.

@neelance 최고의 뉴스 :) 사양을 따르십니까? (나는 희망)

고 스펙? 일반 Go 컴파일러의 새로운 백엔드/타겟이므로 사양이 이미 있습니다. ;)

나는 사양을 의미합니다 :)

https://github.com/neelance/go/tree/wasm-wip ?

@neelance

참고로 저는 이것을 구현하기 시작했습니다.

이 문제를 해결하기 위해 어떤 접근 방식을 사용할 것인지 공유해 주십시오.

우리의 현재 결론은 효과적인 구현 방법이 없다는 것입니다.
현재 setjmp/longjmp 기능이므로 실행 가능한 대상이 아닙니다.
gc 포트의. 실제 스택이 풀릴 때까지 기다려야 하고
예외 처리 지원.

(https://github.com/golang/go/issues/18892#issuecomment-276858667)

@neelance : 아직 초기 단계라는 것을 알고 있지만 wasm 이름을 GOARCH wasm32 로 지정하는 것이 더 현명할 것 같습니다(패키지도 마찬가지)

@sbinet ARM 아키텍처/패키지의 이름이 $ arm32 arm 및 arm64 (유사하게 mips 및 mips64 )이라는 점을 고려해 볼 가치가 있습니다. 및 arm64 . 그러나 그것이 좋은 예인지 나쁜 예인지는 모르겠습니다.

@SerkanSipahi 저는 처음에 V8(nodejs/chrome)을 대상으로 하고 있으며 수행할 작업에 대한 문서로 https://webassembly.github.io/spec/ 을 사용하고 있습니다.

@stuart-warren 예, 내 WIP는 해당 지점에 있습니다. 그러나 아직 사용하려고 시도하지 마십시오. 지금은 쉽게 구축할 수 없으며 복사된 코드와 스텁/핵으로 가득합니다. 알파 상태가 되면 여기에서 발표하겠습니다.

@cznic 위에서 쓴 것처럼 나는 wasm의 call 명령어를 전혀 사용하지 않고 선형 메모리에서 자체 스택을 관리하고 있습니다. 따라서 setjmp/longjmp를 구현할 수 있습니다.

@sbinet 실제로 wasm에는 64비트 연산이 있으므로 64비트 아키텍처가 됩니다.

@neelance 완전히 아닙니다. WebAssembly 사양은 현재 32비트 주소 공간만 지원 하며 wasm64 사양은 나중에 계획됩니다 .

흥미롭네요, 링크 감사합니다. 나중에 다시 살펴보고 싶을 수도 있습니다. 현재 나는 모든 것을 64비트 변수에 저장하므로 int , uint 및 uintptr 모두 64비트의 크기를 갖습니다. 그러나 처음 32비트만 메모리 주소 지정에 사용됩니다. 이것은 처음에 구현하기가 더 쉽습니다.

그것은 wasm64p32 (nacl 명명을 따르기 위해) 또는 무언가처럼 들립니다.
비슷한.

2017년 11월 4일 오전 5시 28분에 "Richard Musiol" [email protected] 이 다음과 같이 썼습니다.

흥미롭네요, 링크 감사합니다. 나중에 다시 살펴보고 싶을 수도 있습니다.
현재 나는 모든 것을 64비트 변수에 저장하므로 int, uint 및 uintptr
모두 64비트의 크기를 갖습니다. 그러나 처음 32비트만 사용됩니다.
메모리 주소 지정. 이것은 처음에 구현하기가 더 쉽습니다.

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/golang/go/issues/18892#issuecomment-341889653 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AAgwpPTbfHRmoYNXLQfcPMVnARxb0UGrks5szEpjgaJpZM4L0o7D
.

그것은 wasm64p32 (nacl 명명을 따르기 위해) 또는 무언가처럼 들립니다.
비슷한.

나는 오직 하나의 아키텍처(주소 공간 크기 선택 포함)만 있을 것이기 때문에 두 개의 숫자를 갖는 것이 의미가 없다고 생각합니다. webassembly.org 에서 :

wasm32와 wasm64는 둘 다 모듈 헤더의 플래그에 의해 선택되는 WebAssembly의 모드일 뿐이며 선형 메모리가 처리되는 방식 이외의 의미론적 차이를 의미하지 않습니다.

나는 오직 하나의 아키텍처(주소 공간 크기 선택 포함)만 있을 것이기 때문에 두 개의 숫자를 갖는 것이 의미가 없다고 생각합니다. webassembly.org에서:

wasm32와 wasm64는 둘 다 모듈 헤더의 플래그에 의해 선택되는 WebAssembly의 모드일 뿐이며 선형 메모리가 처리되는 방식 이외의 의미론적 차이를 의미하지 않습니다.

열망하는 발언입니다. 사실로 판명될 수도 있지만 WebAssembly CG/WG는 그 진술이 정확하다고 확신할 만큼 wasm64를 충분히 탐색하지 않았습니다.

@neelance가 작동하도록 합시다. 이름은 나중에 변경하기 쉽습니다.

Go가 기계 명령(AFAIK)으로 직접 컴파일된다는 것을 알고 있지만 누군가 Go를 C로 컴파일한 적이 있는지 스스로 궁금합니다. Go --> C --> wasm을 시도하는 것은 흥미로울 것입니다(매우 효율적이지는 않지만).

@TomerHeber 컴파일이 아닌 C++로의 번역 형태로 가능할 수 있지만 아마도 이것은 wasm 자체에 대한 컴파일보다 더 많은 작업이 될 것입니다

안녕하세요 여러분. 여기 내 작업에 대한 업데이트가 있습니다. 나는 지금까지 Go 팀과 기여자들의 훌륭한 작업 덕분에 매우 좋은 진전을 이루고 있습니다. 대부분의 코드는 아키텍처/플랫폼 간에 공유되므로 구현해야 할 필요가 예상보다 많지 않았습니다.

다음은 이미 잘 작동하는 몇 가지 목록입니다.

• 브라우저와 Node.js에서 생성된 wasm 코드 실행
• 기본 작업, 변환 등
• 인터페이스
• 고루틴과 채널
• 연기/공황/구출
• Node.js를 사용할 때 디스크에서 파일 읽기
• 다음 패키지의 테스트가 통과하고 있습니다. bytes, container/heap, container/list, container/ring, encoding/ascii85, encoding/asn1, encoding/base32, encoding/binary, encoding/csv, encoding/hex, errors, flag, hash/adler32, hash/crc32, hash/crc64, hash/fnv, html, image, image/color, index/suffixarray, math, math/bits, path, sort, strconv, strings, text/scanner, text/tabwriter, unicode, unicode/utf8, unicode/utf16

아직 작업이 필요한 몇 가지 사항:

• 반사
• 고루틴 스택 늘리기
• 가비지 컬렉션
• 성능 최적화
• wasm 파일 크기 최적화
• 멋진 JS interop 레이어
• 더 많은 패키지 테스트를 통과하기 위한 다른 많은 문제

나는 한 달 반 동안의 진행 상황에 대해 매우 기쁩니다. 그리고 여가 시간에만 가능합니다. Go 1.11에 이것을 넣을 수 있는 좋은 기회가 있다고 생각합니다. 1월에 다음 업데이트를 기대하세요. 제가 휴가를 다녀온 후 휴일이 있기 때문입니다.

이러한 작업 중 일부를 병렬화할 수 있습니까? 일부 비트는 휴일 해킹에 흥미로워 보입니다.

자유롭게 살펴보고 내 포크에 PR을 작성하십시오. Gophers Slack에서도 저를 찾을 수 있습니다.

조사 영역 중 하나는 스택 사용을 최적화하는 것입니다. 지금은 레지스터 할당 단계에서 모든 작업에 대해 레지스터(wasm의 로컬 변수)를 할당합니다. get_local 및 set_local 는 항상 모든 작업 전후에 사용됩니다. 값이 나중에 일부 작업에서 사용하기 위해 스택에 남아 있을 수 있는 경우에는 필요하지 않습니다. 의사 레지스터 REG_STACK 를 추가하고 이 레지스터가 사용되는 경우 명령어 생성기가 get_local 및 set_local 를 건너뛰도록 하는 것이 좋습니다. 그런 다음 적절한 경우 regalloc 가 이 레지스터를 사용하도록 합니다.

답장:

멋진 JS interop 레이어

현재 wasm에 대해 이것을 구현하는 올바른 방법이 있습니까? 나는 Dom/js interop이 wasm을 여전히 사용할 수 있는 방법이라고 생각했습니다. 이것이 가능하다면 그것은 엄청날 것입니다!

float64 및 int32 인수를 가질 수 있는 함수를 가져오고 내보낼 수 있으며 공유 선형 메모리가 있습니다. 다른 모든 것은 그 주위에 구축될 수 있습니다. 가비지 수집 만 그렇게 좋지 않을 것입니다.

(나는 이것을 (@neelance) 리포지토리에 게시하려고 했지만 문제를 게시하는 방법을 알 수 없었습니다...)

js.foo 호출/가져오기 대신 wabt 툴체인을 사용할 수 있습니까?
전체 nodejs 설치 대신 wabt 와 상호 작용하는 것이 더 쉽다는 것을 알았습니다. :)

(여기서 a.wasm 로 번역된 간단한 main.go 프로그램도 해석하려고 합니다: go-interpreter/wagon#36...)

내 포크에서 문제를 활성화했습니다. 자유롭게 게시하세요.

나는 당신의 질문을 정말로 이해하지 못합니다. wasm-interp 말씀하시는 건가요? wasm 바이트코드를 컴파일 및 실행해야 하고 나머지 시스템과 상호작용할 수 있는 JS 환경이 필요합니다(예: 콘솔로 인쇄하기).

Btw: https://github.com/neelance/go/tree/wasm-wip/misc/wasm을 보셨습니까?

이것은 훌륭합니다. Go to wasm을 컴파일하고 실행하려는 사람들을 위해 -

1. 콘솔에 출력하는 간단한 hello world 프로그램을 만듭니다.
2. GOOS=js GOARCH=wasm ./bin/go build -o out.wasm wasm.go
3. ./misc/wasm/go_js_wasm_exec out.wasm

즐기다 !

go_js_wasm_exec 를 PATH에 연결하면 go run 를 사용할 수도 있습니다. ;-)

여러분, Go for WASM의 가비지 컬렉션 상황은 어떻습니까? 우리 는 Crystal을 가져오는 것에 대해 이야기하기 시작했으며 Crystal은 Go가 현재 GC와 동일한 문제를 공유하고 있는 것으로 보입니다. 이 상황에서 WebAssembly 작업 그룹을 협력하거나 도울 수 있는 방법이 있습니까?

위에 언급된 스레드에 자유롭게 참여하거나 이 문제에 대해 채팅/협업할 수 있는 곳을 알려주십시오.

WASM이 이 영역에서 성숙하기 전까지는 현재로서는 Opal 경로가 더 건전한 접근 방식일 수 있지만 그 경로를 따라 가기 전에 확실히 아는 것이 좋습니다.

안녕하세요 여러분, 많은 기본 코드가 관련이 있다고 생각한 이후로 지난 몇 달 동안 작업한 내용을 공유하고 싶었습니다. https://github.com/matthewmueller/joy

지금은 JS(ES3)를 대상으로 하고 있지만 컴파일러는 모든 선언(함수, 변수 등)에 대해 종속성 그래프를 구현합니다. 그런 다음 그래프를 정렬하고 프로그램에서 사용되는 선언만 변환합니다.

이 그래프를 사용하여 WebAssembly를 대상으로 하는 것은 그리 어렵지 않을 것이라고 생각합니다. 저는 제가 할 수 있는 한 어떻게든 돕고 협력하고 싶습니다.

자세한 내용은 관련 링크를 참조하십시오.

• https://mat.tm/joy/#faq -웹어셈블리
• https://mat.tm/joy/#how

위의 Crystal에 대한 GC 문제와 관련하여 Go에 대한 응용 프로그램이 있을 수도 있습니다. @kripken 의 설명과 다음 토론을 참고하세요. https://github.com/WebAssembly/binaryen/issues/1312#issuecomment -348409211

잠재적으로 https://github.com/AppCypher/webassemblylanguage?

모두들 즐거운 연휴 보내셨길 바랍니다. 약속된 업데이트는 다음과 같습니다.

마지막 업데이트 이후로 반사, 스택 증가 및 가비지 수집을 시작하고 실행할 수 있었습니다. 추가 개선 사항으로 136개의 stdlib 패키지 중 104개의 테스트가 현재 통과하고 있습니다. 또한 많은 컴파일러 테스트가 녹색입니다. 좋은 진행!

저는 현재 기능 지원 및 정확성에 집중하고 있음을 명심하십시오. 아직 성능이나 출력 크기에 대한 최적화를 수행하지 않았습니다.

나는 실험에 박수를 보냅니다. (그리고 Promise 에 비해 뛰어난 고루틴에 대한 GopherJS의 @neelance ty , 당신은 아마도 저를 C++에서 구해 냈을 것입니다!), 그래서 다음은 단지 잠재적으로 유용한 정보를 추가하려는 시도일 뿐입니다. 아마도 Go와 WASM 대상 간의 불일치에 대한 인식을 높이기 위해서일 수도 있습니다. 또한 잠재적으로 일부 독자를 위해 문제를 명확히 할 수 있습니다. 또한 고루틴과 같은 것을 WASM으로 컴파일하는 방법에 대해 독립적으로 생각할 때 찾은 다음 @rossberg 인용문을 덤프할 적절한 장소를 원했기 때문입니다.

@neelance 는 다음과 같이 대답 했습니다.

@cznic은 다음과 같이 대답 했습니다.

@neelance 는 다음과 같이 썼습니다 .

WebAssembly의 call 명령을 전혀 사용하지 않고 대신 자체 스택 관리 및 호출 메커니즘을 사용합니다. 스택은 해당 선형 메모리에 존재하며 Go 런타임에 의해 관리됩니다. 스택 포인터는 전역 변수가 됩니다. 모든 코드는 단일 WebAssembly 함수에 있습니다. 최상위 수준은 각 기능에 대해 하나의 분기가 있는 거대한 switch 문(또는 WebAssembly의 br_table 기반 등가물)이 될 것입니다. 각 기능에는 SSA 기본 블록당 하나의 분기가 있는 또 다른 스위치 문이 있습니다.

다음과 같은 문제를 해결하기 위해 어떤 접근 방식을 사용할 것인지 공유해 주십시오.

@minux 는 다음과 같이 썼습니다 .

우리의 현재 결론은 효과적인 구현 방법이 없다는 것입니다.
현재 setjmp/longjmp 기능이므로 실행 가능한 대상이 아닙니다.
gc 포트의. 실제 스택이 풀릴 때까지 기다려야 하고
예외 처리 지원.

@cznic 위에서 쓴 것처럼 나는 wasm의 call 명령어를 전혀 사용하지 않고 선형 메모리에서 자체 스택을 관리하고 있습니다. 따라서 setjmp/longjmp를 구현할 수 있습니다.

WASM의 "공동 디자이너" 및 "사양 작성자" 에 따르면 call 에 대한 제한은 Go에 적합하지 않으며 보안/안전과 관련이 있습니다.

@rossberg 는 다음과 같이 썼습니다 .

반환 주소(*)를 구체화할 방법이 없기 때문에 호출 스택을 쉽게 "교체"할 수 없습니다. 그러나 필요한 경우 선형 메모리에서 로컬 변수에 대한 섀도 스택을 구현할 수 있습니다.

사실, WebAssembly는 현재 내장 "스택"의 개념을 전혀 노출하지 않습니다. 다른 많은 디자인 결정과 마찬가지로 이것이 중요합니다. Wasm은 웹에서 실행되기 때문에 "안전"해야 합니다. 그렇기 때문에 유형이 지정되고, 정의되지 않은 동작이 없으며, 코드가 메모리에서 분리되고(주소를 지정할 수 없음), 함수 유형에 대한 캐스트가 확인됩니다. 함수의 명시적 개념을 갖는 것은 효과적인 레지스터 할당, 병렬 또는 지연과 같은 다른 이점도 가능하게 합니다. 컴파일, 유용한 디버그 도구 등

제어 흐름은 실제로 반구조적입니다. 분기는 실제로 중단되고 계속될 뿐이므로 축소할 수 없는 제어 흐름을 구성할 수 없습니다. 그것도 특징입니다.

[…]

(*) 전체 프로그램을 단일 루프 함수로 컴파일하여 인덱스가 있는 명시적 반환 주소를 거대한 테이블 점프로 에뮬레이트할 수 있을 것입니다. 그러나 그것은 아마도 꽤 느리고 WebAssembly 생태계의 많은 부분을 무너뜨릴 것 입니다.

따라서 @neelance 가 시도하는 WASM 생태계와의 성능 및 상호 운용성은 차선책이 될까요?

@neelance의 GopherJS 성능 최적화 기술을 인용합니다.

"WASM 생태계와의 상호 운용성"이 무엇을 의미하는지 모르기 때문에 이에 대해 언급할 수 없습니다. 성능과 관련하여 다음과 같이 말할 수 있습니다.

예, 현재 접근 방식은 WebAssembly에서 제어 흐름을 표현하는 가장 최적의 방법은 아니지만 오늘날 작동합니다. 아마도 미래에는 WebAssembly의 call 명령어를 더 많이 사용하는 것이 가능할 것입니다. 하지만 이를 위해서는 WebAssembly가 몇 가지 기능을 더 추가해야 하며 Go 측에서 더 많은 작업이 필요합니다. 나는 100%가 있지만 가상에 불과한 것보다 실제로 작동하는 성능의 80%가 있는 것을 원합니다. ;-)

더 자세한 기술 정보에 관심이 있으시면 https://invite.slack.golangbridge.org/의 #webassembly에서 저에게 이야기하십시오.

"WASM 생태계와의 상호 운용성"이 무엇을 의미하는지 모르기 때문에 이에 대해 언급할 수 없습니다.

아마도 @rossberg 가 _"WebAssembly 에코시스템의 많은 부분을 물리친다"_로 언급한 것은 call 및 보호된 호출 스택을 본질적으로 에뮬레이션하지 않는 에코시스템의 도구 및 기타 언어와의 상호 운용성입니다. switch 테이블을 사용하는 자신의 연속 작업?

하지만 이를 위해 WebAssembly는 몇 가지 기능을 더 추가해야 합니다.

나는 WASM Promise 고루틴(녹색 스레드)이 있는 언어를 더 잘 수용할 수 있기를 바랍니다.

나는 100%가 있지만 가상에 불과한 것보다 실제로 작동하는 성능의 80%가 있는 것을 원합니다. ;-)

오, 전적으로 동의합니다. 그렇기 때문에 이전 게시물에 귀하의 많은 노력에 박수를 보냅니다.

웹/WASM에서 더 대중적일수록 Go 또는 녹색 스레드가 있는 다른 언어를 만들 수 있습니다. 그러면 궁극적으로 더 나은 성능을 위해 더 나은 WASM 기본 요소(예: gcc의 -fsplit-stack ?)를 얻을 가능성이 더 높아집니다. .

귀하의 구현이 WASM의 현재 한계 내에서 최적의 성능의 80%를 진정으로 달성한다면 나는 즐겁게 놀랄 것입니다. 성능 결과가 지나치게 나쁘면 JavaScript Promise 콜백 기반 모델에 비해 그린 스레드의 인기를 입증하는 데 제한이 있을 수 있습니다("WebAssembly 에코시스템의 대부분을 무찌른다"는 아이러니의 가능성이 있다고 가정한다면). 디자인은 JavaScript 최적화에 대한 우선 순위에 의해 주도되었습니다 :-) .

또한 저는 typeclass 제네릭을 Go에 트랜스파일러로 추가하는 것을 고려하고 있습니다(그리고 Go 2에 대한 제네릭 제안에 대한 분석 제공). 인기.

@shelby3 텍스트를 읽을 수 없을 정도로 작게 만드는 서식 사용을 중지하십시오. 어떤 것이 사람들이 읽을 가치가 없다고 생각한다면 애초에 쓰지 마십시오. 숨겨진 내용에 대한 힌트를 제공하지 않고 읽을 수 없도록 만드는 것은 독자가 암호를 해독하는 데 두 배(또는 그 이상) 시간을 소비하게 만듭니다. 원래 의도와 반대라고 생각합니다.

@shelby3 작은 텍스트 서식을 사용하지 않도록 게시물을 수정했습니다. 그만 하세요.

https://golang.org/cl/102835 에서 이 문제를 언급 변경: go/build, cmd/dist: add js/wasm architecture

https://golang.org/cl/103255 에서 이 문제를 언급 변경: wasm: add scripts for running WebAssembly binaries

https://golang.org/cl/103256 에서 이 문제를 언급 변경: cmd/compile: add SSA config options noAvg and noHmul

https://golang.org/cl/103275 에서 이 문제를 언급 변경: cmd/compile/internal/gc: factor out beginning of SSAGenState.Call

변경 https://golang.org/cl/103295 에서 이 문제를 언급합니다. cmd/compile: add wasm architecture

변경 https://golang.org/cl/103535 에서 이 문제를 언급합니다. cmd/compile: wasm stack optimization

https://golang.org/cl/103795 에서 이 문제를 언급 변경: cmd/link: add wasm architecture

https://golang.org/cl/103877 에서 이 문제를 언급 변경: runtime: add js/wasm architecture

https://golang.org/cl/103915 에서 이 문제를 언급 변경: internal/bytealg: add wasm architecture

좋아, 많은 CL이 날아가기 시작한 것 같다.
이식 정책과 관련하여 우리는 어떻게 하고 있습니까: https://github.com/golang/go/wiki/PortingPolicy ?
특히, 건축업자는 어떤 모습일까요?
@neelance 에서 포트 유지 관리에 가입한다고 가정합니까?
(CL 중 하나가 이 모든 것을 철자한 경우 사과드립니다. 저는 모두 읽지 않았습니다.)

예, 항구를 유지하겠습니다. @bradfitz 는 현재 빌더 설정을 검토 중입니다.

https://golang.org/cl/106995 에서 이 문제를 언급 변경: sync/atomic: add wasm architecture

https://golang.org/cl/106996 에서 이 문제를 언급 변경: math: add wasm architecture

https://golang.org/cl/106997 에서 이 문제를 언급 변경: time: add wasm architecture

https://golang.org/cl/106998 에서 이 문제를 언급 변경: mime: add wasm architecture

https://golang.org/cl/109195 에서 이 문제를 언급 변경: syscall/js: add package

https://golang.org/cl/109976 에서 이 문제를 언급 변경: syscall: enable some nacl code to be shared with js/wasm

https://golang.org/cl/109977 에서 이 문제를 언급 변경: os: add js/wasm architecture

https://golang.org/cl/109995 에서 이 문제를 언급 변경: net: add js/wasm architecture

https://golang.org/cl/110095 에서 이 문제를 언급 변경: crypto: add js/wasm architecture

https://golang.org/cl/110096 에서 이 문제를 언급 변경: all: skip unsupported tests for js/wasm

변경 https://golang.org/cl/112736 에서 이 문제를 언급합니다. env/js-wasm, dashboard: add start of a js-wasm builder

https://golang.org/cl/113515 에서 이 문제를 언급 변경: misc/wasm: make wasm_exec.js more flexible

Go 문서의 웹 어셈블리 아키텍처, 특히 Node의 'fs' 모듈을 기반으로 하는 JavaScript syscall 구현에 대한 웹 어셈블리 아키텍처를 읽은 후 브라우저 측에서는 대부분 구현되지 않았습니다. _new_ 브라우저 API? 특히, FileSystem API 사양은 적어도 일부 시스템 호출을 지원할 수 있는 것처럼 보입니다. (FileSystem은 여전히 ​​Editor's Draft이며 FireFox, Chrome 및 Opera에서만 구현됩니다. 또한 후자의 두 가지에 접두사가 'webkit-'입니다.)
이것이 괜찮은 접근 방식이라고 생각한다면 개념 증명을 시도할 수 있습니다.

https://golang.org/cl/114197 에서 이 문제를 언급 변경: runtime, sycall/js: add support for callbacks from JavaScript

안녕하세요 여러분, 저는 @neelance 가 수행한 작업을 사랑하고 있으며 이 WASM 구현(예: 첫 번째 릴리스)으로 cgo 도 사용할 수 있는지 궁금합니다. C 코드를 포함하고 GO로 컴파일하고 WASM으로 컴파일합니다. 그것은 빌어먹을 초강대국이 될 것입니다. 당신은 모두 멋진 일을하고 있습니다. 엄청난.

@cmaster11 마음 에 드셨다니 다행입니다. :) 귀하의 질문에: cgo 는 C를 Go로 컴파일하지 않고 대신 두 언어를 각각의 컴파일러를 사용하여 기계어로 컴파일한 다음 결과를 단일 바이너리로 병합합니다. 이미 emscripten을 사용하여 C 코드를 WebAssembly로 컴파일할 수 있습니다. 이론상으로는 런타임에 두 WebAssembly 바이너리를 로드하고 상호 작용할 수 있어야 합니다. 그러나 Go 프로젝트가 가까운 장래에 이 사용 사례를 촉진하는 데 시간을 할애할 것 같지는 않습니다.

대부분 밀레니얼 세대인 듯

@shelby3 나는 아마도 당신보다 나이가 많고 당신을 반대합니다. 여기서 문제는 단순히 의사 소통 능력이 없다는 것입니다.

권력의 문제가 아닙니다. @andybons 는 실제로 다른 사람들이 읽을 수 있도록 게시물을 편집하여 귀하에게 호의를 베풀었습니다.

webidl이 없는 js/wasm 지원은 웹 브라우저 내에서 다른 언어와 많은 상호 운용이 불가능함을 의미합니다. was Architecture는 webidl에 대해 언급하지 않은 것 같습니다.

다음과 같이 C++ Foo 클래스에 적용했을 때 emscripten webidl python 도구를 잘 살펴보았습니다.
Foo 클래스와 같은 방식으로 webidl을 통해 golang duck 유형이 노출되는 것을 보고 싶습니다.
그 근거는 동시에 로드되는 다른 wasm 모듈과 상호 운용되지만 마샬링 스텁을 포함하고 호출할 수 있으려면 idl을 사용할 수 있어야 합니다. 그렇지 않으면 다른 wasm 파일에서 사용할 수 있는 호출 서명을 결정하기 위해 일종의 개체 뷰어가 필요합니다.

python /usr/lib/emscripten/tools/webidl_binder.py Foo.idl glue
This generates:
glue.cpp
glue.js
WebIDLGrammar.pkl

emcc -v Foo.cpp my_glue_wrapper.cpp --post-js glue.js -o output.js
This generates:
output.js
output.wasm

emrun --list_browsers
emrun --browser chrome handcrafted_Foo.html 
emrun --browser firefox handcrafted_Foo.html 
firefox handcrafted_Foo.html &
chrome handcrafted_Foo.html &

$ cat Foo.h

#ifndef FOO_H
#define FOO_H (1)

class Foo {
public:
  int getVal();
  void setVal(int v);
 private:
  int nValue;
};

#endif

$ cat Foo.cpp

#include "Foo.h"

int Foo::getVal() {
  return nValue;
}

void Foo::setVal(int v) {
  nValue = v;
}

$ cat my_glue_wrapper.cpp

#include "Foo.h"
#include "glue.cpp"

$ cat Foo.idl

interface Foo {
        void Foo();
        long getVal();
        void setVal(long v);
};

$ cat handcrafted_Foo.html

<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>WebAssembly Sample</title>
  </head>

  <body>
    <h1>Web Assembly</h1>

    <div class="output">
        <pre id="log"></pre>
    </div>

    <script src="output.js"></script>
    <script>      
      "use strict";


    function log() {
        document.querySelector('#log').textContent += Array.prototype.join.call(arguments, '') + '\n';
    }

    Module.onRuntimeInitialized = _ => {
      log(`blah `);
      var f = new Module.Foo();
      f.setVal(200);
      alert(f.getVal());
      log(`blah `);
    };

    </script>

  </body>
</html>

@ omac777 , 다른 언어와의 상호 운용성은 Go의 1.11 초기 WebAssembly 지원의 목표가 아닙니다.

확인. webidl이 단기 목표가 아니라는 것을 이해할 수 있지만 wasm 출력을 유용하게 만드는 방법에 대한 질문이 있습니다. 먼저 idl과 함께 emscripten C++와 함께 사용하기 위해 위에서 정의한 위의 Foo 클래스로 돌아갑니다. 거기에 맞는 골랑오리 타입을 만들었다고 해봅시다. 그런 다음 C++ Foo SetVal 및 GetVal 구현에서 호출할 수 있도록 해당 함수를 C 함수로 내보냅니다. 결과적으로 속도가 느려질 것이라는 것을 알고 있지만 모든 구현을 go 내에서 구축하는 것이 장기적인 목표가 될 것입니다.

foo.go.wasm.a 및 foo.go.wasm.so는 어떻게 생성합니까? 모든 foo.wasm에는 자체 foo.go.js가 필요합니까?
다른 foos로 가득 찬 라이브러리가 생성되면 otherfoos.go.a.js도 생성됩니까?

go.wasm.a 및 go.wasm.so를 다음에 지정된 대로 생성된 emcc output.wasm에 어떻게 연결합니까?
emcc -v Foo.cpp my_glue_wrapper.cpp --post-js glue.js -o output.js foo.go.wasm otherfoos.go.wasm.a

예를 들어 go 내에서 wasm에서 emcc가 지원하는 sdl 기능에 연결하는 방법.

전체 고루틴, MAXCPUCores, 채널에 대한 지원은 언제 wasm에 대해 나타납니까?
다시 한번 감사합니다.

@ omac777 , Go 1.11의 범위는 다음과 같습니다.

Go 코드는 WebAssembly 모듈로 컴파일되고 브라우저에서 실행되며 JavaScript 간에 앞뒤로 호출할 수 있습니다.

*.a 또는 *.so 파일이나 C 또는 GCC 또는 emcc 또는 SDL과의 상호 운용성에 대한 모든 것을 무시하십시오. 그 중 어느 것도 범위에 없으며 작동하지 않습니다.

전체 고루틴, MAXCPUCores, 채널에 대한 지원은 언제 wasm에 대해 나타납니까?

고루틴과 채널을 완벽하게 지원합니다(이는 Go의 일부이며 필수임). WebAssembly는 MAXCPUCores 가 의미하는 경우 단일 코어만 지원합니다. 이것은 Go나 Go의 WebAssembly 지원의 한계가 아닙니다.

그래서 당신은 내가 곧 이런 것을 볼 수 없다는 말입니까?
GOARCH=wasm GOOS=js go build -o awesome.wasm.so -buildmode=c-shared foo.go

따라서 4개의 코어 또는 20개의 코어가 있는 웹 브라우저가 있는 경우 go 생성된 wasm은 웹 브라우저에서 해당 코어 중 하나만 사용할까요? 나는 그것이 go or go webassembly 지원의 제한이 아니라는 것을 어떻게 설명하는지 이해하지 못합니다. WEBASSEMBLY.org 사양 자체의 한계라고 말씀하십니까?

@ omac777 - 예, 현재 Go 구현이 아니라 WebAssembly 자체의 한계라고 생각합니다.

@omac777 WASM의 멀티스레딩 지원은 진행 중인 작업이며 브라우저에서 출시될 때까지 시간이 걸릴 것입니다.

https://github.com/WebAssembly/threads/blob/master/proposals/threads/Overview.md

그래서 당신은 내가 곧 이런 것을 볼 수 없다는 말입니까?
GOARCH=wasm GOOS=js go build -o Awesome.wasm.so -buildmode=c-shared foo.go

아마도 Go 1.12에 있을 것입니다.

C/C++를 호출하는 Go의 경우 JavaScript로 C 함수를 래핑한 다음 Go 1.11을 사용하여 Go에서 JavaScript 래퍼를 호출하는 것이 가능할 것이라고 생각합니다.

나는 이것이 스레드의 일부가 아니라는 것을 알고 있지만 go v1.11에서 WebAssembly(컴파일 등)를 사용하는 방법에 대한 문서/자습서가 있습니까?

@SerkanSipahi 아직 아닙니다. 그러나 릴리스 전에 문서가 있을 것입니다.

@SerkanSipahi 나는 https://blog.lazyhacker.com/2018/05/webassembly-wasm-with-go.html에서 작동시키기 위해 취한 단계를 기록했습니다.

여전히 관련성이 있는 이 게시물도 있습니다.
https://blog.gopheracademy.com/advent-2017/go-wasm/

우리는 (IIRC) wasm 모듈의 export 섹션에 들어가는 것에 대한 매핑(또는 메커니즘)을 정확히 지정하지 않았습니다.

#25612를 제출했습니다.

wasm 대상을 사용하여 다음으로 이동하는 방법을 명확히/문서화하십시오.
- go를 사용하여 다른 언어에서 사용할 수 있도록 wasm으로 go 기능을 내보내거나 가져옵니다.
- sdl2/webgl/qt를 golang 바이너리에 연결
-모든 sdl2/webgl/qt 이벤트 잡기
- 루프에 있는 경우 절전 모드로 CPU 시간을 OS로 일시적으로 양도합니다. 예를 들어
emscripten emscripten_sleep(10)

go 도구의 output.html 파일은 output.html이 성공적으로 빌드된 경우에도 firefox/chrome 모두에서 일관되게 성공하지 않는 것 같습니다. output.html이 작동하도록 하려면 더 많은 작업을 수행해야 합니다. 성공이라고 하기 전에.

@ omac777 , 우리는 위의 대부분을 해결했습니다. 그러나 다른 사람들을 위해:

wasm 대상을 사용하여 다음으로 이동하는 방법을 명확히/문서화하십시오.
- go를 사용하여 다른 언어에서 사용할 수 있도록 wasm으로 go 기능을 내보내거나 가져옵니다.
- sdl2/webgl/qt를 golang 바이너리에 연결
-모든 sdl2/webgl/qt 이벤트 잡기

위의 내용 중 어느 것도 Go 1.11의 범위에 포함되지 않습니다. 지원되지도, 문서화되지도 않으며, 가능하지도 않을 것입니다.

- 루프에 있는 경우 절전 모드로 CPU 시간을 OS로 일시적으로 양도합니다. 예를 들어

@neelance 는 JS와 Go 스케줄러 간의 콜백 및 상호 운용성을 얻었으므로 일반 time.Sleep 및 친구는 예상대로 작동해야 합니다.

나는 Go 1.11이 이것들 중 어느 것도 가지지 않을 것이라는 것을 이해하지만, 위의 어떤 것이 go에 대해 얼마나 멀리/오래 고려될 것인가. qt가 go와 깔끔하게 통합되는 것을 보고 싶어하는 사람들이 있으며 현재 상황은 해당 레서피/qt에 대해 타사에 의존하고 있다는 것입니다. 이는 모두 좋지만 제한 사항이 있습니다(현재 wasm qt 및 qt 64비트 arm 타겟 없음 지원). autocad에는 emscripten, C++ 및 react를 사용하는 Windows 및 macos용 웹 어셈블리 솔루션이 있습니다. 나는 여전히 golang이 C++를 사용할 수 있는 곳과 달리 특정 사용 영역에서 여전히 제약을 받고 있다고 생각합니다.

C++의 접근 방식에는 많은 힘이 있습니다.
emcc --clear-cache --clear-ports
em++ -v -std=c++1y hello_world_sdl.cpp -s USE_SDL=2 -s USE_SDL_IMAGE=2 EMTERPRETIFY=1 -s EMTERPRETIFY_ASYNC=1 -s WASM=1 -o hello_world_sdl.html

왜 golang은 비슷한 행동을 할 수 없습니까?
업데이트: 정정합니다. Golang은 go 코드에 포함된 cgo 컴파일 지시문 때문에 "-s" 스위치가 필요하지 않습니다.

그러나 다른 golang 빌드 버전(예: go1.9에서 go1.10)으로 마이그레이션할 때 버그가 발생할 수 있으므로 캐시 지우기와 포트 지우기는 좋은 생각입니다. go1.10.3에서 go1.11(vgo 라이프스타일로 마이그레이션할 때). 나는 최근에 go build 버전 사이에 "go build -"를 수행해야 했습니다.
GOARCH=wasm GOOS=js go --clear-cache --clear-ports

왜 golang은 비슷한 행동을 할 수 없습니까?
GOARCH=wasm GOOS=js go --clear-cache --clear-ports

FWIW, Go의 캐시는 정확성을 위해 명시적으로 지울 필요가 없습니다.

@neelance - 이제 콜백이 들어왔으므로 기본 지원이 완료되었다고 생각합니다. 이 버그를 닫아야 할까요? 아니면 염두에 둔 다른 것이 있습니까?

예, 이제 닫을 수 있습니다. 🎉

훌륭한 일!!! @neelance

이것은 굉장하고 훌륭한 작품입니다 @neelance!

https://golang.org/cl/120057 에서 이 문제를 언급 변경: doc/go1.11: mention GOOS/GOARCH values of WebAssembly port explicitly

https://golang.org/cl/120575 에서 이 문제를 언급 변경: cmd/dist: skip non-std tests on js/wasm

파일 크기 줄이기에 대한 문제를 여는 것이 적절합니까(가능한 경우)? 아니면 다른 곳에서 추적되고 있습니까?

@matthewp 원하는 경우 웹 어셈블리별 크기 버그를 자유롭게 여십시오. 일반적인 것은 #6853입니다.

https://golang.org/cl/120958 에서 이 문제를 언급 변경: net: re-implement built-in simulated network on JS and NaCl

golang 컴파일러에 제어 흐름 무결성(CFI)이 내장되어 있습니까? 나는 최근에 clang 컴파일러에 내장된 CFI로 방지된 WASM의 취약점과 관련하여 다음을 살펴보았습니다.
https://www.fastly.com/blog/hijacking-control-flow-webassembly-program
https://github.com/trailofbits/clang-cfi-showcase/blob/master/cfi_vcall.cpp

대충 훑어보니 글이 "WebAssembly는 JavaScript와 같은 고급 언어가 아니라 저급 언어이므로 소스 언어(C 또는 Go)에서 허용하는 경우 특정 클래스의 버그가 적용될 수 있습니다. ." 놀라움이 없습니다. 즉, Go에 이러한 문제가 있으면 WebAssembly뿐만 아니라 다른 아키텍처에도 적용됩니다.

WebAssembly는 대부분 사악한 WebAssembly 코드로부터 브라우저를 보호하는 것입니다. WebAssembly 인스턴스 내에서 보장을 제공하는 것은 그다지 중요하지 않습니다(일부는 있기는 하지만). @neelance 가 말했듯이 필요한 안전 보장을 제공하는 것은 LanguageX->WebAssembly 컴파일러에 달려 있습니다.
Go에는 CFI가 없습니다. 나는 그것이 쉽지 않을 것이라고 생각합니다. 메소드가 시작되는 지점에서 우리는 이미 vtable을 잃어버렸습니다. vtable이 사용되었다는 사실조차 잊어버렸습니다.
Go는 병렬 처리가 있는 경우 이 익스플로잇에 취약합니다. 현재로서는 적어도 WebAssembly Go 포트(및 WebAssembly, 마침표)에는 병렬 처리가 없으므로 이 익스플로잇은 이론적일 뿐입니다. 그러나 WebAssembly 사람들은 어느 시점에서 병렬 처리를 구현할 계획입니다.

@randall77 이것이 일반 linux/amd64 에 어떤 영향을 줍니까? WebAssembly의 경우 위험이 더 큽니까?

위험은 아키텍처에 관계없이 동일합니다(WebAssembly에는 아직 스레드가 없으므로 현재로서는 WebAssembly에 대해 실제로 0입니다). 데이터 경쟁은 unsafe 를 가져오지 않고 unsafe 를 시뮬레이션하는 데 사용할 수 있습니다.
그러한 취약점을 악용하는 것은 어려울 것입니다. 신뢰할 수 없는 코드로 링크하거나 인터페이스 값에 대한 데이터 경합을 수행하는 기존 바이너리에서 가젯을 찾아 트리거한 다음 결과에서 메서드를 호출해야 합니다.

자, Go 코드에 데이터 경합이 없다면 괜찮을 것입니다. 또한 WebAssembly로 신뢰할 수 없는 코드를 실행할 때 데이터 경쟁이 있거나 단순히 unsafe 를 사용할 수 있더라도 WebAssembly 환경을 벗어날 수 없도록 할 수 있습니다. 흥미로운 통찰력에 감사드리며 이 문제의 주제에서 약간 벗어난 점에 대해 유감스럽게 생각합니다.

golang 내에서 이 javascript 사용법을 더 많이 조사할수록 golang 코드의 품질과 장기적인 유지 관리를 저하시키는 감염으로 더 많이 인식하게 됩니다. 설명하겠습니다. 다음은 인상적인 눈 사탕 마술을 수행하는 멋진 wass golang 앱의 예입니다.

https://github.com/stdiopt/gowasm-experiments/blob/master/bouncy/main.go

결과는 인상적입니다. 실제로 발생하는 코드를 자세히 살펴보는 것은 실망스러웠습니다. 왜냐하면 자바스크립트 측에서 무언가를 호출할 때마다 매번 자바스크립트 함수의 이름이나 자바스크립트 값을 문자열로 설명해야 하기 때문입니다. . 결과적으로 golang 컴파일러가 컴파일 타임에 자바스크립트 정확성을 확인할 방법이 없습니다. 런타임에 "기도로 날아라"입니다. 장기 유지 관리를 위해 어디에서나 golang 함수/변수/유형을 보는 것을 선호합니다. BTW 나는 자바 스크립트를 싫어하고 항상 가지고 있습니다. 너무 자유분방해요. 그런 언어가 웹 브라우저에서 지속되는 이유는 무엇입니까? 대답은 나를 탈출합니다.

들어 주셔서 감사합니다.

문자열을 사용하여 JS를 호출하는 것이 더 나은 경험이 아니라는 데 동의합니다. 웹 플랫폼 사양 IDL에서 Go 인터페이스를 생성할 수도 있습니다. 단점은 실행될 브라우저에 따라 API를 사용할 수 없는 반면 웹 플랫폼이 발전함에 따라 새로운 사양이 계속 제공되기 때문에 사양을 유지하는 방법입니다.

@omac777 동의합니다. 그렇기 때문에 대부분의 사용자가 syscall/js 를 직접 만질 필요가 없도록 JS 저수준 주변에 멋진 Go 라이브러리가 있기를 바랍니다. syscall 패키지와 유사하게 보기 흉하고 직접 사용하는 사람은 거의 없습니다. ;-)

@omac777 GopherJS의 경우 많은 사람들이 저수준 js 패키지를 직접 사용하는 대신 다양한 브라우저 API에 대해 고수준 바인딩을 사용합니다. 나는 유사한 접근 방식이 Wasm에서도 가장 인기가 있을 것이라고 생각합니다. 많은 GopherJS 바인딩이 동일한 패키지에 Wasm에 대한 지원을 추가하고 필요에 따라 새 패키지가 생성될 것으로 기대합니다.

참고로 https://github.com/gopherjs/gopherjs/wiki/Bindings , https://dmitri.shuralyov.com/talks/2016/Go-in-the-browser/Go-in-the-browser를 참조하세요. 슬라이드 #11 (및 다음 4개의 슬라이드) 및 https://github.com/dominikh/go-js-dom/issues/57.

또한 우리는 웹 어셈블리 로드맵에 많은 것들이 있다는 것을 고려해야 합니다.

https://webassembly.org/docs/future-features/

그러면 장기적으로 syscall 스토리가 상당히 개선될 것입니다.

WebAssembly 코드에서 직접 DOM 및 기타 웹 API 개체를 참조합니다.
JavaScript를 통해 호출하지 않고 WebAssembly에서 직접 Web API(프리미티브 또는 DOM/GC/Web API 객체 전달)를 호출합니다. 그리고
WebAssembly 코드에서 직접 GC 개체를 효율적으로 할당하고 조작합니다.

어쨌든 @neelance et. 감사합니다. 알. 초기 버전을 구현하기 위해. 너무 멋져! 🥇

DOM의 Go 구현이 있다면 어떻게 될까요?

문서와 스크립트는 유형 시스템을 사용하여 Go로 작성 및 실행할 수 있습니다.

그런 다음 Go DOM에서 코드를 생성할 수 있습니다.

@fractalbach : WebAssembly의 호스트 바인딩 이 작업 그룹에서 확인 및 구현되면 실제로 WebAssembly를 통해 DOM 조작을 수행할 수 있습니다. 그런 다음 DOM, 문서 및 스크립트를 추상화하는 고급 라이브러리를 갖는 것이 합리적입니다.

그러나 그 전에 하는 것은 그다지 매력적이지 않습니다.

Go WebAssembly: JS 참조에 구조 바인딩

https://medium.com/@nlepage/go -webassembly-binding-structures-to-js-references-4eddd6fd4d23

접근 방식이 매력적입니다. 사용법은 구조체 내에서 json 마샬링/마샬링 해제와 유사합니다. 쉽게 옮길 수 있는 스킬입니다.

한 가지 빠진 것은 오리 타이핑에 동일한 접근 방식을 적용하는 방법입니다. 나는 구조 내에서 함수 선언을 하지 않고, 덕 타이핑과 같은 방식으로 구조 외부에서 독립형으로 선언하는 것을 선호합니다. 서비스가 존재하는 경우 사용할 수 있습니다. 그렇게하면 원하는 다른 비 기능 값을 보유하는 핵심 구조체에 영향을 미치지 않고 쉽게 수정할 수 있습니다. 오리 타이핑 바위!

모든 작업에 대해 @neelance 에 다시 한 번 감사드립니다. 대단히 감사합니다.
의견을 주신 Nicolas Lepage 씨에게 감사드립니다. 그들은 직접적인 wasm 인터페이스가 완료될 때까지 잠정 동안 이 모든 자바스크립트 노이즈와 상호 운용하기 위한 더 나은 경로가 될 수 있는 것을 결정하는 데 실제로 도움이 됩니다.

안녕하세요 여러분, 이것은 많은 사람들이 구독하는 트래픽이 많은 스레드입니다. 이와 같은 일반적인 토론을 갖는 것은 Go에 대한 WebAssembly 지원을 갖는 원래 문제에 대해 우려하는 사람들에게 유익하지 않습니다.

적절한 포럼(golang-nuts/golang-dev)에서 자유롭게 토론을 계속하십시오. 또는 특별히 염두에 두고 있는 것이 있으면 새 문제를 여십시오.

감사합니다.