🚀 go-pugleaf

> P.S. Intel skomplikowal assembler, mogl uzywac min bajtow do
> okreslenia rejestrow i operacji na nich, wtedy byloby wszystko
> bardziej czytelne. Kompresja kodu doprowadzila do utrudnienia jego
> rozumienia i praktycznie wyzerowania mozliwosci zapamietania.
> W dokumentacji wyglada to dobrze i niektore rzeczy sa nawet
> stablicowane, tylko niestety widac duza liczbe polecen, ktora
> powieksza chaos.

Ty chcesz się uczyć na pamięć kodu maszynowego? Można zapytać... po co :-)

> Co bedzie w przyszlosci z tymi procesorami?

patrz AMD64. jeszcze większy bałagan, bo pousuwano mnóstwo elementów 
(rejestry ds i es całkowicie poleciały, deskryptory są okastrowane) i dodano 
nowe rejestry i operacje 64-bitowe. Wtedy spamiętaj, czy dany rejestr można 
wykorzystać w danej instrukcji, czy nie... (np. OIDP nie można mieszać 
rejestrów ah,bh itp, w jednej instrukcji z r8w,r9w itd. "bo tak")

> Napewno wystarczyly by proste polecenia i mniejsza liczba, zeby wszystko
> dzialalo. Kompatyblinosc wstecz zbiera zniwo i kto wie jakie beda
> tego efekty.

demonizujesz. kompatybilność x86 jest jednym z podstawowych założeń, i 
dzięki niemu ta rodzina się rozwija [patrz: ia64 (niezgodne wstecz) kontra 
amd64 (zgodne) - która platforma się upowszechniła?]

> utrudniono maksymalnie nauke na tej platformie i pewnie
> ograniczono w duzej mierze produktywnosc.

najniższy poziom, jakiego programista się tyka, to asembler. mnemoniki są 
jasne, poziom skomplikowania instrukcji w wewnętrznej reprezentacji nie 
powinien nikomu przeszkadzać.

> Po co mieszac 32 bitowy i 16 bitowy kod?

a i 8 i 64- również :-)

> Sytuacje ratuja kompilatory i linkery, jednak
> nie zawsze mozna na nich polegac.

to kiedy nie?

-- 
Azarien