"Problem emulacji rejestrów" ZTCW pojawił się w PPro i ciągnął się co najmniej do PIII (wiele osób jeszcze je ma). Kiedy zniknął? Z odczytem ah z zapisanego eax ZTCW nie było większego problemu (najwyżej zwykły "registry stall"). Problem był, gdy zapisaliśmy ah i odczytywaliśmy ax lub eax (czyli w przypadku xchg al,ah, po którym zapewnie chcemy użyć ax).

Po prostu ja kiedyś zapisałem z 15 plansz i nie mogłem ich wczytać (chyba RK się wieszał przy wczytywaniu). Zdaje się, że później czytałem, że ktoś też miał taki problem, ale nie dam głowy.

Racja, ROL się ślimaczył tylko na 186 i 286:

ROL     Rotate bits left

    operands    bytes   8088    186     286     386     486     Pentium
    reg, 1       2       2       2       2       3       3       1   PU
    mem, 1    2+d(0,2)  23+EA   15       7       7       4       3   PU
    reg, cl      2       8+4n    5+n    5+n      3       3       4   NP
    mem, cl   2+d(0,2) 28+EA+4n 17+n    8+n      7       4       4   NP
    reg, imm     3       -       5+n    5+n      3       2       1   PU
    mem, imm  3+d(0,2)   -      17+n    8+n      7       4       3   PU*

       * = not pairable if there is a displacement and immediate

Za to RCL (czyli ROL z 6502) wygląda, że jeszcze w Pentium miał złożoność liniową:

RCL     Rotate bits left with CF

    operands    bytes   8088    186     286     386     486     Pentium
    reg, 1       2       2       2       2       9       3       1   PU
    mem, 1    2+d(0,2)  23+EA   15       7      10       4       3   PU
    reg, cl      2       8+4n    5+n    5+n      9      8-30    7-24 NP
    mem, cl   2+d(0,2) 28+EA+4n 17+n    8+n     10      9-31    9-26 NP
    reg, imm     3       -       5+n    5+n      9      8-30    8-25 NP
    mem, imm  3+d(0,2)   -      17+n    8+n     10      9-31   10-27 NP

Jeszcze XCHG dla ciekawskich:

XCHG    Exchange register/memory with register

     operands   bytes   8088    186     286     386     486     Pentium
     reg, reg    2       4       4       3       3       3       3   NP
     reg, mem  2+d(0-2)  25+EA  17       5       5       5       3   NP
     mem, reg  2+d(0-2)  25+EA  17       5       5       5       3   NP

     acc, reg    1       3       3       3       3       3       2   NP
     reg, acc    1       3       3       3       3       3       2   NP

     in above: acc = AX or EAX only

(zaczerpnięte z http://security-protocols.com/programmi … pcode.html)

"intrinsics" są oczywiście równie przenośne jak asm. VU w PS2 pewnie rzeczywiście lepiej programować w asmie (nigdy nie twierdziłem inaczej), jednak do emulacji Atari raczej na niewiele się zda (a wątek dotyczy asm vs C w kontekście emulacji Atari). Co do problemów z nowym hardware, to wkrótce będzie PS3 i wszyscy zapomną o PS2. ;)

Czemu ograniczać się do CMC ?
Może tak ASAP2MIDI ?

Jak najbardziej. A jeśli ich nie zauważa ani nie zauwarza, to można użyć w C "intinistic functions",
czyli wywołań funkcji, które kompilator zamienia na odpowiednie instrukcje asma.

4-krotne przyspieszenie to bajki. Procesory są zoptymalizowane pod kątem przetwarzania "zwykłych" instrukcji (np. często mają więcej potoków dla nich). Sam kiedyś robiłem testy, w których na Dureniu 700 procedura na zwykłych instrukcjach 386 była kilkadziesiąt procent szybsza od procedury z użyciem MMX, chociaż w przypadku MMXowej było wykonywane kilkukrotnie mniej instrukcji. Na Pęntlum III 500 MMX miał przewagę zaledwie kilku procent - szkoda zachodu.

ja mogę powiedzieć jakich konstrukcji asemblera nie ma bezpośrednio w C: zamiana słów (xchg), zamiana kolejności bajtów (bswap), obroty (rol, ror, rcr, rcl), operacje BCD (daa, das) i na cyfrach dziesiętnych (aaa, aas, aam, aad), dzielenie z resztą (jedna operacja, dostępny wynik dzielenia i reszta). Obroty i operacje BCD mogą się przydać w emulacji 6502, ale bez przesady, przecież programy na Atari rzadko używają takich ficzerów.

drac030: Zgadza się. Np. pisząc if-a nijak nie można wytłumaczyć kompilatorowi, że warunek będzie np. w 90% spełniony. W asemblerze jest tu większe pole do popisu. To jednak może tłumaczyć 50% a nie 600% różnicy w wydajności. Taką różnicę w przypadków programów na Atari "migających" bankami pamięci mogłoby tłumaczyć użycie sprzętowego mechanizmu stronicowania, zamiast przepisywania pamięci. Jednak sprzętowe stronicowanie można również osiągnąć w C wywołując odpowiednie funkcje systemowe. Co więcej, w asemblerze też trzeba wywołać te same funkcje systemowe, o ile emulator pracuje pod kontrolą systemu operacyjnego (a nie np. DOSa).

Widocznie PG "wziął urlop". W każdym razie obecnie odpisuje szybko, nawet w przeciągu kilku minut.

Jeśli wysłałeś mu SAPy i/lub informacje o autorach, a on podziękował, to znaczy, że będą umieszczone.

A ja myślałem, że chodziło o to:

http://atariarea.krap.pl/forum/viewtopic.php?id=219

:)

Na 99% nie spotkałem się nigdy na giełdzie jednocześnie z Tobą, Mikerem i Lewisem.

Pożyczyłeś mi je (a raczej wepchnąłeś, bo ja ich nie chciałem) w swoim mieszkaniu.

Tak szybko, jak się da. :)