Ostatnio mam taki nawyk, że całą grę piszę w ASM, ale po kawału. W TBXL majstruje bitami, bajtami i ustawiam zmienne, a potem w jednej pętli jedzie USR za USRem gdzie jest wywoływany czysty ASM wcześniej władowany do RAMu z dyskietki. Ponieważ nie skończyłem jeszcze w ten sposób żadnego projektu, a baaaardzo wygodnie mi się w ten sposób pracuje, (bo mogę wyłączyć jakąś podprocedurę, zamienić je kolejnościami, zmieniać dane w bazylu zanim przejmie kontrolę ASM, dorzucić jakiś warunek itd itp) zastanawiam się jak to będzie wyglądać po skompilowaniu, nie chcę się rozczarować :( Czy TBXL po skompilowaniu tłumaczy USR jako zwykły skok ze śladem? Czy tworzy dodatkowo kilkaset instrukcji i coś takiego się nie opłaca?
Program wygląda tak: 1. zmienne ustawiane w bazylu, wczytywanie podprogramów w ASM do ramu, majstrowanie w RAMie itd itp. 2 DO USR USR USR USR LOOP
Ta druga część zostanie skompilowana jako czysty ASM, a każdy moduł połączony skokiem ze śladem, powrotem i tak w kółko? Czy też wydajność będzie do dupy? Czy taki program "zniesie" jakiś prosty warunek napisany między USRami w bazylu?
jeśli zwracasz z procedury maszynowej jakiekolwiek wartości (X=USR) - to do "X" po kompilacji nie zostanie zwrócone nic :)
Do ładowania segmentów kodu asm NIE używaj BLOAD, bo pod niektórymi dosami w tym pod Sparta DOS X wszystko, co oparte o BLOAD przestanie działać. Był też problem z instrukcją DEC, chyba że używasz poprawionych bibliotek RUNTIME2 - poprawki homemade by Jacek Żuk ;)-
Właśnie ładuje to Bloadem po kawałku, nie zwracam żadnych zmiennych do bazyla, między DO, a LOOP leci cały czas USR za USRem. Piszę wszystko w QA, stąd wygodniej mi sterować tym wszystki w Basicu, mógłby opcjonalnie dopisać skoki w tych kawałkach bezpośrednio do kolejego kawałka kodu maszynowego, wtedy zaoszczędziłbym czas na skok, powrót, skok bo tak to chyba wygląda po skompilowaniu w TBXL, ale nie jestem pewien. Zastanawiam się czy wciśnięcie jakiegoś bardzo prostego fragmentu w TBXL (np. jakiś poke, czy wygenerowanie liczby losowej) pomiędzy USRy nie rozwali mi wszystkiego, w sensie że nie zmieszczę się w ramce. Dalej nie wiem czy USR to faktycznie tylko skok i powrót po skompilowaniu, na taką małą stratę cykli mogę sobie pozwolić, gorzej jeśli doklei się tam jakiś spory i niepotrzebny kawałek kodu.
A co do uwagi o tym, że lepiej wszystko napisać w ASM bez programu sterującego w Basicu to raz, że piszę w QA więc i tak musiałbym to robić w kawałkach, a dwa, Basica używam tylko do ustawienia zmiennych i paru peeków i poków do operacji na RAM, nie chce mi się do celów testowych co chwila kompilować jakiegoś programu w ASM z różnymi parametrami, żeby sprawdzić jak to wyjdzie, lepiej mi je podmieniać jak chcę przed główną pętlą prostymi komendami.
A tak z czystej ciekawości, przesyłanie po skompilowaniu działa w drugą stronę? Poprawnie mi odłoży coś na stosie po użyciu USR z parametrem? Nie piszę tego na pececie więc traciłbym dodatkowo na takie myki jeszcze więcej czasu.
Maciek, a co ty tak naprawdę chcesz robić/robisz? Bo wydaje mi się, że chcesz zrobić coś dla idei - w sposób taki, jak to się kiedyś robiło, gdy nie korzystało się (bo nie było jak) z dobrodziejstw dzisiejszej technologii (cross-compiling, testowanie na emulatorze, itp)
Wiem, że to zboczenie, ale dla mnie własnie liczy się pisanie czegoś na real hardware... Nie interesuje mnie żaden crosskompilator, na peceta. Pisanie czegoś na zwykłym Atari ma dla mnie takie samo znaczenie jak granie na nim, a nie na emulatorze. Ta magia sprawiła, że w ogóle zająłem się Atari. Dzisiaj pisanie czegoś w C++ czy Javie wydaje mi się strasznie nudne i nie stanowi takiego wyzwania jak programowanie 8śmiobitowca "metodami naturalnymi" :)
