26

Odp: TBXL - miejsce na dane

seban: nie wiem, jak wygląda move w TBXL, nie analizowałem kodu tego interpretera, tylko zrewerse-engineerowałem go w Multi :) Ale użycie do przepisywania stringów tej samej procedury, co w MOVE wydaje się logiczne.

Lizard: długość nazw zmiennych nie ma wpływu na szybkość wykonywania programu, interpreter przy obliczeniach posługuje się tokenami zmiennych a nie ich nazwami.

Ostatnio edytowany przez drac030 (2008-02-06 11:18:04)

KMK
? HEX$(6670358)

27

Odp: TBXL - miejsce na dane

Hej!

Lizard: No widzisz :) A kto powiedział że ja się super znam na Turbo Basicu :) O zmiennej TIME również zapomniało mi się po latach :) Pamiętałem jedynie o TIME$ która była dla mnie bezużyteczna :) Ale abym i ja mógł się do czegoś przyczepić  (a co :P ) to z  tym MEMTOP-192 to chyba przesadziłeś nieco :D Poza tym T1 i T2 wyjdą u Ciebie w ramkach nie w sekundach. :D trzeba by zmienić" SEC." na "frames" :D

Drac030: tak też sądziłem iż MOVE będzie tożsame z kopiowaniem stringów :D

Seban

Ostatnio edytowany przez seban (2008-02-06 11:44:41)

28

Odp: TBXL - miejsce na dane

Lizard napisał/a:

Na szybkość wykonywania programu ma też wpływ długość nazw zmiennych, więc używanie długiej nazwy BUFF (w porównaniu z krótkim A$) spowalnia wykonanie MOVE.

ROTFL miesiąca.

Hitler, Stalin, totalniak, SSman, NKWDzista, kaczor dyktator, za długo byłem w ChRL, wypowiadam się afektywnie.

29

Odp: TBXL - miejsce na dane

laoo/ng napisał/a:

A gdyby "driver" w kodzie maszynowym umieścić na stronie szóstej, a reszta w pamięci dodatkowej

Zestaw wsatwek maszynowych do miąchania w dodatkowej pamięci za pomoca USR'a pod TBXL to byłoby coś... Nowa jakość dem w Basicu :)
Mam jakiś wycinek z IKSa pozwalający korzystać z dodatkowej pamięci w 130XE. Lizard napisał mi kiedyś USR'a przenoszącego dane ext. ram -> podstawowa pamięc, gdzieś się na dysku kurzy ta procka. Taka pełna biblioteka to byłaby fajna rzecz...

grzybson/SSG^NG

30

Odp: TBXL - miejsce na dane

Mam właśnie taki problem  z metodą , jaką opisywał wyżej larek. Ze względu na użyty tryb graficzny nie mogę dowolnie modyfikować RAMTOPem (muszę go zmieniać co 4KB) , a to co tam zarezerwowałem już mam wykorzytsane na 100%.
Pozostaje zatem zadeklarowanie tablicy np. A$ i korzystanie z niej (peek,poke) jak z fragmentu pamięci. Z deklaracją nie ma problemu (udaje się - ramu wystarcza), ale nie rozumiem jednej rzeczy.
Dlaczego dla:
? adr(a$)
? adr(a$(1))
x = adr(a$): ? x
x = adr(a$(1)): ? x

dostaję zupełnie inne wartości? zwłaszcza nie rozumiem dlaczego jak podstawiam wartość adresu do zmiennej dostaję co innego. oczywiście założenie jest takie, że zmienne już zadeklariowałem, użyłem wcześniej. czy rzeczywiście jest to bezpieczna metoda?

PunBB bbcode test

31

Odp: TBXL - miejsce na dane

Ja dostaję takie same, przynajmniej w programie. Bierzesz pod uwagę, że wartości adr(a$) mogą się zmieniać w zależności od tego, czy program jest uruchomiony przez run, czy tylko robisz ? adr(a$) w trybie bezpośrednim, a również, oidp., w trakcie działania programu, jeśli zmieni się wielkość innych zmiennych łańcuchowych, pojawią się nowe zmienne w ogóle itp.?

PS. a$ jest zadeklarowana - ale czy jest zwymiarowana?

KMK
? HEX$(6670358)

32

Odp: TBXL - miejsce na dane

