W dniu sobota, 26 sierpnia 2017 16:04:34 UTC+2 użytkownik AK napisał:
> Użytkownik "fir" <p...@g...com> napisał:
>
> > pewnie pomysle o optymalizacji jak ktos zacznie z sensem asemblowac tym
asemblerem
>
> Nikt nie zacznie, bo zwykly popularny kompilator C zrobi to o wiele wydajniej niz
twoj assembler.
>
> > na razie jakos tego zapotrzebowania wogole nie widze ;c
>
> .. co mnie w ogole nie dziwi.. czy ty widzisz cokolwiek dalej niz czubek wlasnego
nosa :) ?
>
> > gorzej ze nie che mi sie wklepywac tych wszystkich menmonikow, glownie chodzi o
te wersje
> > na charow i shortow, AX AH AL BX BL BH etc,
> > zreszta chyba nawet zwykle skoki albo nawet mov eax maja wersje skrocone (tj
takie ktorych
> > operand nie jes 32 bitowy tylko jakies krotsze wersje 16 bit 8 bit)..
>
> no to d..pa ! :)
>
> np. ...na stosowaniu tych wersji skrocoonych polegala kiedys optymalizacja kodu
assemblerowego.
>
> np powszechnie stosowalo sie (i kompiltaory C tez to wtedy juz umialy):
>
> push cs
> call near ptr addr_fun
>
> zamiast mniej wydajnego ;
>
> call far ptr addr_fun
>
> Takich "sztuczek" bylo wiele.
> Ja np. stosowalem dosc czesto:
>
> mov bx, sp
>
> i indeksowalen stos bx-em
>
> zamiast standarowej wtedy "rozbiegowki" funkcji:
>
> push bp
> mov bp, sp
> ...
> pop bp
>
> ale nie miejsce i pora. Raczej ciekawostka historyczna. z czasow x86
>
> PS: Dobrym assemblerowcem bedziesz, gdy bedziesz mial w kapuscie
> wryte zarowno mnemoniki jak i czasy wykonania rozkazow (no ok, dzis
> juz nie tak - cale szczescie - wazne:). Juz nic nie pamietam prawie
> ale CF (far ret) i C3 (near ret) wrylo sie w stary leb.
> Robilo wrazenie gdy (slawek zapewne pamieta/potwierdzi) pisalo sie
> w niejakim programie "debug" programy "z palca" szesnastkowo :)
> PS1: Kiedys rozpoznawalo sie prawiczka w ASM86 gdy pisal mov ax, 0
> miast xor ax,ax. Dzis (i znow cale szczecie:) przestalo i to miec znaczenie.
>

dzisiaj te instrukcja na AX AH i AL nie sa specjalnie krytycznie potrzebne,

pytanie czy wspolczesne kompilatory je nawet wogole generują (i pytanie jest raczej
ZTCW czy generuja je w ilosci mikro czy wogole)

moglby moze miec sens gdyby pomagaly w optymalizacji ale chyba tego nie robia (wogole
dzisaj gdy
cpu wogole nie jest krytyczne tylko memory bandwidth (MB) to co by sie
liczylo to pewnie prostota - i moze ewentualnie 'compactness' w sensie
pewnie lepsza specjalizowana instrukcja do iloczyny skalarnego dwu float4 niz jej
brak) (a to i tak wszystko w tyle za MB)

ew tylko przydalyby sie pewnie

mov byte ptr [eax], value

(bo inaczej pisanie poszczegolnych bajtow byloby utrudnione)

ew
mov eax, byte ptr [ecx]

do czytania pojedynczych bajtow

(ta granulacja bajtowa wogole przydaje sie chyba tylko do ascii
i kompletnie niczego wiecej -
to jak wspominalem chyba by znaczylo ze nalezaloby zrezygnowac z ascii na rzecz
sensownego unicode
i przerzucic sie na 32bitowe bajty]

(wynika tez chyba z tego ze zasadniczo by byc przyjaznym nowoczesnemu hardware
wypadaloby nielubic chara (przynajmniej w jego typowych zastosowaniach - [ew lubic
go tylko w unikalnych sytuacjach gdy pozwala zmniejszyc memory bandwidth (bo
teoretycznie moglby) ale nie wiem czy te sztuczki by dzialaly) ]

w sumie nie wiadomo co jest bardziej pozyteczne - korzysc wynikajaca z malego
rozmiaru pamieci na teksty wynikajaca z ciagle masowego uzywania charow
czy niekorzys wynikajaca z calego babrania sie z unalignmentami w procku (ciezko mi
powiedziec bo
faktem jest ze procek jest bardziej skomplikowany ale ewna korzysc ze
spakowania tekstow tez jest ;c )