asembler.106janko,
-> #104, biber
> Covek ce sa pak, koristeci asembler, truditi da sto je moguce
> vise
> podataka drzi i prebacuje koristeci registre procesora koji su
> neuporedivo brzi od memorije.
To svaki optimizujući kompajler radi bez problema.
> neuporedivo brzi od memorije. Pa zatim tu su ostali sitni
> dobici
> (trikovi za deljenje sa 10, proveravanje znaka operacije,
> "generisanje nule
Sve te trikove zna i svaki dobar kompajler.
Očigledno nisi skoro gledao kakav sors generišu dobri kompajleri.
> Sve zajedno kad se skupi izadje da je ipak
> asembler brzi.
Veoma retko, samo kada se čovek polomi da optimizuje određenu malu
petlju. Većinu koda koji izoptimizuje kompajler ne bi stigli ni svi
Kinezi sveta da izoptimizuju...
asembler.107janko,
-> #106, janko
Na temu diskusije "da li kompajleri znaju da pišu kao asm programeri":
Evo kako Borland C++ 4.5 prevodi sledecu funkciju (za 32-bitni kod -- ko
još koristi XT ili 286? -- a koliko asm programera zna da piše 386 i
jači kod?):
int mnozi( int a )
{
return a * 31;
}
Prevod je:
_mnozi proc near
;
; int mnozi( int a )
;
push ebp
mov ebp,esp
;
; {
; return a * 31;
;
mov eax,dword ptr [ebp+8]
mov edx,eax
shl eax,5
sub eax,edx
;
; }
;
pop ebp
ret
_mnozi endp
Primetite kako je izvedeno množenje sa 31, tako da se ne radi
pravo MUL. Može li asm programer bolje? Ne.
OK, reći će neko, ali tu je overhead poziv funkcije (na stek--sa steka).
ako se to smatra kritičnim, doda se samo jedna ključna reč u deklaraciji
funkcije:
inline int mnozi( int a )
{
return a * 31;
}
Pogledajmo sad prevod funkcije koja poziva našu "mnozi"
Funkcija:
int sloz( int c )
{
return mnozi( c ) + 33;
}
Prevod:
@sloz$qi proc near
;
; int sloz( int c )
;
push ebp
mov ebp,esp
;
; {
; return mnozi( c ) + 33;
;
mov eax,dword ptr [ebp+8]
mov edx,eax
shl eax,5
sub eax,edx
add eax,33
;
; }
;
pop ebp
ret
@sloz$qi endp
Dakle umesto poziva funkcije, sve je ugrađeno "na mesto".
Da je i sloz() inline, ni za nju ne bi postojao overhead itd...
asembler.108biber,
-> #106, janko>> Sve te trikove zna i svaki dobar kompajler.
>>
>> Ocigledno nisi skoro gledao kakav sors generisu dobri kompajleri.
Evo pogledao sam deo koda iz embe.exe
Pazi kako se doturaju argumenti potprogramu (funkciji).
push si ; ovo je argument
call potprogram
.....
.....
potprogram: push bp
mov bp,sp
push si
push di
mov di,w[bp+4]
Posle ovih operacija se u di registru nadje vrednost
ulaznog argumenta funkcije (potprograma), tj. ono sto je
bilo u si pre pozivu potprograma.
Sve zajedno prilicno neefikasno. Pogotovo sto ovakvih
poziva imas na svakih nekoliko linija programa. Takodje
u okviru potprograma imas poziv drugog potprograma a cesto
i nekoliko nivoa poziva.
Obren rece da je program preveden sa BC 3.1 i sa svim
optimizacijama ukljucenim.
Na koji kompajler si ti mislio kad si rekao "optimizujuci" ?
Ajde prevedi embe.cpp sa njim pa mi okaci u mail.
E da, na kraju, vidjao sam programe koji prilikom svakog
poziva potprograma proverevaju jos i da li se stek prepunio.
I to, naravno, tako sto pozovu potprogram koji ce to da
proveri. Tek to je gubitak vremena.
asembler.109embe,
-> #108, biber>> optimizacijama ukljucenim.
>> Na koji kompajler si ti mislio kad si rekao "optimizujuci" ?
>> Ajde prevedi embe.cpp sa njim pa mi okaci u mail.
Evo i ja da se ukljucim. Nije stvar u embe.cpp. Program je i
pisan tako da se sastoji od nekoliko kratkih potprograma, umesto
da se sastoji od samo jedne funkcije. O prednostima razlaganja
programa na vise malih funkcija ne bih pricao. Mogao sam, ali
nisam da ovaj program napisem u obliku jedne funkcije ali smatram
da je takav nacin pisanja programa STETAN po kulturu programiranja.
Ni na kraj pameti mi nije bilo da ovo "usitnjavanje" moze dovesti
do bitnog usporenja programa.
BTW, nasi algoritmi su razliciti pa je besmisleno porediti duzinu
asemblerskog koda koji si ti napravio i onog kojeg vidis u debugeru,
a sto se tice pozivanja potprograma, koliko mi se cini, u tvom
algoritmu i nema potprograma i prenosenja argumenata.
>> E da, na kraju, vidjao sam programe koji prilikom svakog
>> poziva potprograma proverevaju jos i da li se stek prepunio.
>> I to, naravno, tako sto pozovu potprogram koji ce to da
>> proveri. Tek to je gubitak vremena.
To sto si ti video je program kompajliran sa opcijom "Check stack
overflow", koji omogucava da se proverava prepunjenost Stack-a,
sto je vrlo korisno u fazi pisanja programa, jer greske u programu
ciji je uzrok prepunjen stack su veoma veoma zametne za otkrivanje
a manifestuju se haoticnim radom programa. U svakom slucaju, konacna
verzija programa se kompajlira sa iskljucenom opcijom za proveru
stack-a. To sto je provera stacka ostala u kodu, greska je zaboravnog
programera a ne kompajlera, jer kompajleri po defaultu imaju ukljucenu
ovu opciju, kao i opciju za debug informacije itd. Ovo naravno pricam
za Borland kompajlere. I jos nesto, program embe.exe je kompajliran
sa BC++ 3.1, a poznato je da je to kompajler star CETIRI godine i
da je od tada mnogo novih verzija izaslo, a razlika se gotovo uvek
ogledala u poboljsanim optimizacijama (izmedju ostalog).
Pozdrav, Milan.
asembler.110biber,
-> #107, janko>> mov edx,eax
>> shl eax,5
>> sub eax,edx
Mudro, nema sta. Pretpostavljam da su i neki drugi mnozitelji
uzeti u obzir. Mozda izlazi iz okvira teme, ali da li slicno
razmisljaju i ostali prevodioci ( MS, Watcom )?
Ipak i dalje ostaje ono doturanje parametara preko steka kao
visak. Covek ipak bolje organizuje podatke.
>> -- a koliko asm programera zna da pise 386 i
U principu samo ubacis "E" ispred registra :)
Ja bih pitao "a koliko asm programera postoji"
Evo ova tema je mesecima prazna.
asembler.111janko,
-> #110, biber
> Mudro, nema sta. Pretpostavljam da su i neki drugi
> mnozitelji
> uzeti u obzir. Mozda izlazi iz okvira teme, ali da li slicno
> razmisljaju i ostali prevodioci ( MS, Watcom )?
Sve što se može uzeti u obzir se uzima u obzir. Moderani kompajleri
nisu džabe tako ogromni -- za neke optimizacije potrebno je izuzetno
mnogo memorije da bi se svi parametri uzeli u obzir -- toliko da ne
postoji čovek koji bi peške uspeo da to izvede (morao bi da piše
po papiru veličine stadiona i da "igra šah" birajući najbolje
kombinacije danima... a to se dogodi između klika na Run i
startovanja programa...
Opet da ti ponovim, sigurno je da SVE što ti umeš da izvedeš ume i
kompajler.
> Ipak i dalje ostaje ono doturanje parametara preko steka kao
> visak. Covek ipak bolje organizuje podatke.
Malo sutra, višak.
Prokazao sam ti šta možeš da izvedeš u C++ -- da potpuno eliminišeš
poziv funkcije. U Asmu to možeš, ako praviš makroe. Ali znaš koliko
treba truda da umesto duže funkcije napišeš dug makro, i da vodiš
računa o tome da makro i sam brlja registre. Ako ga napišeš sa
push/pops obezbedio si ga, ali on je neefikasniji od kompajlerovog
posla jer kompajler ZNA za svaki ekvivalent makro substitucije koji
su registri angažovani i čime su popunjeni. To nijedan asembler ne
zna, niti je moguće napisati takav makro. Znači ako ti se neki
konstrukt pojavljuje na deset mesta morao bi na svakom RUČNO da ga
pišeš i da bi opitmizovao upotrebu registara. Na C++ napišeš JEDNU
funkciju na JEDNOM mestu, a kompajler sve optimizuje i direktno
ugradi u kod kao da si ti to radio danima...
A upotreba tzv. stek frejmova u "klasičnim" funckijama ti daje
slobode koje su nezamenljive. aKo ti bilo koja od njih zatreba u ASM
programu, i tebi je najefikasniji način da koristiš stek-frejm.
asembler.112janko,
-> #110, biber
> >> -- a koliko asm programera zna da pise 386 i
>
> U principu samo ubacis "E" ispred registra :)
Ajde da ti dam program koji si pisao za 8086 i rekao ti "hoću da
koristi 386 instrukcije". Koliko ćeš ga menjati? Za moj C++ sors,
samo prevedem drugim kompajlerom.
> Ja bih pitao "a koliko asm programera postoji"
> Evo ova tema je mesecima prazna.
Ja sam asm programer, kada treba. ;) Ali treba samo u vrlo retkim
situacijama. C i C++ mogu puno toga. Ja sam sa BC pisao .COM programe
koji su imali samo po tridesetak bajtova, npr.
asembler.113biber,
-> #109, embe>> BTW, nasi algoritmi su razliciti pa je besmisleno porediti duzinu
>> asemblerskog koda koji si ti napravio i onog kojeg vidis u debugeru,
Mislim da nisi razumeo o cemu janko i ja pricamo. Nije o duzini
koda nego o optimizaciji.
>> a sto se tice pozivanja potprograma, koliko mi se cini, u tvom
>> algoritmu i nema potprograma i prenosenja argumenata.
Ne secam se, ali nije ni bitno. Kad bi ih bilo sigurno ne bih
nekoliko puta gurao i skupljao podatke sa steka kao sto rade
kompajleri. Ovo je samo jedan najocigledniji primer kako
kompajler ipak losije radi od coveka. Ako malo vise zaceprkas
po kodu nekog programa (tvoj je eto slucajno uzet za primer,
mogao sam da analiziram i vinkov ili mhrkicev ili ...) videces
da su i podaci organizovani na..., pa za coveka na cudan nacin.
Npr. instrukcija mov [bx+di+14] trosi vise vremena od mov [bx]
a ipak kompajleri teze prvoj varijanti. Jednostavno zato sto
prevode mehanicki.
>> stack-a. To sto je provera stacka ostala u kodu, greska je zaboravnog
>> programera a ne kompajlera, jer kompajleri po defaultu imaju ukljucenu
:)) Sem provere, zaboravio je i labele, pa sam sa uzivanjem
mogao da analiziram program.
asembler.114janko,
Hajde gospodo asemblerski programeri, pogodite i kako se
radi mnozenje sa 10 nekog broja u eax na BC 4.5, ali
da ne gledate u resenje (citaj kompajlirate njime).
Resenje sutra.
asembler.115bceklic,
-> #110, biber> Ja bih pitao "a koliko asm programera postoji"
> Evo ova tema je mesecima prazna.
Imam iza sebe par mega asm sourceta sto me pretpostavljam
stavlja u ovu grupu :) Nekada sam sve poslove radio u asm-u (lude
godine..) ali u zadnje vreme pokusavam da upotrebu asm-a smanjim na
minimum. Tako asm upotrebljavam samo kada je kriticna brzina
izvrsavanja, oko poslova zastite softvera i antivirusne zastite.
Za vecinu poslova koristim c/c++ a ako je u pitanju neka 'brza'
aplikacija za rad sa bazama tu je naravno clipper ;).
Povodom diskusije o optimizacijima koje nude danasnji kompajleri
i opravdanosti koriscenja asm-a...
I sam sam proveo izvesno vreme proucavajuci kod koji generisu
neki od c kompajlera. Iako sam bio zadrti asm programer moram da
priznam da danas ipak prihvatam cenu nesto sporijeg izvrsavanja na
racun brze izrade, lakseg odrzavanja i portabilnosti.
poz, Blagoje.
asembler.116obren,
-> #113, biber> Ne secam se, ali nije ni bitno. Kad bi ih bilo sigurno ne bih
> nekoliko puta gurao i skupljao podatke sa steka kao sto rade
> kompajleri. Ovo je samo jedan najocigledniji primer kako
> kompajler ipak losije radi od coveka.
Takozvani "stack frame" je opšteprihvaćen način prenosa podataka i
neophodan je ako se želi povezivanje .OBJ datoteka pisanih u različitim
jezicima. Druga prednost je za "reuse" podprograma: ti možeš napisati u
C-u neku funkciju, prevesti je i povezati u LIB koji ćeš kasnije
pozivati iz svojih programa i to će ˙sigurno˙ raditi.
Ako ručno optimizuješ prenos parametara u ASM-u to radiš zavisno od
situacije za koju ti treba. Verovatno ćeš postići spektakularne
rezultate u konkretnom slučaju, ali je "reupotrebljivost" ;) te
procedure vrlo mala. Pitanje je da li ćeš u nekom novom programu koji
budeš pisao imati baš iste registe slobodne za prenos parametara i kakve
ćeš kompromise morati da praviš da bi koristio "staru" funkciju.
Kad smo već kod ovoga, kod C-a postoji i "fastcall" način prosleđivanja
parametara, koji ne koristi STACK FRAME već argumente smešta u slobodne
registre. Problem kod PC-a je što "slobodnih" registara nikad nema na
pretek (kod Borlanda su to, čini mi se, AX, BX i DX).
asembler.117janko,
-> #114, janko
> Hajde gospodo asemblerski programeri, pogodite i kako se
> radi mnozenje sa 10 nekog broja u eax na BC 4.5, ali
> da ne gledate u resenje (citaj kompajlirate njime).
>
> Resenje sutra.
add eax,eax
lea eax,dword ptr [eax+4*eax]
asembler.118janko,
-> #116, obren
> Takozvani "stack frame" je opšteprihvaćen način prenosa podataka i
> neophodan je ako se želi povezivanje .OBJ datoteka pisanih u
> različitim jezicima. Druga prednost je za "reuse" podprograma: ti
> možeš napisati u C-u neku funkciju, prevesti je i povezati u LIB
> koji ćeš kasnije pozivati iz svojih programa i to će ˙sigurno˙
> raditi.
Zapravo, ne!
Stek frejm je mehanizam koji obezbeđuje REKURZIJU. Kada se funkcija
prevede tako da održava stek frejm, garantovano će biti REENTRANT.
Istorijski, stariji kompajleri nisu imali stek frejm -- FORTRAN npr.
Zato FORTRAN procedure nisu reentrant.
Za povezivanja OBJ nastalih različitim kompajlerima stek frejm kao
takav je nebitan, linker to uopšte ne proverava, a još su prvi C
kompajleri mogli da pozivaju fortranske procedure.
asembler.119embe,
-> #113, biber
>> Mislim da nisi razumeo o cemu janko i ja pricamo. Nije o duzini
>> koda nego o optimizaciji.
Ma znam ja o cemu pricate. Ako je putanja izvrsavanja programa ista
najnormalnije je da se brze izvodi program sa manje linija. O tome
sam JA pricao.
asembler.120biber,
-> #112, janko>> Ajde da ti dam program koji si pisao za 8086 i rekao ti "hocu da
>> koristi 386 instrukcije". Koliko ces ga menjati? Za moj C++ sors,
>> samo prevedem drugim kompajlerom.
Slazem se naravno da su visi programski jezici mnogo fleksbilniji.
Svakako nije bez razloga sto se vecina programera okrece C-u.
asembler.121janko,
-> #117, janko
> add eax,eax
> lea eax,dword ptr [eax+4*eax]
Ovo sam namerno ostavio kao primer jer ilustruje netačnost
tvrdnje da je "programiranje za 386 i jače isto što i za 86
samo se dodaje e". Ovde su demonstrirane značajno veće mogućnosti
adresnih modova u odnosu na starinski kod.
asembler.122obren,
-> #118, janko> Zapravo, ne!
> Stek frejm je mehanizam koji obezbeđuje REKURZIJU. Kada se funkcija
> prevede tako da održava stek frejm, garantovano će biti REENTRANT.
Ma ok... nije u tome bila poenta. U principu je bitno samo kojim
redosledom gurneš parametre pre poziva, a funkcija može da ih kupi
kako zna i ume, ne mora biti klasičan stack frame. Međutim, ako
pogledaš uputstvo za Turbo Assembler (povezivanju sa drugim jezicima)
videćeš da je prvo objašnjen stack frame kao standardan mehanizam za
prenos parametara među različitim jezicima. Naravno da linker ne
proverava prilikom povezivanja, jer je to u principu deo programa
u čiji sadržaj on ne ulazi... :)
Replicirao sam o razlozima zašto C onako "glupo" prenosi parametre
u odnosu na način kako bi to neko uradio u asmebleru...
asembler.123janko,
-> #122, obren
> Replicirao sam o razlozima zašto C onako "glupo" prenosi parametre
> u odnosu na način kako bi to neko uradio u asmebleru...
I odgovor je zato da bi podržao rekurzivnost i reentrablinost
funkcija. To je jedini razlog za postojanje stek frejma. Ako se to
ne želi, stvarno postoje drugačiji mehanizmi prenosa parametara.
Dokaz -- Fortran.
asembler.124janko,
-> #122, obren
> Međutim, ako
> pogledaš uputstvo za Turbo Assembler (povezivanju sa drugim
> jezicima)
> videćeš da je prvo objašnjen stack frame kao standardan mehanizam za
> prenos parametara među različitim jezicima.
Ne, uputstvo upravo objašnjava kako KONKRETNI kompajleri organizuju
poziv funckija, i to zato da bi ti mogao da napišeš funkciju i poziv
imitirajući kompajlerov stil.
Da to nije nikakav standard trebalo bi da ti je očigledno: već Turbo
Paskali i turbo C, oba od istog proizvođača, neće po defaultu
generisati pozive funkcija i same funkcije na isti način.
To čak ima uzroke i u definiciji ponašanja jezika: u SVAKOM C-u
funckija nije nadležna za uklanjanje dostavljenih parametara, a u
svakom Paskalu jeste. To je suštinska razlika, a proističe iz
činjenice da se Paskal i C sorsovi prevode pod različitim
pretpostavkama. (Ne čačkaj me na ovu temu, to je oblast kojom se
bavim profesionalno).
asembler.125obren,
-> #124, jankoDa ne repliciram odvojeno na tvoje poruke, sastavio sam citate iz obe:
> I odgovor je zato da bi podržao rekurzivnost i reentrablinost
> funkcija. To je jedini razlog za postojanje stek frejma. Ako se to ne
> želi, stvarno postoje drugačiji mehanizmi prenosa parametara.
> Dokaz -- Fortran.
Da podržava gnežđenje, apsolutno se slažem (nisam nikad ni tvrdio
suprotno), da postoje drugačiji načini prenosa parametara takođe, ali
pitanje je da li ih iko koristi? ;) Ništa nije Bogom dano, ali neke
stvari su opšte prihvaćene iako nisu propisane standardom...
Ok, ajde ako imaš pri ruci, napiši kako prenosi parametre taj Fortran
koji ne koristi stek frejm?
> Da to nije nikakav standard trebalo bi da ti je očigledno: već Turbo
> Paskali i turbo C, oba od istog proizvođača, neće po defaultu
> generisati pozive funkcija i same funkcije na isti način.
Što se tiče tvrdnje da stack frame nije nikakav standard, mislim da
grešiš. Počevši od i80186 postoje i mašinske instrukcije koje ga
formiraju (ENTER/LEAVE). Ne bi ih trpali u mikrokod da nisu videli da
svi to rade na isti način. Svi kompajleri koji su mi došli pod ruku (tu
spada i nekoliko Fortrana) standardno koriste za prenos parametara stek,
a na ulazu u funkciju formiraju frejm na isti način:
PUSH BP
MOV BP, SP
SUB SP, nnn ; količina prostora za lokalne promenljive
; neki Fortrani (!) mogu i da sračunaju nnn,
; slično onom što se pominje u novom standardu C-a
...
(dohvatanje parametara relativno od BP-a. ofseti su različiti)
(u zavisnosti od redosleda stavljanja parametara na stek)
...
RET [nnn] ; [nnn] u slučaju Paskala
> To čak ima uzroke i u definiciji ponašanja jezika: u SVAKOM C-u
> funkcija nije nadležna za uklanjanje dostavljenih parametara, a u
> svakom Paskalu jeste. To je suštinska razlika, a proističe iz
> činjenice da se Paskal i C sorsovi prevode pod različitim
> pretpostavkama.
Veruj mi - zaista znam o čemu govoriš, ali kao što rekoh jedina razlika
je u displejsmentu u odnosu na BP i u tome ko skida parametre. A sve
zajdeno postoje dve varijante. Ja bar ne videh druge, a i te dve
varijante su STANDARDNE i nazivaju se Pascal i C calling convention.
> (Ne čačkaj me na ovu temu, to je oblast kojom se bavim profesionalno).
Pa super, to je razlog više da te čačkam! :) Uvek sam raspoložen da
nešto naučim od iskusnijeg kolege. Nadam se samo da ne gušimo ostale?
asembler.126janko,
-> #125, obren
> Da podržava gnežđenje, apsolutno se slažem (nisam nikad ni tvrdio
> suprotno), da postoje drugačiji načini prenosa parametara takođe,
> ali pitanje je da li ih iko koristi? ;) Ništa nije Bogom dano, ali
> neke stvari su opšte prihvaćene iako nisu propisane standardom...
Ali to sve nema veze sa linkovanjem a pogotovu ne sa povezivanjem
koda iz više jezika!
> Ok, ajde ako imaš pri ruci, napiši kako prenosi parametre taj
> Fortran koji ne koristi stek frejm?
Standardni Fortrani (dakle oni kod kojih je rekurzija nemoguća!)
su jednostavno statički alocirali promenljive za procedure. U doba
sporijih mašina postojale su i varijante drugih jezika (Paskala, čak!
čini mi se da je i Turbo Paskal to radio) koji su po defaultu tako
prenosili parametre (kroz "lokalne" statičke promenljive) a tek po
uključenju posebnog sviča ili ključne reči u definiciji podržavali
rekurziju.
> Što se tiče tvrdnje da stack frame nije nikakav standard, mislim da
> grešiš. Počevši od i80186 postoje i mašinske instrukcije koje ga
> formiraju (ENTER/LEAVE). Ne bi ih trpali u mikrokod da nisu videli
> da svi to rade na isti način. Svi kompajleri koji su mi došli pod
> ruku (tu spada i nekoliko Fortrana) standardno koriste za prenos
> parametara stek, a na ulazu u funkciju formiraju frejm na isti
> način:
Vidi, odavno se ispostavilo da je to toliko korisno da je sasvim
normalno da se koristi. Međutim da se koristi UVEK ISTO to nikad nije
bilo. To što dva jezika koriste stek frejm ne znači da će i raditi
zajedno.
ENTER i LEAVE su poslednji trzaji CISC filozofije: pravi nove naredbe
umesto da si potrošio to malo vremena i napravio ceo procesor malo brže ;)
Te dve citirane "iste instrukcije" su iste prosto jer je to najbrži
skup istrukcija za taj posao. :) Stek frejmovi i pored toga ne znači
da su isti. Već i sama promena nadležnosti njegovog uništavanja utiče
na to da nisu isti i da se ne mogu povezivati.
> > To čak ima uzroke i u definiciji ponašanja jezika: u SVAKOM C-u
> > funkcija nije nadležna za uklanjanje dostavljenih parametara, a u
> > svakom Paskalu jeste. To je suštinska razlika, a proističe iz
> > činjenice da se Paskal i C sorsovi prevode pod različitim
> > pretpostavkama.
>
> Veruj mi - zaista znam o čemu govoriš, ali kao što rekoh jedina
> razlika je u displejsmentu u odnosu na BP i u tome ko skida
> parametre. A sve zajdeno postoje dve varijante. Ja bar ne videh
> druge, a i te dve varijante su STANDARDNE i nazivaju se Pascal i C
> calling convention.
Naprotiv. Evo ti malo kontraprimera:
1. prevedi f-ju C-om, u small modelu
2. prevedi drugu f-ju C-om, u large modelu, koja poziva prvu
3. linkovanje prolazi bez greške. Da li rade?
4. Napravi varijacije u K&R stilu C-a (nemoj da dozvoliš da ti
definiciju jedne f-je vidi druga). Da li rade.
Odgovor je ne, jer svaki model generiše različite stek frejmove po
definiciji (različite veličine elemenata stek frejma). Linker ti se
po pravilu ne buni.
Ono zbog čega ti frejmovi liče je samo zato što su SVI
proizvošači C kompajlera sebe usklađivali sa MS. Ništa više. Ono što
ti zoveš standardnom _pascal konvencijom je samo način na koji je MS
koristio prenos parametara od početka Windowsa (jeste, sva ekranska
okruženja su izvorno bila zamišljena za Paskal a ne za C, Mekintoš
je dobrim delom i razvijan uz pomoć ObjektPaskala).
I da ne davim dalje... Za više ćeš morati negde da me nađeš i podmitiš
pivom da pričam šire :)
asembler.127pedjak,
-> #124, janko> pretpostavkama. (Ne čačkaj me na ovu temu, to je oblast kojom se
> bavim profesionalno).
Slobodno se raspiši, i mene zanima.
asembler.128dpredovic,
-> #125, obren> Da podržava gnežđenje, apsolutno se slažem (nisam nikad ni tvrdio
> suprotno), da postoje drugačiji načini prenosa parametara takođe, ali
> pitanje je da li ih iko koristi? ;) Ništa nije Bogom dano, ali neke
Pazi, stvar je kompajlera kako će se prenos interno realizovati.
Borlandovi kompajleri (kao) imaju neku fastcall konvenciju koja
ponekad poneki parametar ne gura kroz stack. MSC je već pametniji
pa kod njega (manje-više) svaka funkcija sa 1-2 parametra ode kroz
registre. Kod Watcoma je to default tj. fastcall ne samo da važi za
tvoje nego i za sve standardne funkcije.
asembler.129nenad,
-> #111, janko> Opet da ti ponovim, sigurno je da SVE što ti umeš da izvedeš ume i
> kompajler.
Eh, da je tako ne bi postojali kompajleri koji bolje i lošije
optimizuju... Sve to što kompajler ume da izvede je smislio
čovek, nije nemoguća situacija da neko ume ponešto bolje da
izvede od Borlandovih i Microsoft-ovih programera - čak naprotiv. ;)
Jasno je naravno da je za 99% primena bolje posao optimizacije
poveriti ljudima kojima je to posao i koji to rade ceo život.
asembler.130biber,
Zna li ko sta se desava kad, dok tece DMA prenos procesor u isto
vreme pokusa da pristupi memoriji. Ko ceka DMA ili procesor? Da li se
generise neki interapt pri tome?
asembler.131obren,
-> #130, biber> Zna li ko sta se desava kad, dok tece DMA prenos procesor u isto
> vreme pokusa da pristupi memoriji. Ko ceka DMA ili procesor? Da li
> se generise neki interapt pri tome?
Zavisi da li je "burst" režim prenosa ili ne. Ako jeste, procesor mora
da sačeka da se ceo blok prenese, a ako nije DMA za svaki bajt traži
dozvolu za izlazak ba magistralu i može da izađe na istu tek kada mu
procesor dozvoli. Interapt se generiše po završetku transfera. Ako ti
treba dokumentacije od DMA imam nekih .DOC i .TXT fajlova, uglavnom
vezanih za korišćenje DMA za "sviranje" na SB-u.
asembler.132pdeze,
Pozdrav!
Nov sam u Assembleru, pa jos nisam skontao neke stvari:
procitao sam negde da na memorijski ofset, npr 1234, u data
segment mogu upisati recimo BX registar na sledeci nacin:
mov [1234], BX
ali mi TASM uporno javlja gresku: Illegal immediate,
mada ovo radi OK u Debuggeru.
Gde je greska, kako ispraviti, ili ako ovako ne moze, koji je drugi
nacin?
Thanks unapred.
asembler.133zormi,
-> #130, biber* Zna li ko sta se desava kad, dok tece DMA prenos procesor u isto
* vreme pokusa da pristupi memoriji. Ko ceka DMA ili procesor? Da li se
* generise neki interapt pri tome?
Ima više modova DMA prenosa, zavisi koji se koristi...
asembler.134deimos,
-> #132, pdeze>> mov [1234], BX
Dakle, ono sto upisujes je u bx. Za primer cemo da ga stavimo u ax.
mov dx, <segment>
mov es, dx
mov di,1234
stosw // na ES:DI upisujes word iz ax
Prvo push-ujes , a na kraju pop-ujes regisatre.
Ovo ti sigurno radi. Sto bi se reklo - po knjizi je. Moze i na
milion boljih (kracih) nacina, ali posto ucis, eto ti jedna mini-lekcija.
.dEiMoS.
asembler.135obren,
-> #132, pdeze> Nov sam u Assembleru, pa jos nisam skontao neke stvari:
> procitao sam negde da na memorijski ofset, npr 1234, u data
> segment mogu upisati recimo BX registar na sledeci nacin:
> mov [1234], BX
> ali mi TASM uporno javlja gresku: Illegal immediate,
Stavi:
MOV DS:[1234], BX
(u IDEAL modu će proći i bez DS...)
Pošto si, kako kažeš, nov u ASM-u, ostavi za početak tešku artiljeriju
i uzmi "A86" (Shareware asembler, ima ga ovde u nekom direktorijumu).
Munjevit je, automatski pravi .COM fajlove, što znači da ne moraš uopšte
da pozivaš linker, a ne moraš ni da deklarišeš segmente i ostale
šablonske delove programa. Ima detaljno uputstvo i vrlo je zgodan za
eksperimentisanje...
asembler.136cozymc,
Nista posebno, tek toliko da se i ja pridruzim, najboljem delu sezamNET,
tj ASM, CODINGS, and ZERO LEVEL STUFF. Full frame or lame!
scroll.exeasembler.137biber,
-> #132, pdeze>> Nov sam u Assembleru, pa jos nisam skontao neke stvari:
>> procitao sam negde da na memorijski ofset, npr 1234, u data
>> segment mogu upisati recimo BX registar na sledeci nacin:
>> mov [1234], BX
Za pocetak ( a i na dalje, sto da ne) probaj da radis sa A86
asemblerom. Kod njega bi ovo proslo bez problema. Ukoliko na
pocetku nemas deklaraciju segmenata, A86 podrazumeva da je
u pitanju ".com" program i tako ga prevodi. Brz je, kratak,
lepo te obavestava o greskama a u paketu sa njim ide sasvim
upotrebljiv debager (real mode doduse). Meni se mnogo vise
svidja nego masm ili tasm.
asembler.138biber,
-> #135, obren>> uzmi "A86" (Shareware asembler, ima ga ovde u nekom direktorijumu).
Ima li ko A386 i D386 ?
asembler.139deimos,
-> #138, biber>> Ima li ko A386 i D386 ?
Treba i meni. So, ako ga nadjes baci ga ovdi, plizzz.
.dEiMoS.
asembler.140biber,
U biosu postoje funkcije za direktno citanje sektora HD-a.
Da li i windows ima slicne fn.?
U nekom spisku kernel funkcija sam pronasao sam samo citanje
fajla. Da li windows ne podrzava pristup sektorima? Je li moguce
tako nesto isprogramirati?
asembler.141janko,
-> #140, biber
> U biosu postoje funkcije za direktno citanje sektora HD-a.
> Da li i windows ima slicne fn.?
>
> U nekom spisku kernel funkcija sam pronasao sam samo citanje
> fajla. Da li windows ne podrzava pristup sektorima? Je li moguce
> tako nesto isprogramirati?
Windows 3.1 dozvoljava zvanje čistih DOS funkcija, pa je verovatno
moguće i tako nešto, uz malo žongliranja. Međutim ukoliko je 32disk
access sve to je vrlo opasno (pa možda i tada zabranjeno). Tada se
mora komunicirati na nivou viruelnog drajvera.
Win32 interfejs, međutim, koliko znam, ne dozvoljava ovako
nešto na API nivou. Međutim, verovatno bi se to takođe moglo postiči
pisanjem koda kojume da komunicira sa virtuelnim drajverom (kada je
reč o W95, NT ni tada?)
Dokaz za ovakvu teoriju je što za Win95 postoji disk defragmenter!
Za NT, opet, koliko ja znam, ne.
asembler.142biber,
-> #141, janko>> moguce i tako nesto, uz malo zongliranja. Medutim ukoliko je 32disk
>> access sve to je vrlo opasno (pa mozda i tada zabranjeno). Tada se
Malo mi je nejasno zasto se ovo zove 32bit access?
Ako ne gresim, kad je 32bit disk acces omogucen, windows za
komunikaciju koristi sopstvene funkcije, a ne svicuje se stalno
u real mod da bi pozivao bios rutine. E sad, li su te windows
funkcije pisane u 32bitnom kodu pa se zato zove 32 bitni acess?
asembler.143deimos,
-> #142, biberRE: 32BDA
Stvar se svodi na to da se koristi INSD umesto INSW i slicnih
stvari. Kod nekih novijih bios-a ovo ne donosi poboljsanja (ili bar ne
znacajna), jer isti rade bas na takav nacin.
.dEiMoS.
asembler.144janko,
-> #142, biber
> Malo mi je nejasno zasto se ovo zove 32bit access?
>
> Ako ne gresim, kad je 32bit disk acces omogucen, windows za
> komunikaciju koristi sopstvene funkcije, a ne svicuje se stalno
> u real mod da bi pozivao bios rutine.
Tačno!
> E sad, li su te windows
> funkcije pisane u 32bitnom kodu pa se zato zove 32 bitni acess?
Vidi, nije bitno ono što kaže deimos da li će ćapiti WORD ili DWORD.
Poenta je samo u tome što pri obraćanju diska procesor ne mora da
izlazi iz svog 32-bitnog režima što je najviše time-consuming.
Glabni trik je u tome što te njegove sopstvene funkcije mogu biti
napisane kao REENTRANT, dok ove BIOS-ove NISU SIGURNO. U situaciji
kada se radi sa više taskova odjednom, pristupi disku treba da budu
što je moguće više preklopljeni itd.
asembler.145nenad,
-> #141, janko> Dokaz za ovakvu teoriju je što za Win95 postoji disk defragmenter!
> Za NT, opet, koliko ja znam, ne.
Postoji defragmenter za NT-a, zove se DisKeeper. Pri instalaciji
između ostalog zameni i fajlove NFTS.SYS i NTOSKRNL.EXE svojim
verzijama. Na taj način radi na niskom novou.
Postoji i drugi pristup, koji je primenjen kod nekoliko
defragmentera za OS/2-ov HPFS. Pošto HPFS sam obezbeđuje (ukoliko
je to moguće) da se fajl snimi na disk kontinualno oni praktično
kopiraju fajlove tamo-amo po disku po nekom redu koji misle da će
biti najzgodniji samom HPFS-u da sredi stvar. Verujem da postoje
takvi utility programi i za NTFS.
asembler.146biber,
-> #141, janko>> Dokaz za ovakvu teoriju je sto za Win95 postoji disk defragmenter!
Postoji li disk defragmenter za win 3.xx?
asembler.147zeljkoj,
-> #146, biber> Postoji li disk defragmenter za win 3.xx?
Da. Recimo onaj iz NU.
asembler.148bokir,
Da li neko moze da ostavi primer za INT 9 hendler?
Pokusavao sam da napravim pop-up TSR, ali mi INT 9 nikako ne
radi.
Cak ni ako stavim samo praznu funkciju (samo IRET), tastatura se
ponasa cudno: svaki pritisak na taster bar tri puta ponavlja
znak.
Pomozite, hitno mi je...
... Only dead Windows is good Windows
asembler.149biber,
-> #148, bokir>>Da li neko moze da ostavi primer za INT 9 hendler?
>>Pokusavao sam da napravim pop-up TSR, ali mi INT 9 nikako ne radi.
; Demonstracija INT 09 07.07.96
; Pritiskom na F12 na ekran ce biti ispisano slovo "B"
; Pisano za rad sa A86 asemblerom
jmp beg
make_code equ 058 ; make code tastera F12
; MAKE CODE je kod koji se dobija prilikom
; pritiskanja, za razliku od BREAK CODE
; koji signalizira otpustanje tastera
old_int09: dw 0,0 ; ovde se cuva sadrzaj starog int 09
new_int09: push ax
push bx
push ds
in al,060
cmp al,make_code
je jeste_trazeni_kod
nazad: pop ds
pop bx
pop ax
cs:
jmp d[old_int09]
jeste_trazeni_kod:
in al,061
mov ah,al
or al,080
out 061,al
mov al,ah
out 061,al
mov al,020
out 020,al
mov ax,0b800 ;
mov ds,ax ; stavi na ekran
mov bx,09e ; slovo "B"
mov [bx],08242 ; (u gornji desni ugao)
pop ds
pop bx
pop ax
iret
beg: mov ax,03500+09 ; Get Interrupt Vector
int 021
mov [old_int09],bx
mov [old_int09+2],es
mov ax,02500+09 ; Set Interrupt Vector
mov dx,new_int09
int 021
mov dx,beg ; Terminate & Stay Resident
int 027
asembler.150bokir,
-> #149, biberHvala na pomoci, biber! Ovo sjajno radi!
Imam jos par pitanja:
1. Za sta je port 20h?
2. Kako da se program instalira u HMA ili UMB?
asembler.151dzakic,
-> #150, bokir> 1. Za sta je port 20h?
Port 20h je port interapt kontrolera. Po sećanju, preko njega se
programira frekvencija interapta 8 (ako nije baš 20h, tu je blizu :),
a ono za šta se najčešće koristi jeste da se upisivanjem vrednosti
20h na port 20h vrši signalizacija interapt kontroleru da je završena
obrada interapta i da je PIC (programable interrupt controler)
slobodan da generiše sledeći interapt po prioritetu.
Na primeru, pišeš interapt rutinu za obradu int 8. Za vreme
izvršavanja tvog handlera, pritisnut je taster na tastaturi. Za obradu
interapta tastature je zadužen int 9. On je niži po prioritetu od
osmice i pritisak na taster neće prekinuti izvršavanja tvog int
handlera. Ako tvoj handler ne bi izvršio jedno out 20h,20h, int
tastature nikada ne bi bio izvršen. Zato se ovaj out stavlja na kraj
tvoje procedure i tog trenutka PIC generiše int 9.
Treba takođe voditi računa da će, ukoliko se prvo poziva originalni int
8 (iz biosa), out 20h, 20h već biti izvršen. Zato, ako ima potrebe,
neke stvari treba uraditi pre a neke posle poziva originalne int
rutine.
Detaljnije o ovome možeš da nađeš u HELPPC-u (ima ga u nekom info
direktorijumu), pored drugih jako korisnih informacija o hardveru.
> 2. Kako da se program instalira u HMA ili UMB?
Ovo je malo teže odgovoriti ovako online, ukratko: postoji int kojim
se proverava prisustvo XMS managera (2Fh ako se ne varam). Ako ga
nađe, on vrati pointer na entry u XMS manager koji nudi funkcije tipa
alociranje i dealociranje UMB-a i HMA. Alociraš blok određene veličine
u gornjoj memoriji, dobiješ pointer na dodeljen blok, iskopiraš svoj
kod na to mesto i postaviš int vektore da ukazuju tamo. Da ti, opet,
preporučim da skineš ovog puta techelp koji je za razliku od helppc-a
bolji i detaljniji za ove softverske stvarčice.
asembler.152biber,
Je li neko radio sa windows disasemblerom? (ima ga u
sezamovim direktorijumima)
asembler.153zeljkoj,
-> #152, biber> Je li neko radio sa windows disasemblerom? (ima ga u
> sezamovim direktorijumima)
Kad već pomenu Windows ovde... Kako se uopšte pišu Windows programi u
asembleru? Jel' mnogo komplikovanije nego pisanje DOS programa?
Znam da sada, u vreme VB-a, Delphija, itd. nema smisla raditi u asembleru,
pitam čisto onako, 'teorijski'. :)
asembler.154janko,
-> #153, zeljkoj
> > Je li neko radio sa windows disasemblerom? (ima ga u
> > sezamovim direktorijumima)
>
> Kad već pomenu Windows ovde... Kako se uopšte pišu Windows programi
> u asembleru? Jel' mnogo komplikovanije nego pisanje DOS programa?
> Znam da sada, u vreme VB-a, Delphija, itd. nema smisla raditi u
> asembleru, pitam čisto onako, 'teorijski'. :)
Tja... Windows 16-bit programi su malo dosadniji, jer moraš da paziš
na sve one glupe segmente. 32-bitni su malo pristojniji.
Ko zna da piše windows programe na C-u, i zna dobro asembler,
automatski zna da piše i Windows programe na asembleru. I teško je
skoro jednako, što se Windowsa tiče, jer je API isti i za C i za
asembler.
asembler.155janko,
-> #154, janko
> Ko zna da piše windows programe na C-u, i zna dobro asembler,
> automatski zna da piše i Windows programe na asembleru. I teško je
> skoro jednako, što se Windowsa tiče, jer je API isti i za C i za
> asembler.
zaboravih da napišem moju omiljenu važnu tvrdnju: pomoću C-a
je najlakše pisati asemblerske programe. ;) To mogu
i dokazati -- umem da pomoću C-a napišem .COM program od par desetina
bajtova KOJI RADI NEŠTO KORISNO
, ili rezidentni program koji radi složenu obradu a velik je
par stotina bajtova itd...
asembler.156kovacevicd,
Da li neko zna kojim OUT instrukcijama mogu poslati vrednosti
SB-Pro da na izlazu DAC dobijem napon na određeni kanal levi ili
desni kao i kojim INP instrukcijama da dobijem vrednost napona
sa ADC konvertora. Inače hteo bih primere bez korišćenja DMA
a hteo bih da iskoristim muzičku karticu za merenja u elektronici
jer ima 2 x 16 bit ADC i DAC.
asembler.157biber,
-> #155, janko>> zaboravih da napisem moju omiljenu vaznu tvrdnju: pomocu C-a
>> je najlakse pisati asemblerske programe. ;) To mogu
>> i dokazati -- umem da pomocu C-a napisem .COM program od par desetina
void pisi_B (void)
{
asm mov ax,0xe66
asm mov bx,7
asm int 16
}
Jel' mislis na nesto ovako ;>
asembler.158biber,
-> #156, kovacevicd>> Da li neko zna kojim OUT instrukcijama mogu poslati vrednosti
>> SB-Pro da na izlazu DAC dobijem napon na odredeni kanal levi ili
Evo ti uz poruku fajl koji opisuje kako.
>> a hteo bih da iskoristim muzicku karticu za merenja u elektronici
>> jer ima 2 x 16 bit ADC i DAC.
SB-pro ima 8-bitne pretvarace.
sb_dsp.zipasembler.159janko,
-> #157, biber
> void pisi_B (void)
> {
> asm mov ax,0xe66
> asm mov bx,7
> asm int 16
> }
>
> Jel' mislis na nesto ovako ;>
Naravno ne, gornji program kad linkuješ i dalje je velik. Trik
je potpuno suprotan -- umesto klasičnog run-time smestiš svoj
(to parčence mora na mašincu). Onda SVE ostalo pišeš na C-u
(suprotno od ovog gore) s tim što ne smeš da koristiš bibliotečke
funckije koje zavise od rt.
asembler.160biber,
-> #159, janko>> Naravno ne, gornji program kad linkujes i dalje je velik. Trik
>> je potpuno suprotan -- umesto klasicnog run-time smestis svoj
>> (to parcence mora na masincu). Onda SVE ostalo pises na C-u
Naravno da ne :) U pitanju je bila sala.
Pa mozes li da nam demonstriras to ovde?
Da okacis taj rt? Svakako to ima veza sa temom. A i
C dodatak koji se nadovezuje posle na rt nece skoditi.
BTW sta bese sa tvojim Concurrent C++ (moze i na mail
ako je prica suvise duga za "asembler")
asembler.161kovacevicd,
-> #158, biber> SB-pro ima 8-bitne pretvarace.
Da li si siguran, ja mislim da on ima 16 bitne pretvarače i to
stereo. Inače u fajlu se navode funkcije samo za SB običan a on je
8-bitni. Inače probao sam date instrukcije i radilo je.
Da li imaš neke informacije o programiranju WSS (Windows system
sound) , SB-PRO-a i SB-16.
asembler.162janko,
-> #160, biber
> Pa mozes li da nam demonstriras to ovde?
Da, rt jeste asembeler. Ali ostatak je C. Čitaš li C konf?
Ja bih o tome tamo... Kad malo razmislim, i to bi vredelo za jedan
članak u Računarima, kad već pišem. A znam da ću morati dosta da
pišem i ako počnemo u konf. biče dosta pitanja...
> Da okacis taj rt? Svakako to ima veza sa temom. A i
> C dodatak koji se nadovezuje posle na rt nece skoditi.
Može, sve. Evo ovako: ovde ide samo sors RT BEZ KOMENTARA. Tebi na
eventualna pitanja odgovaram telefonom, a cela priča će biti u
binarnom obliku samo ako pišem članak za Računare...
> BTW sta bese sa tvojim Concurrent C++ (moze i na mail
> ako je prica suvise duga za "asembler")
E to je priča za C++ konf. :)
Odgovor na ovo pitanje, onoliko koliko znam, tamo.
asembler.163zormi,
-> #161, kovacevicd*> SB-pro ima 8-bitne pretvarace.
*
* Da li si siguran, ja mislim da on ima 16 bitne pretvarače i to stereo.
SB Pro originalni model može da semluje na 22 kHz stereo ili 44 kHz mono
ali 8bitno u oba slučaja. SB Pro kompatibilci svi odreda mogu da rade
na 44/48 kHz stereo 16bitno ali uz sopstvene driver-e.
asembler.164biber,
-> #161, kovacevicd>> Da li imas neke informacije o programiranju WSS (Windows system
>> sound) , SB-PRO-a i SB-16.
Za ovo prvo nemam, za drugo sam ti vec ostavio u konf.
Trece imam ponesto al' ti to nece pomoci ako radis sa
nekim klonom. Oni (valjda) rade preko svojih drajvera.
Inace sve ovo je za DOS. Za windows nemam nista.
Ima li ko?
Mada, za tvoje potrebe (merenje elektricnih velicina)
je sasvim dovoljno 8-bitno semplovanje, koje je jako lepo
objasnjeno u fajlu koji sam vec kacio.( a bilo ih je jos
gomila kacenih na sezamu)
asembler.165kovacevicd,
Da li bi mogao da mi objasniš kako poslati na određen
kanal levi ili desni direktno vrednost kao i za semplovanje
levog ili desnog kanala mislim na SB-PRO.
Inače imam neke adrese za SB_PRO
LEFT_FM_STATUS 0x00
LEFT_FM_ADDRESS 0x00
LEFT_FM_DATA 0x01
RIGHT_FM_STATUS 0x02
RIGHT_FM_ADDRESS 0x02
RIGHT_FM_DATA 0x03
MIXER_ADDRESS 0x04
MIXER_DATA 0x05 da li bi mogao da mi objasniš ovo
oko mixera za ove dve adrese?
I ako bih sklonio kondezatore na izlazu i ulazu muzičke kartice
i ugradio otpornike za direktnu spregu da li će biti nekih problema
u radu i da li će to raditi. Inače zbog kondezatora kartica se može
koristiti samo u neizmeničnim režimima rada ništa od jednosmernog
režima postavim sada napon on se pojavi i onda smanji na 0 zbog
kondezatora i potrošača.
asembler.167kovacevicd,
-> #165, kovacevicd Bio sam pitao u vezi programiranja mixer-a na SB-PRO-u pa
sam našao uputstvo u arhivi
PCGPE=PC game programmer's encyclopedia 'PCGPE.RAR' (613632 bytes)
u konferenciji PC.PROG.5 poruka 31.470 datoteka SBPRO.TXT
asembler.168legend,
Zamolio bih nekog da mi popiše dobre knjige za učenje asm, jer hoću da
naučim, a nemam odakle :(. Ako neko zna gde ima da se nadje neki dobar faq
o asm, nek mi kaže, bio bih mu veoma zahvalan.
10x
Legend of LoC!
asembler.169mdimitrijevic,
-> #168, legend> Zamolio bih nekog da mi popise dobre knjige za ucenje asm,
> jer hocu da naucim, a nemam odakle :(. Ako neko zna gde
> ima da se nadje neki dobar faq o asm, nek mi kaze, bio bih
> mu veoma zahvalan.
Sto se knjiga tice stvarno ne znam ni jednu koja bi ti pomogla.
Bar ja nisam naucio asembler iz knjiga. Mogu da pogledam kod sebe nekoliko
FAQ-uova, pa cu poslati ako nadjem nesto pogodno za ucenje.
asembler.170pdeze,
Znam da poruka bas i ne ide u ovu temu, ali tema ms.dos je malo
odumrla :)
Znaci: zna li ko koji se sve registri salju na stack kada se pojavi
interrupt? A potreban mi je i redosled registara na stacku u tom slucaju.
Hvala unapred!
asembler.171obren,
-> #170, pdeze> Znam da poruka bas i ne ide u ovu temu, ali tema ms.dos je malo
> odumrla :)
Naprotiv, poruka pre spada u ovu temu, nego u ms.dos :)
> Znaci: zna li ko koji se sve registri salju na stack kada se pojavi
> interrupt? A potreban mi je i redosled registara na stacku u tom
> slucaju.
Stek raste ka opadajućim adresama, a SP pokazuje na zadnju zauzetu
lokaciju. Guraju se prvo flegovi pa kompletna povratna adresa CS:IP.
Pošto je kod Intela uvek niži bajt svega na nižoj adresi, lako ćeš
zapamtiti da se prvo gura CS pa IP, kako bi IP bio na nižoj adresi
(tako raste stek).
Slikovito:
│ │
├───────┤
│ ... │ <-- SP+6
├───────┤
│ Flags │ <-- SP+4
├───────┤
│ CS │ <-- SP+2
├───────┤
│ IP │ <-- SP (u trenutku ulaska u ISR)
└───────┘
Vrh steka
asembler.172biber,
-> #170, pdeze>> Znaci: zna li ko koji se sve registri salju na stack kada se pojavi
>> interrupt? A potreban mi je i redosled registara na stacku u tom slucaju.
Samo fleg registar.
I povratna adresa naravno (CS:IP)
To znaci da bi iz interapta mogao da se vratis i sa:
popf
retf
asembler.173obren,
-> #172, biber> To znaci da bi iz interapta mogao da se vratis i sa:
>
> popf
> retf
Ne bi mogao. Ovako sa POPF ne skidaš flegove nego IP, a onda RETF pogrešno
pokupi Flags:CS kao povratnu adresu i program ode u hipresvemir ;)
asembler.174biber,
-> #173, obren
>> > To znaci da bi iz interapta mogao da se vratis i sa:
>> >
>> > popf
>> > retf
>>
>> Ne bi mogao. Ovako sa POPF ne skidas flegove nego IP, a onda RETF pogresno
Tako je. Nisam razmisljao kad sam pisao. Naime, cesto sam koristo
pushf
call far ....(stvarna adresa interapta)
pa napravio analogiju sa ovim (pogresnu :)
asembler.175pdeze,
-> #171, obren>> Znam da poruka bas i ne ide u ovu temu, ali tema ms.dos je
>> malo odumrla :)
>
> Naprotiv, poruka pre spada u ovu temu, nego u ms.dos :)
Pa, da. Ovo je jedna od mojih vecih gluposti u poslednje vreme. :(
Poruka bi trebala da ide u temu ibm.pc.
Hvala na objasnjenju.
asembler.176npmiki,
Prelistavajuci neki intro sa TD286 naisao sam na :
MOV FS,CX ????
sta je ovo FS , nisam mogao da nadjem nigde u literaturi ?
asembler.177mdimitrijevic,
-> #176, npmiki> MOV FS,CX ????
> sta je ovo FS , nisam mogao da nadjem nigde u literaturi ?
FS je segmentni registar 386 i novijih racunara. Vecina novijih
INTRO-a i DEMO-a je radjena za 386 i bolje racunare. Na taj nacin se dobija
mogucnost da se koriste ekstra registri kojih ima vise kod 386 racunara. Kao
i mnoge druge pogodne naredbe (32 bitni registri, MOVSD, itd).
asembler.178npmiki,
Dali neko zna kako da uradim scrool u text modu ?
Naravno , preko registara vga karte .
Unapred zahvalan
ps. scrool u grafici sam savladao , pa me zato ne interesuje .
asembler.179mdimitrijevic,
Neko je trazio nesto o skrolovanju u text modu. Nisam stigao ranije
da posaljem. Ovo je primer koji se nalazi u ASMSNIP arhivi. Mislim da je
radjen za A86 asembler. Hteo sam da stavim komentare kod registara da bi
znali kako se ovo radi, ali nemam vremena. U text modu se mogu dobiti
split-screen efekti itd. Vecina stvari koje mozete da dobijete u grafickom
nacinu moze i u text modu (osim grafike naravno :).
panning.zipasembler.180mc.kuzma,
Da li neko ima asembler za ZX-a na PC-u?
Hitno je...
asembler.182tomil,
-> #180, mc.kuzma> Da li neko ima asembler za ZX-a na PC-u?
>> Ako ipak nađeš Z80 asembler koji radi pod dosom, mail me :)
Jel ovako nešto:
This is the shareware distribution disk for TASM - a table
driven assembler. The files on the disk include:
TASM.EXE - TASM Assembler, executable
TASM48.TAB - 8048 Instruction definition table
TASM51.TAB - 8051 Instruction definition table
TASM65.TAB - 6502 Instruction definition table
TASM85.TAB - 8085 Instruction definition table
TASM80.TAB - Z80 Instruction definition table
TASM05.TAB - 6805 Instruction definition table
TASM32.TAB - TMS320 Instruction definition table
TASM68.TAB - 6800/6801 Instruction definition table
TASM70.TAB - TMS7000 Instruction definition table
TASMDOC.ZOO - TASM Documentation
README - Brief Explanation of Disk contents
COPYRIGH.T - Copyright notice
ORDER.FRM - Order Form
BOOZ.EXE - Archive extracter
ili nešto od ovoga:
Microtec ASM180 Release 3.0D - kros asembler za HD64180
ASMZ80.exe - Microtec Z80 assembler V4.4b
XASMZ80.com - Avocet Z80 assembler V1.03M
AVSIMZ80.exe - Avocet Z80 simulator/debuger V1.01
Uzgred replicirao sam na sledeću poruku:
===============================
5.181 PCPROG.6:asembler
dzakic, 17.08.96. 14:17, 287 chr
Odgovor na 5.180, mc.kuzma, 16.08.96. 18:06
---------------------------------------------------------
> Da li neko ima asembler za ZX-a na PC-u?
> Hitno je...
S obzirom da je hitno, a da asembler za ZX ne postoji (?) u PC
varijanti, šaljem ti Devpac u verziji Vlade Kostića za Spektrum
Simulator - nadam se da ga imaš.
Ako ipak nađeš Z80 asembler koji radi pod dosom, mail me :)
----------------------------------------------- 5.181 ---
Gde se izgubi?
tabasm.zipasembler.184npmiki,
-> #179, mdimitrijevicJa sam trazio scroll u text modu .
Hvala puno !
sajonara :)
asembler.185ognjen,
Hocu da iz jednog programa (mali COM file), pozovem drugi
(veci EXE) ali na samom kraju, tj. da se posle ne vracam u COM
program. Kako to da izvedem? Int 021 f-ja 04c radi nesto slicno,
ali meni ne treba povratak u COM program, samo treba da pozove
EXE i da vise ne zauzima memoriju.
Kako to da izvedem?
asembler.186dzakic,
-> #185, ognjen> Hocu da iz jednog programa (mali COM file), pozovem drugi
> (veci EXE) ali na samom kraju, tj. da se posle ne vracam u COM
> program. Kako to da izvedem? Int 021 f-ja 04c radi nesto slicno,
> ali meni ne treba povratak u COM program, samo treba da pozove
> EXE i da vise ne zauzima memoriju.
Uh :). Sećam se da je bila jedna zanimljiva diskusija baš oko
ovoga nekada davno, daleke '89 ili '90, u konferenciji pcsoft.
Konferencija je još uvek tu, sačuvana je, pa pokušaj nekim
find-om da pronađeš tu diskusiju.
Ne sećam se, na žalost, šta je zaključeno na kraju, ali je bilo
interesantnih predloga i rešenja, kao što je regularan izlazak
iz programa i stavljanja imena sledećeg u keyboard buffer :).
asembler.187zeljkoj,
-> #186, dzakic> Uh :). Sećam se da je bila jedna zanimljiva diskusija baš oko
> ovoga nekada davno, daleke '89 ili '90, u konferenciji pcsoft.
Da, DejanR je isto to pitao 13.11.1989, :) poruka 8.6.
Cela diskusija se nalazi i u Računarima 59, od marta 1990. - rubrika
Priča se na Sezamu. :)
BTW, u BASIC-u RUN "fajl.exe" radi upravo to.
asembler.188tomislavr,
-> #185, ognjen> Hocu da iz jednog programa (mali COM file), pozovem drugi
> (veci EXE) ali na samom kraju, tj. da se posle ne vracam u COM
> program. Kako to da izvedem? Int 021 f-ja 04c radi nesto slicno,
> ali meni ne treba povratak u COM program, samo treba da pozove
> EXE i da vise ne zauzima memoriju.
Koliko znam nema regularnog načina da se ovo izvede pod DOS-om. Recimo
Borland C ima P_OVERLAY konstantu kao način spawnovanja ali ona nema
nikakvog efekta, odnosno ubačena je radi kompatibilnosti sa nekim drugim
platformama. Dakle, ostaje ti hakeraj, mada pošto kažeš da .EXE program
pozivaš iz malog .COM programa, pretpostavljam da i nije neki problem
što će ti on ostati u memoriji dok se .EXE izvršava...
asembler.189mdimitrijevic,
-> #186, dzakic> interesantnih predloga i resenja, kao sto je regularan
> izlazak iz programa i stavljanja imena sledeceg u keyboard
> buffer :).
Sta fali ovakvom resenju :) Ja sam ga koristio kada sam napisao
program koji u odredjeno vreme startuje neki drugi program. Prosto samo
bacim ime programa u keyboard buffer.
Sto se tice poruke na koju si replicirao. Treba pronaci poruke uz
koje su zakaceni fajlovi koji se zovu CHAIN*.*, nisam siguran za celo ime.
Ako ih mozda nema na Sezamu mogu ja da potrazim kod mene.
asembler.190pedjak,
-> #186, dzakic> Uh :). Sećam se da je bila jedna zanimljiva diskusija baš oko
> ovoga nekada davno, daleke '89 ili '90, u konferenciji pcsoft.
Čini mi se da je na kraju Vlada Kostić pronašao u nekoj biblioteci
za C funkciju koja upravo radi to. Na kraju su tu funkciju
disemblirali i otkrili o kom pozivu se radi zapravo
Treba proveriti u konferenciji.
asembler.191biber,
-> #188, tomislavr>> platformama. Dakle, ostaje ti hakeraj, mada pošto kažeš da .EXE program
>> pozivaš iz malog .COM programa, pretpostavljam da i nije neki problem
>> što će ti on ostati u memoriji dok se .EXE izvršava...
Svejedno je da li je COM mali ili veliki. COM program uvek
zauzima 64Kb u memoriji.
asembler.192obren,
-> #191, biber> Svejedno je da li je COM mali ili veliki. COM program uvek
> zauzima 64Kb u memoriji.
Ali možeš da shrink-uješ memoriju koju program zauzima na neophodnu
vrednost. Prost primer ti je da pozoveš COMMAND /C MI.COM gde je MI.COM
onaj programčić za prikaz zauzeća memorije. Videćeš da se COMMAND sveo
na 3-4 kilobajta pre nego što je pozvao MI, a isto može da uradi i
tvoj program.
Nego, konačno nađoh arivicu koja je svojevremeno bila okačena posle
pomenute rasprave na ovu temu na Sezamu, negde '92. godine. Dakle rešenje
postoji, ali nije nikakav poziv nedokumentovane funkcije. Pogledajte .ASM
sors koji je priložen, jako interesantno...
chain.zipasembler.193ognjen,
-> #189, mdimitrijevic)-> Sto se tice poruke na koju si replicirao. Treba pronaci
)-> poruke uz koje su zakaceni fajlovi koji se zovu CHAIN*.*,
Ok, nasao sam. Koga zanima to su poruke 8.24 (elgantno) i
8.26 (hakersko resenje) u konferenciji PCSOFT.
asembler.194bceklic,
-> #192, obren> Nego, konacno nadoh arivicu koja je svojevremeno bila okacena
> posle pomenute rasprave na ovu temu na Sezamu, negde '92.
> godine. Dakle resenje postoji, ali nije nikakav poziv
> nedokumentovane funkcije. Pogledajte .ASM sors koji je
> prilozen, jako interesantno...
Resenje je napravljeno specificno za TP. Samo resenje problema
je u principu vezano upravo za jezik u kome se radi. Ako se radi
u asm-u ono je najjednostavnije...
Za vise jezike problem se komplikuje zbog potreba vracanja
interapta koje preuzima odgovarajuca startup procedura.
U sustini potrebno je:
- vratiti sistem u prethodno stanje vracanjem preuzetih interapta
- u potpunosti osloboditi zauzetu memoriju
Najlakse se izvodi uz pomoc 21/4A pri cemu se prvo zatrazi
ukupna raspoloziva memorija (trazi se nemoguce BX=FFFFH). Ovaj broj
se moze izracunati i pretrazivanjem MCB-ova ciji je vlasnik program
ali je prvo resenje lakse. Potom se raspoloziva memorija dodeli
novom programu uz pomoc iste funkcije.
- ucitati program i predati mu kontrolu
U primeru se koristi 21/4B03 (load program). Za novi program se
moze kreirati novi PSP ili iskoristiti PSP postojeceg i ucitati
program preko postojeceg programa. Moguce je i iskoristiti i
nedokumentavanu funkciju 4B01 (load but don't execute) (koju inace
koriste debagari za ucitavanje programa).
Moguce je i naravno napraviti sopstvenu rutinu za ucitavanje
programa sto i nije resenje za pocetnike...
Na kraju se covek upita cemu sve ovo. Zar nije elegantnije
osloboditi nepotrebnu memoriju i izvrsiti program sa 4B00 a potom
samo zavrsiti sa radom?
asembler.196biber,
PROTDEMO is a demo program that is intended to show how to program
the 80386 to go to protected mode, set up virtual mode interrupt handlers,
do some console I/O using interrupts, and finally return to 80386 real
mode.
protdm.zipasembler.197biber,
P5 CODE MACRO FILE FOR USE WITH MICROSOFT MASM 5.1 OR LATER
ASSEMBLER.
These macros have been developed by Intel Corporation and have
been verified on a working P5 system.
You have Intel's permission to incorporate these macros into
your product royalty free.
p5masm.zipasembler.198bilder,
Kako da debagujem program koji koristi PMODE extender od Tran-a ?
Probao sam TD i posle odredjenih instrukcija racunar se jednostavno resetuje !
asembler.199mdimitrijevic,
-> #198, bilder> Kako da debagujem program koji koristi PMODE extender od
> Tran-a ? Probao sam TD i posle odredjenih instrukcija
> racunar se jednostavno resetuje !
Za sada nikako :( Posto PMODE (naravno) baci racunar u protected mode
a TD nije protected mode debuger. Mozda je moguce sa Soft-Ice debuger-om ali
ima prilicno los interfejs, pa je malo tezak za koriscenje. Uzgred, postoji
TDX (Turbo Debuger za DPMI) ali on radi samo sa "svojim" formatom programa.
Jedini debuger koji moze da debug-uje Protected Mode programe je
WD (Watcom Debuger), ali on radi samo sa DOS4GW extender-om. Nije
jedini ali ja samo za njega znam.
asembler.200biber,
-> #198, bilder>> Kako da debagujem program koji koristi PMODE extender od Tran-a ?
>> Probao sam TD i posle odredjenih instrukcija racunar se jednostavno
>> resetuje !
Može li SoftIce? Bio je već kačen na Sezamu.
asembler.201legend,
-> #200, biber-=-> Može li SoftIce? Bio je već kačen na Sezamu.
Koja poruka? Ako te ne mrzi, pogledaj ili nakači ponovo, leba ti...
Legend of LoC!/eXplosives
Alone till doom's day!
asembler.202biber,
-> #201, legend>>-=-> Može li SoftIce? Bio je već kačen na Sezamu.
>>
>> Koja poruka? Ako te ne mrzi, pogledaj ili nakači ponovo, leba ti...
Na sezamu imaš naredbe za pretraživanje (čiju sintaksu ni ja
neznam na pamet- uvek se poslužim HELPom) pa ćeš i ti možeš to da
uradiš isto tako dobro ili loše koliko i ja :)
Ako se fajl zagubio prilikom zamene softvera s početka ove
godine, kaži pa ću da šaljem.
asembler.203stameni,
Kod interapta 21h funkcija 35h nalazi adresu interapta datog u
AL (dakle, mov ah, 35h / mov al, <broj> / int 21h). Funkcija 25h
postavlja vektor na interapt čiji je broj dat u AL. Tako svi kažu
("Sve MS DOS funkcije", HELPPC, DOSREF, TECHHELP...), uključujući
i spisak interaptova Ralfa Browna.
Kod ovog poslednjeg piše takođe to isto, ali uz još neke
dodatne informacije, koje me malo zbunjuju. Koliko sam shvatio,
radi se o podfunkcijama funkcija 25h i 35h koje se dobijaju preko
registra AL. E, tamo je navedeno da nekoliko prvih podfunkcija
funkcije 25h koristi nešto što autor naziva "Phar Lap 386/DOS -
Extender", a funkcije 35h "Flash Teck X-32 VM". Šta je to, i kako
kod takvih računara (ako su to tipovi računara) funkcionišu ove
dve podfunkcije? Koliko se sme računati na "opštost" ovih dveju
funkcija?
asembler.204legend,
-> #202, biber-=-> Na sezamu imaš naredbe za pretraživanje (čiju sintaksu ni ja
-=-> neznam na pamet- uvek se poslužim HELPom) pa ćeš i ti možeš to da
-=-> uradiš isto tako dobro ili loše koliko i ja :)
Ajd kad ti kažeš, ali kako je ime? Softice*? Sice*? Softi*?
-=-> Ako se fajl zagubio prilikom zamene softvera s početka ove
-=-> godine, kaži pa ću da šaljem.
Ajd, da proverim pa ću da vičem...
Legend of LoC!/eXplosives
Alone till doom's day!
asembler.205mdimitrijevic,
-> #204, legend> Ajd kad ti kazes, ali kako je ime? Softice*? Sice*? Softi*?
SICE*.* ili S-ICE*.*
asembler.206mdimitrijevic,
-> #203, stameni> funkcije 25h koristi nesto sto autor naziva "Phar Lap 386/DOS -
> Extender", a funkcije 35h "Flash Teck X-32 VM". Sta je to, i kako
> kod takvih racunara (ako su to tipovi racunara) funkcionisu ove
> dve podfunkcije? Koliko se sme racunati na "opstost" ovih dveju
> funkcija?
Dva nabrojana cudna imena su nazivi Dos Ekstendera i ne bi trebalo da
te zbunjuju. Koriste se da bi pruzili mogucnost koriscenja celokupne memorije
racunara u zasticenom rezimu rada (protected mode). Znaci to nisu tipovi
racunara, a funkcije rade bas ono sto ti kazu svi helpovi i sto si i sam
naveo. Znaci, nemas frke :)
asembler.207nekromant,
Da li neko moze da mi posalje neku dokumentaciju u vezi Xmode-a,
i uopste niskom programiranju VGA kartica.
asembler.208mdimitrijevic,
-> #207, nekromant> Da li neko moze da mi posalje neku dokumentaciju u vezi Xmode-a,
> i uopste niskom programiranju VGA kartica.
Evo nesto sto sam na brzinu skupio. Sve je na engleskom. Primeri
su o programiranju VGA karti (X-MODE, Scroll ...). Primeri su u ASM-u, C-u i
PASCAL-u. Nadam se da ce ti pomoci, ako negde zapnes javi se.
vga_prog.zipasembler.209biber,
-> #204, legend>> Ajd kad ti kažeš, ali kako je ime? Softice*? Sice*? Softi*?
ICEDEBUG.RAR i S-ICE.ARJ
To su DOS i WINDOWS verzije.