🚀 go-pugleaf

> chcialbym przekonwertowac liczbe z postaci intelowskiej
> do zwyklego stringa, czyli normalnie jest tak
> a:int64
> a:=1
> rzutuje na stringa - czyli jest tak
> "$01$00$00$00$00$00$00$00"

ty cos kombinujesz. od kiedy to ot tak sobie mozna int64 rzutowac na 
stringa?

albo: jak to robisz?

-- 
Azarien

Wiktor S. wrote:
>> chcialbym przekonwertowac liczbe z postaci intelowskiej
>> do zwyklego stringa, czyli normalnie jest tak
>> a:int64
>> a:=1
>> rzutuje na stringa - czyli jest tak
>> "$01$00$00$00$00$00$00$00"
> 
> ty cos kombinujesz. od kiedy to ot tak sobie mozna int64 rzutowac na 
> stringa?
> 
> albo: jak to robisz?
> 

Przecierz w asemblerze nie ma rzutowania,
wydaje mi sie ze to taki 'skrot myslowy'.
Poczekajmy az OP doprecyzuje czy chodzi mu
o zmiane kolejnosci bajtow, czy cos z pogranicza
endianowosci, czy tez jeszcze cos innego.

-- 
Pozdrawiam
Lopez

> Przecierz w asemblerze nie ma rzutowania,
> wydaje mi sie ze to taki 'skrot myslowy'.
> Poczekajmy az OP doprecyzuje czy chodzi mu
> o zmiane kolejnosci bajtow, czy cos z pogranicza
> endianowosci, czy tez jeszcze cos innego.
Panowie, a czy ktos powiedzial, ze ja pisze tylko w czystym assemblerze ?
To po pierwsze :)
Rzutowanie, czyli traktowanie liczby zapisanej w postaci intelowskiej na
postac "zwykla" cokolwiek mialoby to oznaczac
Z tym sobie juz powradzilem poradzilem
procedure ValueToValueIntel(var BufferIn;var BufferOut;const
BufferLen:integer);
  var
      pBufferIn:pByte;
      pBufferOut:pByte;
  begin
  If BufferLen =0 then exit;
  pBufferIn:=@BufferIn;
  pBufferOut:=@BufferOut;
  Inc(pBufferOut,BufferLen-1);
  asm
    PUSH EAX
    PUSH EBX
    PUSH ECX
    MOV ECX,BufferLen
    LEA EBX,pBufferIn
    MOV EBX,[EBX]
    LEA EDX,pBufferOut
    MOV EDX,[EDX]
    @@Loop:

    MOV EAX,[EBX]
    MOV [EDX-3],EAX
    inc EBX
    inc EBX
    inc EBX
    inc EBX
    DEC EDX
    DEC EDX
    DEC EDX
    DEC EDX
    DEC ECX
    DEC ECX
    DEC ECX
    DEC ECX
    JNZ @@Loop
    POP ECX
    POP EBX
    POP EAX
  end;
end;
Oczywiscie dla uproszczenia liczby przesylane beda 8 bajtowe czyli int64
Nie wiem tylko czy lepiej dac cztery razy inc czy raz add ( coi bedzie
szybsze) ?
Druga sprawa, czy ktos wie dlaczego dwie instrukcje czyli bsr i bsf zwracaj
a ten sam wynik ???
MOV EAX, 1
bsr EBX,EAX   // EBX =7 przeciez to jest Bit Scan Reverse ???!!

MOV EAX, 1
bsf EBX,EAX   // EBX =7   przeciez to jest Bit Scan Forward ???!!
????

On Mon, 4 Dec 2006 20:46:04 +0100, mikezum wrote:

> MOV EAX, 1
> bsr EBX,EAX   // EBX =7 przeciez to jest Bit Scan Reverse ???!!
> 
> MOV EAX, 1
> bsf EBX,EAX   // EBX =7   przeciez to jest Bit Scan Forward ???!!
> ????

soory nie mialobyc eax,1 tylko eax,128
MOV EAX, 128
bsr EBX,EAX   // EBX =7 przeciez to jest Bit Scan Reverse ???!!

MOV EAX, 128
bsf EBX,EAX   // EBX =7   przeciez to jest Bit Scan Forward ???!!
????

mikezum wrote:

> Nie wiem tylko czy lepiej dac cztery razy inc czy raz add ( coi bedzie
> szybsze) ?

