Vlákno názorů k článku Programovací jazyk Go a assembler (3.část) od Calculon - Dobrý den, určitě jsou len a cap na...

Jj má (popravdě mě ten assembler v tomto mate, mám zakódováno, že D=double word a L mi tím padá do něčeho "většího", což je špatně). Navíc jsem začínal na opisu kódu generovaného přímo překladačem Go a ten použil XORL. Asi pořád přepokládá len=cap=int? :D

Že Vy ještě máte Go 1.0 :)

jsem konzervativní, takže staré dobré 1.13 (https://github.com/tisnik/go-root/blob/master/article_56/02_empty_image_asm/go.mod), na 1.14 se necítím (tedy zkouším doma, ale ne pro naše projekty)

Ale pro zasmání jaký jsem exot - relativně velkou codebase ještě udržuji v ANSI C. Dnes v podstatě jen tak z hecu, už by se to klidně dalo přepsat, ale proč si nezavzpomínat.

13. 2. 2020, 08:58 editováno autorem komentáře

jaký kód ten první příklad generuje u vás? 0x31 0xd2 je v xor EDX, EDX

13. 2. 2020, 09:08 editováno autorem komentáře

Jo, je tam XORL. Tady mi něco uniká.

BTW ten "opis kódu" se Vám jednou vymstí, schválně si do asembleru napište CMPQ AX, BX a pak si to prohlédněte přes objdump :) Věděl jste o tom?

Jj hned při prvních hrátkách s go asm, kdy se "zdálo", že všechny podmíněné skoky jsou špatně :-) Prostě celé to přišlo z úplně jiného světa (Plan-9).

Podle mě by to chtělo jeden článek “Go best practices and WTFs”, jako že je lepší se vyvarovat konverze []byte(...), záludnosti cap a v sekci o asm právě takovéto chytáky.

Ale pokrok se děje, instrukce pro AVX-512 už nějakou dobu nezapisuju pomocí BYTE :)

Na amd64 32-bitový XOR na EAX apod. vynuluje horních 32 bitů a ušetří se jeden bajt opkódu.