Názory k článku Programovací jazyk Go a assembler (2.část)

Zdravím (opět :), jen dotaz: nevíte náhodou, je nutné u deklarace funkcí s implementací v asm použít explicitně go:noinline?

Také zdravím. Chápu to dobře, že MOVSD_XMM používá to _XMM jen proto, že existuje i starodávná MOVSD ještě z dob 8086 a proto to assembler nějak musí naznačovat? (asi se ptám naivně, ale docela se začínám ztrácet v různých "extensions" té původní instrukční sady která je sama o sobě strašně moc CISCová :-)

Taky mě překvapil způsob překladu Add64 pro ARMy v https://www.root.cz/clanky/programovaci-jazyk-go-a-assembler-2-cast/#k11 Pěkný trik, vystačit si jen se dvěma ADC

No je to tak. Intel totiž instrukční sady (resp. jména instrukcí) rozšiřuje poměrně chaoticky, na rozdíl od RISC-V (https://www.root.cz/clanky/instrukcni-sada-procesorovych-jader-s-otevrenou-architekturou-risc-v/), kde má každé rozšíření speciální označení (https://www.root.cz/clanky/instrukcni-sady-procesorovych-jader-s-otevrenou-architekturou-risc-v-dokonceni/). Takže zrovna MOVSD znamená buď https://www.felixcloutier.com/x86/movs:movsb:movsw:movsd:movsq nebo https://www.felixcloutier.com/x86/movsd (S je tedy buď "string" nebo "scalar").

Kolega me upozornil, ze RISC-V se objevi v Go 1.14 v experimentalnim rezimu, coz je super:
https://tip.golang.org/doc/go1.14#riscv

Diky Jakube!

Já tomu asi nějak nerozumím. Nejprve se vytvoří jazyk Go s tím, že je to jednodušší než C, má to garbage collector, bezpečnější alokování paměti a obecně práci s pamětí, vyšší míru abstrakce... a pak se tam narve assembler. Když se podívám, že Go kompilátor umí kompilovat jen pro AMD64 + IA-32 a pro ostatní platformy spoléhá na gccgo, tak si říkám, k čemu ten jazyk vlastně je. Takhle mi to připadá, že se v podstatě akorát znovuvynalézá kolo místo toho, aby se raději třeba udělala nějaká práce přímo na GCC, což by bylo pro všechny mnohem užitečnější.

K tomu překladači: podívej se znovu a pořádně.

Já to chápu tak, že právě tím, že se jedná o jazyk s vyšší mírou abstrakce (nad nějakým obecným CPU, který je v případě Go konkrétnější, než v C), tak se ztrácí vyjadřovací schopnosti pro nízkoúrovňové operace. Tím trpí prakticky všechny vyšší programovací jazyky, protože "semantical gap" mezi assemblerem a jakýmkoli vyšším jazykem je obrovská (snad nikde v žebříčku jazyků není větší). Řeší se to různě - nějakými intrinsic popř. možností přejít do assembleru, ZA PŘEDPOKLADU, že je to nutné pro vyřešení problému (například potřebuji extra dobrý výkon při SIMD operacích).

Konkrétně v samotné základní knihovně Go je assembler použit jen tam, kde je to prakticky nezbytné:
1) věci okolo CPUID
2) balíček crypto (různé bitové posuny, rotace, masky, interleave, speciální crypto instrukce)
3) balíček hash (dtto)
4) samozřejmě math
5) bytes - pěkná je například funkce equal, která má uvnitř smyčku, kde se v každé iteraci porovná celých 64 bajtů (na AMD64)

Kde bych assembler použil dnes já, kdyby bylo vyžadováno (jako že na našem projektu není):
1) vše okolo SIMD operací (SSE1-4, AVX, ...)
2) možná kdyby bylo skutečně nutné si nějak hrát s bitíky (FFT?, ale to už určitě někdo v asm. pro Go napsal)