Add bedzie szybsze

> Druga sprawa, czy ktos wie dlaczego dwie instrukcje czyli bsr i bsf
> zwracaj a ten sam wynik ???
> MOV EAX, 128
> bsr EBX,EAX   // EBX =7 przeciez to jest Bit Scan Reverse ???!!
> 
> MOV EAX, 1
> bsf EBX,EAX   // EBX =7   przeciez to jest Bit Scan Forward ???!!
> ????

Obie podaja numer pierwszego napotkanego bitu rownego 1. Jedna instrukcja
skanuje operand od najstarszego bitu do najmlodszego, a druga odwrotnie. W
twoim wypadku

EAX = 00000000000000000000000010000000b

Innymi slowy, niezaleznie z ktorej strony skanujesz EAX, bit numer 7 bedzie
pierwszym napotkanym bitem rownym 1

wystarczy, czy bardziej po ludzku napisac?

-- 
Michal Schulz

mikezum wrote:
>> Przecierz w asemblerze nie ma rzutowania,
>> wydaje mi sie ze to taki 'skrot myslowy'.
>> Poczekajmy az OP doprecyzuje czy chodzi mu
>> o zmiane kolejnosci bajtow, czy cos z pogranicza
>> endianowosci, czy tez jeszcze cos innego.
> Panowie, a czy ktos powiedzial, ze ja pisze tylko w czystym assemblerze ?
> To po pierwsze :)
> Rzutowanie, czyli traktowanie liczby zapisanej w postaci intelowskiej na
> postac "zwykla" cokolwiek mialoby to oznaczac

Możesz zdefiniować pojęcia "postać intelowska" i "postać zwykła"?

> Z tym sobie juz powradzilem poradzilem
> procedure ValueToValueIntel(var BufferIn;var BufferOut;const
> BufferLen:integer);

Czemu var w parametrach?

>   var
>       pBufferIn:pByte;
>       pBufferOut:pByte;
>   begin
>   If BufferLen =0 then exit;
>   pBufferIn:=@BufferIn;
>   pBufferOut:=@BufferOut;
>   Inc(pBufferOut,BufferLen-1);
>   asm
>     PUSH EAX
>     PUSH EBX
>     PUSH ECX
>     MOV ECX,BufferLen
>     LEA EBX,pBufferIn
>     MOV EBX,[EBX]
>     LEA EDX,pBufferOut
>     MOV EDX,[EDX]
>     @@Loop:
> 
>     MOV EAX,[EBX]
>     MOV [EDX-3],EAX
>     inc EBX
>     inc EBX
>     inc EBX
>     inc EBX
>     DEC EDX
>     DEC EDX
>     DEC EDX
>     DEC EDX
>     DEC ECX
>     DEC ECX
>     DEC ECX
>     DEC ECX
>     JNZ @@Loop
>     POP ECX
>     POP EBX
>     POP EAX
>   end;
> end;
> Oczywiscie dla uproszczenia liczby przesylane beda 8 bajtowe czyli int64

Oczywiście Twój kod nie działa tak, jak sobie wyobrażasz, tzn. nie 
zmienia kolejności bajtów i w dodatku zamazuje inne dane.

> Nie wiem tylko czy lepiej dac cztery razy inc czy raz add ( coi bedzie
> szybsze) ?

Dodawanie i odejmowanie. Jedna instrukcja będzie tutaj szybsza niż cztery.

> Druga sprawa, czy ktos wie dlaczego dwie instrukcje czyli bsr i bsf zwracaj
> a ten sam wynik ???
> MOV EAX, 1
> bsr EBX,EAX   // EBX =7 przeciez to jest Bit Scan Reverse ???!!
> 
> MOV EAX, 1
> bsf EBX,EAX   // EBX =7   przeciez to jest Bit Scan Forward ???!!

Pewnie dlatego, że tak powinno być zgodnie z definicją tych instrukcji.

Czesc

Uzytkownik "mikezum" <noname@poczta.onet.pl> napisal w wiadomosci
news:8j3qqhx2oh2t.16ahj7wfz15t2$.dlg@40tude.net...
> chcialbym przekonwertowac liczbe z postaci intelowskiej
> do zwyklego stringa, czyli normalnie jest tak
> a:int64
> a:=1
> rzutuje na stringa - czyli jest tak
> "$01$00$00$00$00$00$00$00"
> a chcialbym zeby bylo tak
> "$00$00$00$00$00$00$00$01"
> jak to zrobic bardzo szybko ( bez kopiowania bajt po bajcie), bo
kopiowanie

