Temat: 65816 brakujące rozkazy...
No właśnie, tak trochę w opozycji do tematu http://www.atari.org.pl/forum/viewtopic.php?id=9843 - czemu nie?
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
4th Atari ASCII Compo - wyniki Dostępne są już wyniki tegorocznego ATASCII Compo.
thing neo 1.60 Olivier Landemarre wydał nową wersję desktopu Thing.
VIII. Basque Tournament of Atari 2600 Kolejna relacja, wśród otrzymywanych od naszego przyjaciela Egoitza z Kraju Basków.
Przezroczysta obudowa dla Atari 800XL Rusza przedsprzedaż wyjątkowej, przezroczystej obudowy do komputera Atari 800XL!
RECOIL 6.4.5 RECOIL to przeglądarka retro plików graficznych, obsługująca ponad 550 formatów, dostępna na różnych systemach operacyjnych, z regularnymi aktualizacjami.
Strony 1
Zaloguj się lub zarejestruj by napisać odpowiedź
No właśnie, tak trochę w opozycji do tematu http://www.atari.org.pl/forum/viewtopic.php?id=9843 - czemu nie?
XXL nie troluj. Atari z 816 nadal jest komputerem 8-bitowym (a 816 jest 8-bitowym procesorem - taką ma szynę danych)
Czekamy na F7 Pasia :)
a 816 jest 8-bitowym procesorem - taką ma szynę danych
Szyna danych nie decyduje o tym ilu bitowy jest procesor. XXL ma rację 65816 jest procesorem 16-bitowym.
Ostatnio edytowany przez Rastan (2012-11-22 20:24:30)
Juz raz byla dyskusja o tym co decyduje. Wiec wg Ciebie?...
Edit: Tak, pamiętam taką dyskusję na Atari Online.
Procesor 386SX jest procesorem 32-bitowym z ograniczoną do 16-bitów szyną danych, podobnie Motorola 68008 jest procesorem 16-bitowym z okrojoną do 8-bitów szyną danych. Tak, że szyna danych nie decyduje.
Decyduje ALU i nie jest to moja opinia, ani kwestia czyjegoś zdania.
Ostatnio edytowany przez Rastan (2012-11-22 21:12:54)
Bardzo mnie ciekawi, co oznaczają "brakujące rozkazy".
xxl: przypierdalasz sie bez powodu (w dziedzinie atari masz jakis 16bit system (komputerowy, nie operacyjny) oparty o 65816?) nie do tego co trzeba.
zamiast przywalac sie moglbys potraktowac ten watek humorystycznie, bo przeciez nawet niewiele wiedzac o 65816, kazda srednio rozgarnieta malpa potrafi wygooglac ze "It utilizes all 256 possible opcodes and does not support the original illegal opcodes".
wieczor: pentiumy to tez 16bit proce? one tez budza sie w trybie o okrojonych mozliwosciach, ze wzgledu na wsteczna kompatybilnosc (zupelnie jak 65816), a mimo tego uznaje sie je procesorami 32bitowymi lub nawet i 64bitowymi.
nie decyduje szyna danych, ale maksymalna wielkosc rejestrow danych (wylaczajac rejestry "koprocowe", tj. do operacji wektorowych, czy fp.
w przypadku 65816 te rejestry maja 16bit.
epi: to te "o rozszerzonych mozliwosciach" ;) odkrywane na nowo przez xxl ;)
Ostatnio edytowany przez jellonek (2012-11-22 21:38:42)
@jell: nie może decydować jak napisałeś "wielkosc rejestrow danych" ponieważ Z80 ma 16-bitowe rejestry, a jest prockiem 8-bitowym. tak samo z 68000 - ma 32-bitowe rejestry, a jest prockiem 16-bitowym. choć akurat w przypadku tego procesora czasami, myślę, że ze względów marketingowych, pisze się 16/32 - ja to czytam tak: procesor 16-bitowy z elementami 32-bitowymi. 80486DX - procek 32-bitowy ma bodajże 80-bitowe rejestry koprocesora.
pisalem ze rejestry fp (koproca) nie graja roli
zx ma 16bit rejestry danych? jak juz - indeksowe/bazowe lub adresowe.
6502 tez ma 16bit rejestr pc, co nie czyni go procem 16bit
z 68k nie pamietam jaki trick byl ;)
Panowie, konkrety poproszę...
@epi: na przykład, czy są jakieś lub działają inaczej niż na 6502 (oprócz nielegali, of coz)
Znalazem coś takiego: http://www.google.pl/url?sa=t&rct=j … OTZAqxE6Lg oraz opis do 6502: http://c64power.com/index.php/artykuly/ … esora-6502
Nie jestem programistą, a przynajmniej nie na poziomie assemblera, ale parę rzeczy w wymienionym dokumencie mnie zainteresowało:
MOS 65c816 jest szesnastobitowym procesorem zgodnym programowo "w dół" z zainstalowanym w ATARI XL/XE procesorem 6502. Zgodność ta nie obejmuje nielegalnych (niepublikowanych) rozkazów 6502.
Celem zachowania kompatybilności z aplikacjami pisanymi dla 6502 procesor ma, obok trybu 16-bitowego (tzw. native mode), również tryb emulacji 6502 (emulation mode). W trybie tym funkcjonują wszystkie rozkazy 65c816, jednak nie jest możliwe korzystanie z szesnastobitowych operandów.
Szesnastobitowy akumulator bezpośrednio dostępny jest jedynie w trybie natywnym, nawet jednak w trybie emulacji istnieje możliwość zamiany miejscami obydwu jego ośmiobitowych połówek. Wykonuje to rozkaz XBA. Niektóre rozkazy używają szesnastobitowego akumulatora niezależnie od bieżącego trybu pracy CPU i stanu bitu M. W takich wypadkach akumulator oznaczany jest jako rejestr C.
-tutaj podejrzany jest kawalek o używaniu szesnastobitowości akumulatora niezależnie od trybu pracy...
Rejestr PC jest, niestety, szesnastobitowy. Oznacza to, że procesor nie jest w stanie przekroczyć granicy 64k inaczej, niż wykonując długie skoki JMP lub JSR.
Jak to się ma do natywnych programów z 6502? Pytam z czystej ciekawości.
Czas wykonywania się rozkazów w trybach strony zerowej jest taki sam, jak w 6502, pod warunkiem, ze rejestr D zawiera parzysta wartość. W przeciwnym wypadku wykonanie rozkazu zajmuje jeden cykl więcej.
Hmm, możemy tracić cykle za darmo... :/
Następna rzecz może powodować nieprzewidziane działania (dla standardowego Atari z 6502C):
Ważna różnica pomiędzy 6502 a 65c816 jest sposób obliczania adresu efektywnego w trybach indeksowanych strony zerowej. W 6502 nie da się przekroczyć granicy tej strony: jeśli wartość wynikająca z dodania adresu absolutnego do rejestru indeksowego jest większa, niż $FF, odwołanie "zawija się" do początku strony zerowej - LDA $FF,X przy X=$01 daje adres efektywny $0000 (a nie $0100).
W 65c816 pracującym w trybie 16-bitowym (native mode) jest inaczej: indeksy dodawane SA z przeniesieniem, toteż dla powyższego przykładu zostanie wygenerowany adres efektywny $0100 (+ zawartość rejestru D). Jednak w trybie emulacji 6502, dla zachowania kompatybilności z istniejącym oprogramowaniem, procesor zachowa się tak jak 6502, wszelako (i to jest cokolwiek dziwne) tylko wtedy, gdy rejestr D=$0000 a rozkaz pochodzi z repertuaru zwyklego 6502 (uwaga: nie 65c02!). We wszystkich innych wypadkach odwolania beda przekraczac granice strony rowniez w trybie emulacji.
Nie da sie ukryc, ze XL OS nie ma niczego sensownego pod tym adresami, tak wiec przelaczenie CPU w tryb natywny bez wylaczenia przerwan powoduje natychmiastowe padniecie systemu.
Uppsss... Lecimy w maliny?
JMP - jump - skok. Dla JMP long uzywa sie tez mnemonika JML (jump long). Uwaga: tryby posrednie (abs) i (abs,X) dzialaja zgodnie z logika, tj. jeśli argument wskazuje slowo znajdujace sie na granicy stron, starszy bajt zostanie odczytany z poczatku nastepnej strony, a nie z poczatku tej samej, jak w 6502.
Czyli skoczymy fizycznie gdzie indziej... A przeca JMP jest standardowym rozkazem... :/
Dobra, trochę się czepiam, ale XXL mnie zainspirował do sprawdzenia tych kilku rzeczy. Czy ktoś z szanownych programistów znających się na assemblerze mógłby tabelarycznie porównać STANDARDOWE rozkazy 6502C i 65C816 w trybie emulacji? Wraz z rozpiską cykli, zasadniczych różnic? (na przykład skoki we wspomnianym już JMP)?
@jell: ok. z tym koprocesorem źle przeczytałem. ale dwa przykłady są w mocy, tj. z80 jak pisał XXL ma 16 rejestry ogólnego przeznaczenia, a jest uważany za procesor 8-bitowy. natomiast 68000 ma 32-bitowe rejestry ogólnego przeznaczenia i również jest uważany za procek 16-bitowy z zastrzeżeniem o którym wyżej pisałem.
65C816 napisał/a:
Szesnastobitowy akumulator bezpośrednio dostępny jest jedynie w trybie natywnym, nawet jednak w trybie emulacji istnieje możliwość zamiany miejscami obydwu jego ośmiobitowych połówek. Wykonuje to rozkaz XBA. Niektóre rozkazy używają szesnastobitowego akumulatora niezależnie od bieżącego trybu pracy CPU i stanu bitu M. W takich wypadkach akumulator oznaczany jest jako rejestr C.
istnieje możliwość to nie oznacza, że stanowi to jakikolwiek problem. W stosunku do natywnego kodu 6502c opartego o legalne instrukcje problem nie istnieje.
65C816 napisał/a:
Czas wykonywania się rozkazów w trybach strony zerowej jest taki sam, jak w 6502, pod warunkiem, ze rejestr D zawiera parzysta wartość. W przeciwnym wypadku wykonanie rozkazu zajmuje jeden cykl więcej.
Hmm, możemy tracić cykle za darmo... hmm
Jeśli miało by to stanowić problem, to stopień niekompatybilności byłby znacząco większy. A tak - jest mało zauważalny.
65C816 napisał/a:
Nie da sie ukryc, ze XL OS nie ma niczego sensownego pod tym adresami, tak wiec przelaczenie CPU w tryb natywny bez wylaczenia przerwan powoduje natychmiastowe padniecie systemu.
Uppsss... Lecimy w maliny?
Mając na względzie taką sytuację mamy do dyspozycji system operacyjny przeznaczony dla 65c816. Mówimy tu o programowaniu dla 65c816, więc nie wiem o jakich malinach mowa ;)-
A czy ten z80 moze lyknac te 16 bitow danych na raz? W sensie czy mozliwe sa operacje ladowania/przesylania/wymiany tych rejestrow za jednym cyklem rozkazowym?
(serio pytam nie znam tej architektury)
owszem, mozesz zaladowac/zapisac 2 bajty na raz, co wiecej - mozesz 16 bitowe rejetry dodawac/odejmowac, mozesz zwiekszac/zmniejszac 16 bitowe rejetry...
ale akumulator masz 8 bitowy, takie operacje jak AND, OR, XOR, porownywanie, rotacje itp tylko 8 bitow i caly misterny plan wpi....u
ale jest ciekawa cecha - "ruchomy stos" - dzieki niemu oraz temu, ze na stos/ze stodu mozna zapisac 16 bitowe rejestry ogolnego przeznaczenia mozna przyspieszyc kopiowanie (zwlaszcza na ekran) bo pomijamy indksowanie
65816 jest procesorem 16-bitowym, jednak Atari z takim procem są jedną z odmian 8-bitowego Atari i jako takie tematycznie należą do tego działu. Zatem jeśli coś, to należy zmienić nazwę (lub definicję) działu. Bo "16/32" to dział ST/TT i odmian, a zatem nie ten temat.
Nie wątpię zresztą, że xxl świetnie o tym wie, tylko po prostu trolluje jak zwykle. I jest regularnie dokarmiany.
Ja już przestałem, wolę dokarmiać siebie ;P
Strony 1
Zaloguj się lub zarejestruj by napisać odpowiedź
[ Wygenerowano w 0.087 sekund, wykonano 9 zapytań ]