Dnia 13.10.2014 R.e.m.e.K <p...@w...pl> napisał/a:
> Dnia Mon, 13 Oct 2014 05:25:56 -0700 (PDT), firr napisał(a):
>
>>> nazwac "signed unsigned int" czy jakos inaczej)
>>
>> w sumie przy takich zlozeniach to np taki bajt jest nie tylko suma signed i
unsigned ale nawet sumą plus signed i minus unsigned, czyli jeden
>> bajt moze przechowywac np wartosci od -255 do 255
>
> Teraz to juz przechodzisz samego siebie, zaslugujesz juz na wielkie Ś przed swoim
nickiem!
>:-)

Daj spokój, zaczynało być "ciekawie" ;)
Tak żeby podkręcić firra: bajt to po pierwsze nie to samo co oktet (nie
zawsze to jest 8 bitów, choć obecnie najczęściej tak jest, ale na przykład
polska Odra miała inaczej :D) a po drugie nawet jeśli zakładać dla
uproszczenia, że to oktet, to czy to jest liczba, kolor piksela czy na
przykład informacja która lampka ma sięświecić a która nie, zależy od
kontekstu. Procesory po prostu nie wnikają, dla nich bity i bajty nie mają
"typu", są operacje na przykład logiczne, traktujące bity niezależnie (OR,
AND, XOR, NOT itd.), są operacje traktujące bity jako liczbę (ADC, MUL
itp.), są operacje w ogóle nie wnikające w zawartość (PUSH, PULL, IN, OUT)
itd. Dodatkowo ALU wielu procesorów potrafi ten sam bajt podczas operacji
arytmetycznych traktować w różny sposób (już nawet 6502 ze wspomnianego
przez firra C64), na przykład jako liczbę z zakresu -128..127 (w kodzie
uzupełnień do dwóch) lub jako liczbę z zakresu 0..99 (kod BCD). Poza tym
procesory mają najczęściej dwie flagi, przeniesienie i przepełnienie, dla
uproszczenia dla 8 bitów przeniesienie jest ustawiane gdy wynik (na
przykład dodawania) nie mieści się w 8 bitach, a przepełnienie gdy wynik
nie mieści się w 7 bitach - w ten sposób ten sam układ ALU może dodawać
liczby w kodzie U2 zarówno ze znakiem jak i bez znaku (nie musi wiedzieć
który wariant chce programista, bo układ bitów w wyniku będzie taki sam), a
w gestii programisty jest sprawdzanie flag i reakcja w zależności od tego
jak te dane chce traktować. Oczywiście przy mnożeniu/dzieleniu sprawa
wygląda inaczej :D
Co do poprzednich wywodów czy robić porównania od razu ze skokiem czy
nie... ja proponuję jeszcze inne podejście, takie jak na przykład mają
procesory ARM, czyli wykonanie instrukcji (dowolnej!) można uzależnić od
pewnych flag w rejestrze statusu, na przykład:

CMP R1,R2 # Porównanie R1 i R2 i ustawienie flag w rejestrze statusu
SUBGT R1,R2,R1 # Wykonanie odejmowania (wynik do trzeciego argumentu, tu
# wynik leci do R1) tylko wtedy gdy poprzednie CMP ustawiło
# flagi "zachodzi warunek 'większy niż'"

W ten sposób po CMP nie trzeba w ogóle wstawiać instrukcji skoku (ani CMP
nie musi mieć jej "wbudowanej").

do góry

w ogole to mialem troche rozkminek jak napisac
taki asembler (bo bede pisac) - dosyc elegancko
nalezy zbudowac
1. jeden (wirtualny) 'plik' - z przestrzenią procesu tj ram + skompilowany bytecod
(jesli zalozymy ze kod startuje od adresu zero to nie trzeba zadnych metadanych jak w
PE, wystarczy wygenerowac czysta obraz przestrzeni procesu i go uruchomic (podoba mi
sie ta prostota)
2. drugi plik z tabelą nazw symboli we wspomnianej wczesniej przestrzeni procesu
(potrzebny przy kompilowaniu ale tez majacy
'stale' znaczenie puzniej jako cos w rodzaju
symboli dla debuggera) - ta prostota tez mi sie
bardzo podoba - finalne wnioski (o istocie tych dwu plikow) bardzo ciekawe

do góry