Jesli chcesz, zeby pierwszy bajt stal sie ostatnim, a ostatni pierwszym to
bez kopiowania po bajcie sie nie obejdzie.

> pamieci ztcw odbywa sie dla pierwszego i drugiego operandu w te sama
strone

Tak, to prawda, jesli mówimy o operacji typu movs...
[...]
> procedure ValueToValueIntel(var BufferIn;var BufferOut;const
> BufferLen:integer);

Chyba lepiej (klarowniej) byloby tak:
procedure ValueToValueIntel(const BufferIn;var BufferOut;const
BufferLen:integer);

>     LEA EBX,pBufferIn
>     MOV EBX,[EBX]

Tu bym dal po prostu:
    mov    ebx, [pBufferIn]
albo jeszcze prosciej - odwolal bezposrednio do parametrów zamiast do
zmiennej tymczasowej:
    mov    ebx, [BufferIn]

>     LEA EDX,pBufferOut
>     MOV EDX,[EDX]

a tu:
    mov    edx, [BufferOut] (tez bez zmiennej tymcz.)
    add    edx, ecx (koniec bufora)
i dodalbym (*1):
    shr    ecx, 2

>     MOV EAX,[EBX]
>     MOV [EDX-3],EAX
>     inc EBX
>     inc EBX
>     inc EBX
>     inc EBX
>     DEC EDX
>     DEC EDX
>     DEC EDX
>     DEC EDX

a to bym zastapil przez:
    dec    edx
    mov    al, [ebx]
    inc    ebx
    mov    [edx], al

lub (zwróc uwage na zmiane kolejnosci bajtów przed zapisem):

    mov    eax, [ebx]
    lea    ebx, [ebx + 4]
    xchg    al, ah
    lea    edx, [edx - 4]
    rol    eax, 16
    xchg    al, ah
    mov    [edx], eax

[...]
>     DEC ECX
>     DEC ECX
>     DEC ECX
>     DEC ECX

a tu zostawil tylko jeden dec ecx (patrz *1)

     DEC ECX
     JNZ @@Loop
-- 
Pozdrawiam :-)
Bartek
PS. Kod pisany "z glowy", wiec nie dam glowy, ze bezbledny...

Bartek Dajewski wrote:
> Czesc
> 
> Uzytkownik "mikezum" <noname@poczta.onet.pl> napisal w wiadomosci
> news:8j3qqhx2oh2t.16ahj7wfz15t2$.dlg@40tude.net...
>> chcialbym przekonwertowac liczbe z postaci intelowskiej
>> do zwyklego stringa, czyli normalnie jest tak
>> a:int64
>> a:=1
>> rzutuje na stringa - czyli jest tak
>> "$01$00$00$00$00$00$00$00"
>> a chcialbym zeby bylo tak
>> "$00$00$00$00$00$00$00$01"
>> jak to zrobic bardzo szybko ( bez kopiowania bajt po bajcie), bo
> kopiowanie
> 
> Jesli chcesz, zeby pierwszy bajt stal sie ostatnim, a ostatni pierwszym to
> bez kopiowania po bajcie sie nie obejdzie.

Obejdzie się. Kopiowanie po 32 bity i BSWAP po drodze.

Bartek Dajewski napisał(a):
> lub (zwróc uwage na zmiane kolejnosci bajtów przed zapisem):
> 
>     mov    eax, [ebx]
>     lea    ebx, [ebx + 4]
>     xchg    al, ah
>     lea    edx, [edx - 4]
>     rol    eax, 16
>     xchg    al, ah
>     mov    [edx], eax

a ja zamiast
>     xchg    al, ah
 >     rol    eax, 16
 >     xchg    al, ah

dałbym po prostu
       bswap eax

Pozdrawiam,
Morris

Cześć.

Użytkownik "Bernard" <bernard@earth.net> napisał w wiadomości
news:el47iu$qie$1@achot.icm.edu.pl...
> Bartek Dajewski wrote:
[...]
> > Jesli chcesz, zeby pierwszy bajt stal sie ostatnim, a ostatni pierwszym
to
> > bez kopiowania po bajcie sie nie obejdzie.
>
> Obejdzie się. Kopiowanie po 32 bity i BSWAP po drodze.

Fakt. Ja miałem na myśli raczej konieczność zabawy pojedynczymi bajtami niż
jednobajtowe operacje odczytu lub zapisu pamięci. A swoją drogą (dawno nie
zaglądałem do materiałów dotyczących optymalizacji) - czy mi się wydaje, czy
na starszych typach procesorów bswap było mniej wydajne niż xchg?
-- 
Pozdrawiam :-)
Bartek

> Obie podaja numer pierwszego napotkanego bitu rownego 1. Jedna instrukcja
> skanuje operand od najstarszego bitu do najmlodszego, a druga odwrotnie. W
> twoim wypadku
> 
> EAX = 00000000000000000000000010000000b
> 
> Innymi slowy, niezaleznie z ktorej strony skanujesz EAX, bit numer 7 bedzie
> pierwszym napotkanym bitem rownym 1
> 
> wystarczy, czy bardziej po ludzku napisac?
Czyli kazdy bajt w EAX jst skanowany odzielnie ?
Tak rozumiem z Twojej wypowiedzi.
A jak najszybciej przeskanowac caly operand od nastarszego bitu w
operandzie, a nie w bajcie ?

> Oczywiście Twój kod nie działa tak, jak sobie wyobrażasz, tzn. nie 
> zmienia kolejności bajtów i w dodatku zamazuje inne dane.

Dalczego zamazuje dane ?, skoro BufferOut jest allokowany gdzies w
procedurze wywolujacej, przecieztak samo robi sie tez w api.

> 
> Chyba lepiej (klarowniej) byloby tak:
> procedure ValueToValueIntel(const BufferIn;var BufferOut;const
> BufferLen:integer);
Masz racje zamiast var przeciez mozna dac const, ale chcialem, zeby po
naglowku funkcji mozna bylo wyczaic, ze funkcja zmienia dane :)
chociaz przyrost predkosci jest niewielki, to i tak zmienilem na to co
proponujesz, nawet 'producenci' jezyka stosuja taka konwencje brrrrr.

mikezum wrote:

>> EAX = 00000000000000000000000010000000b
>> 
>> Innymi slowy, niezaleznie z ktorej strony skanujesz EAX, bit numer 7
>> bedzie pierwszym napotkanym bitem rownym 1
>> 
>> wystarczy, czy bardziej po ludzku napisac?
> Czyli kazdy bajt w EAX jst skanowany odzielnie ?

nie. instrukcja operuje na rejestrze EAX traktujac go jako calosc. W jaki
sposob z mojego opisu wyciagnales swoje wnioski?

> Tak rozumiem z Twojej wypowiedzi.

zatem nic nie zrozumiales

> A jak najszybciej przeskanowac caly operand od nastarszego bitu w
> operandzie, a nie w bajcie ?

To teraz jeszcze bardziej proste wyjasnienie.

Wyobraz sobie rejestr eax, skladajacy sie z 32 bitow. Bit najstarszy
(najbardziej wazny) ma numer 31, bit najmlodszy ma numer 0. Liczba 128 w
systemie szesnastkowym to 0x00000080, lub tez w systemie binarnym
00000000000000000000000010000000b. Innymi slowy, liczba 128 to taka liczba,
w ktorej bit numer 7 jest rowny 1 (jeden), a *wszystkie* pozostale bity sa
rowne 0 (zero).

Instrukcja BSF (Bit scan forward) przeglada drugi operand (w naszym wypadku
rejestr EAX zawierajacy liczbe 128) od najmlodszego bitu do najstarszego.
Jesli nie znajdzie zadnego bitu rownego 1 (jeden), ustawi flage Z w
rejestrze EFLAGS. W przeciwny wypadku flaga Z zostanie wyzerowana, a w
pierwszym operandzie (EBX w przypadku twojego kodu) zostanie zapisany numer
pierwszego bitu ktorego wartosc jest rowna 1 (jeden). W podanym przez
ciebie przypadku bedzie to liczba 7 (bit numer 7 jest pierwszym ustawionym
bitem, patrzac od PRAWEJ strony).

Instrukcja BSR (Bit scan reverse) przeglada drugi operand (w naszym wypadku
rejestr EAX zawierajacy liczbe 128) od najstarszego bitu do najmlodszego.
Jesli nie znajdzie zadnego bitu rownego 1 (jeden), ustawi flage Z w
rejestrze EFLAGS. W przeciwny wypadku flaga Z zostanie wyzerowana, a w
pierwszym operandzie (EBX w przypadku twojego kodu) zostanie zapisany numer
pierwszego bitu ktorego wartosc jest rowna 1 (jeden). W podanym przez
ciebie przypadku bedzie to liczba 7 (bit numer 7 jest pierwszym ustawionym
bitem, patrzac od LEWEJ strony).

Wystarczajaco prosta odpowiedz?

PS. gdyby w rejestrze EAX byla liczba 1073741826 (0x40000002 w systemie
szesnastkowym, lub tez 01000000000000000000000000000010 w systemie
dwojkowym), to instrukcja

BSF ebx, eax

owocowalaby wartoscia 1 w rejestrze ebx, natomiast instrukcja

BSR ebx, eax

owocowalaby wartoscia 30 w rejestrze ebx. Potrafisz zrozumiec dlaczego?

-- 
Michal Schulz

Użytkownik "Bartek Dajewski" <bartek@UsunTo.tradiss.com.pl> napisał w
wiadomości news:el48ga$evi$1@news.onet.pl...
> Cześć.
>
> Użytkownik "Bernard" <bernard@earth.net> napisał w wiadomości
> news:el47iu$qie$1@achot.icm.edu.pl...
> > Bartek Dajewski wrote:
> [...]
> > > Jesli chcesz, zeby pierwszy bajt stal sie ostatnim, a ostatni
pierwszym
> to
> > > bez kopiowania po bajcie sie nie obejdzie.
> >
> > Obejdzie się. Kopiowanie po 32 bity i BSWAP po drodze.
>
> Fakt. Ja miałem na myśli raczej konieczność zabawy pojedynczymi bajtami
niż
> jednobajtowe operacje odczytu lub zapisu pamięci. A swoją drogą (dawno nie
> zaglądałem do materiałów dotyczących optymalizacji) - czy mi się wydaje,
czy
> na starszych typach procesorów bswap było mniej wydajne niż xchg?
> -- 
> Pozdrawiam :-)
> Bartek
>

Cześć.

Użytkownik "Bartek Dajewski" <bartek@UsunTo.tradiss.com.pl> napisał w
wiadomości news:el48ga$evi$1@news.onet.pl...
[...]
> czy
> na starszych typach procesorów bswap było mniej wydajne niż xchg?

No i się wyjaśniło. Ale siara! W spisie rozkazów, który mam jeszcze z czasów
młodych P1 jest napisane, że bswap potrzebuje nie jednego tylko 11
(jedenastu!) cykli! Nigdy do tej pory tego nie weryfikowałem i tylko wbiłem
sobie do łba, żeby go zastępować kombinacją xchg + rol + xchg, bo jest
szybsza. A wygląda na to, że to zwykła literówka... Ale zonk!!! No cóż -
całe życie się człowiek uczy. Zasady ograniczonego zaufania też... To mi
tylko przypomniało stare, sprawdzone powiedzenie, że jak na płocie jest
napisane d*a, to nie trza od razu wierzyć, bo potem można długo drzazgi
wyciągać...
-- 
Pozdrawiam :-)
Bartek
PS. I dziękuję Wam za ten wątek, bo nie wiem jak długo tkwiłbym jeszcze w
tym koszmarnym błędzie.
PPS. Opis już poprawiłem, a teraz chyba sobie każę za karę 100 razy w
zeszycie zapisać, że bswap wykonuje się w _JEDNYM_ cyklu.

Czesc.

Uzytkownik "mikezum" <noname@poczta.onet.pl> napisal w wiadomosci
news:8hpmldksmqgr.1b5c321wbnuw8$.dlg@40tude.net...
> >
> > Chyba lepiej (klarowniej) byloby tak:
> > procedure ValueToValueIntel(const BufferIn;var BufferOut;const
> > BufferLen:integer);
> Masz racje zamiast var przeciez mozna dac const
[...]
> chociaz przyrost predkosci jest niewielki, to i tak zmienilem

Zauwazyles przyrost predkosci po zmianie naglówka!? Nic z tego nie
rozumiem...
-- 
Pozdrawiam :-)
Bartek

mikezum wrote:
>> Oczywiście Twój kod nie działa tak, jak sobie wyobrażasz, tzn. nie 
>> zmienia kolejności bajtów i w dodatku zamazuje inne dane.
> 
> Dalczego zamazuje dane ?, skoro BufferOut jest allokowany gdzies w
> procedurze wywolujacej, przecieztak samo robi sie tez w api.

Dlatego:
MOV [EDX-3],EAX

Na początku EDX zawiera adres początku bufora, a delikwent pisze o 3 
bajty wcześniej, czyli poza buforem. Jeśli bufor był alokowany 
dynamicznie - rozwali w ten sposób listę alokacji subalokatora. Jeśli 
był alokowany statycznie - zamaże zmienną umieszczoną przed buforem.

Cześć.

Użytkownik "Bernard" <bernard@earth.net> napisał w wiadomości
news:el616u$h97$1@achot.icm.edu.pl...
> mikezum wrote:
[...]
> > Dalczego zamazuje dane ?, skoro BufferOut jest allokowany gdzies w
>
> Dlatego:
> MOV [EDX-3],EAX
>
> Na początku EDX zawiera adres początku bufora, a delikwent pisze o 3

Nie początku tylko końca. Wcześniej jest:
    pBufferOut:=@BufferOut;
    Inc(pBufferOut,BufferLen-1);
-- 
Pozdrawiam :-)
Bartek

Bartek Dajewski wrote:
> Cześć.
> 
> Użytkownik "Bernard" <bernard@earth.net> napisał w wiadomości
> news:el616u$h97$1@achot.icm.edu.pl...
>> mikezum wrote:
> [...]
>>> Dalczego zamazuje dane ?, skoro BufferOut jest allokowany gdzies w
>> Dlatego:
>> MOV [EDX-3],EAX
>>
>> Na początku EDX zawiera adres początku bufora, a delikwent pisze o 3
> 
> Nie początku tylko końca. Wcześniej jest:
>     pBufferOut:=@BufferOut;
>     Inc(pBufferOut,BufferLen-1);

No fakt, nie zauważyłem. Ale bajtów i tak nie zamienia ;)

> Zauwazyles przyrost predkosci po zmianie naglówka!? Nic z tego nie
> rozumiem...

oczywiscie pod warunkiem, ze dodatkowo nie korzystam ze zmiennych
tymczasowych.... moglem to dopisac wczesniej.....

> owocowalaby wartoscia 30 w rejestrze ebx. Potrafisz zrozumiec dlaczego?
Ddziekuje za odpowiedz, choc sarkazmy nie byly potrzebne.... zreszta
mniejsza o wiekszosc.....
Dla pelnego zrozumienia nalezaloby tylko dodac, ze wynik zwracany przez te
dwie instrukcje liczony zawsze jest od bajtu najmlodszego, a nie tak jak ja
spodziewlem sie - od tego czy jest to bsf czy bsr. W kazdym badz razie
dzieki.

> No fakt, nie zauważyłem. Ale bajtów i tak nie zamienia ;)

*4bajty ^4bajty
po wykonaniu instrukcji
^4bajty *4bajty

prosciej
1234 56789
5678 1234

mikezum wrote:

>> owocowalaby wartoscia 30 w rejestrze ebx. Potrafisz zrozumiec dlaczego?
> Ddziekuje za odpowiedz, choc sarkazmy nie byly potrzebne.... zreszta
> mniejsza o wiekszosc.....

czasem wredny bywam :)

> Dla pelnego zrozumienia nalezaloby tylko dodac, ze wynik zwracany przez te
> dwie instrukcje liczony zawsze jest od bajtu najmlodszego, 

Dla pelnego zrozumienia nalezaloby dodac ze numeracja bitow jest okreslona w
dokumentacji dotyczacej danej architektury (x86 w tym wypadku) i nie zalezy
od aktualnie wykonywanej instrukcji :-D

pozdrawiam,
M.

-- 
Michal Schulz

> Dla pelnego zrozumienia nalezaloby dodac ze numeracja bitow jest okreslona w
> dokumentacji dotyczacej danej architektury (x86 w tym wypadku) i nie zalezy
> od aktualnie wykonywanej instrukcji :-D
> 
> pozdrawiam,
> M.
Masz racje, choc w assemblerze pisze bardzo malo, jesli jest potrzebna duza
szybkosc ( choc wcale nie uwazam, ze znam go dobrze - raczej w stopniu
minimalnym ) :) Nie wszystko, co dla Ciebie wydaja sie oczywiste, dla mnie
tez jest...
Pozdrowka :)