tak, zwymiarowana. zgodnie z zaleceniem podstawiam tam dowolną wartość pod ostatni znak w łańcuchu przed użyciem. przyznaję, że radośnie sobie to wylogowanie robię bezpośrednio (w ramach testów bo coś mi nie działa ), a nie prez run (muszę to wylogować bezpośredniow programie - może nie ma problemu). starałem się, aby wszytskie zmienne były już zadeklarowane (raz użyte)  przed pobraniem adresu. jeszcze zatem posprawdzam, czy nie zrobiłem skify u siebie, skoro to powinno działać.
dzięki

PunBB bbcode test

33

Odp: TBXL - miejsce na dane

Dla kompletu spróbuj jeszcze:

A=1: ? ADR(A$(A))

Jeśli to piszesz w trybie bezpośrednim dostajesz różne adresy ze względu na to, że długość linii jest różna w każdej z podanych postaci a przecież tablica zmiennych indeksowanych znajduje się ZA KODEM PROGRAMU (linia w trybie bezpośrednim ma numer 32768 i zawsze jest częścią programu mimo, że BASIC jej nie pokazuje przy listowaniu; jest natomiast zapisywana przy CSAVE/SAVE i oczywiście ładowana przez CLOAD/LOAD). Tokeny indeksujące ciąg zajmują 2 bajty, liczba indeksująca ciąg zajmuje 6 bajtów, zmienna indeksująca zajmuje 1 bajt.
Przy wykonaniu tych samych instrukcji w kodzie programu niezależnie od postaci dostaniesz zawsze ten sam adres, ponieważ linia 32768 ma wtedy tylko token RUN.

Edit: W trakcie działania programu nie może się zmienić rozmiar zmiennych (nie można redeklarować zmiennych w BASICu), wszystkie zmienne deklarowane są w trakcie parsowania linii przy wprowadzaniu. W trakcie działania programu zatem zmienne się nie przesuwają w pamięci.

Ostatnio edytowany przez mono (2010-04-16 11:14:26)

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

34

Odp: TBXL - miejsce na dane

monoEdit napisał/a:

W trakcie działania programu nie może się zmienić rozmiar zmiennych (nie można redeklarować zmiennych w BASICu), wszystkie zmienne deklarowane są w trakcie parsowania linii przy wprowadzaniu. W trakcie działania programu zatem zmienne się nie przesuwają w pamięci.

Racja. Może się to zmienić jedynie w sytuacji (rzadkiej) kiedy program sam dodaje do siebie albo modyfikuje swój kawałek, np. jedną linię. Jest to bardzo rzadka sytuacja i trudno, żeby twórca programu o niej nie wiedział :)

KMK
? HEX$(6670358)

35

Odp: TBXL - miejsce na dane

Rzeczywiście. Sztuczka z POKE 842,13. Ale to chyba jedyny (poza USR i świadomym przesuwaniem programu w pamięci procedurami maszynowymi) sposób na samomodyfikację programu w BASICu?

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

36

Odp: TBXL - miejsce na dane

Jedyny mi znany :)

KMK
? HEX$(6670358)

37

Odp: TBXL - miejsce na dane

czy te różnice między ADR(A$) i ADR(A$(1)) nie polegają na różnym interpretowaniu kodu przez edytor ?

ADR([zmienna]):

ADR(A$): zmienna = A$ - pobierz i zwróć adres przypisanej zmiennej

ADR(A$(1)): zmienna = A$(1) - ze zmiennej A$ pobierz pierwszy znak do "bufora", pobierz i zwróć adres przypisanej zmiennej -> adres bufora!

___
Press play on tape...

38

Odp: TBXL - miejsce na dane

ADR zwraca adres w pamięci tego, co mu podamy. tak więc ADR(A$) to adres ciągu tekstowego (jego pierwszego bajtu/znaku), A$(N) adres n-tego znaku ciągu tekstowego. Samo ADR nie przypisuje nic niczemu.
"Bufor" który pewnie masz na myśli jest używany przez funkcje STR$ i CHR$ do tworzenia w locie nowych ciągów tekstowych i znajduje się pod adresem $5c0 dla CHR$ i $580 dla STR$ - zajmuje odpowiednio $40 i $80 bajtów, a więc ciąg tymczasowy powinien mieć co najwyżej 64 lub 128 znaków. Ponieważ nie jest on alokowany dynamicznie, jest to przyczyną błędnego działania konstrukcji

IF CHR$(34)=CHR$(35) THEN ? "ERROR!"

i analogicznej z STR$ (porównanie w przypadku STR$ zwróci 1 tylko kiedy obydwa ciągi mają taką samą długość niezależnie od zawartości).

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje