Bocs, hogy beleszólok, csak magánvélemény....

Miért kell cikizni a nagy ASM-eseknek a csóró Pascal-osokat, meg C-seket?
Ezek a nyelvek mára fejlett objektumorientált nyelvekké feljlödtek, majd
mindent meg lehet velük csinálni, s ami fontos, ezerszer gyorsabban, mint
asemblerben. Proálj meg ASM-ben Win95-ös adatabáziskezelö programot, egy ki
ügyviteli beütéssel legyártani ASM-ben! Biztos, hogy megy?

Igaz!!! Mielött még lebaltáznak: 250K-ban görgö képernyon futó szinesben
csillogó vonalakat valóban nem lehet csinálni sem Pascalban, sem C-ben. De
azert nem kelene leirni a többi nyelvet sem.

Horty

Sziasztok!

Hardware felismeres teren meg egy dolog, amit ha jol lattam, nem 
emlitettetek: int 11h (bar nem egy nagy durranas).

###

Mas: 8085 utan kisse zuros ez a 8086 szegmens-buvoles nekem. Meg tudnatok 
mondani, hogy mi a kulonbseg az alabbi MASM "progi" 2 sora kozott?

        .data
string  db        "blabla"
        .code
        lea       dx,string
        mov       dx,offset string


Elore is koszonom,
marky a germanhonba szakadt neme[s|csek] - 

Hali!
> 
> Az en moccerem: (ez a leheto legrovidebb kodu!)
>  ASM
>    push 0a000h     ; 3 byte
>    pop es          ; 1 byte
>  END
> hatranya hogy 286-ra forditas opcio kell hozza, de hat ki az aki
> XT-re fordit ilyesmit? :)
Ezzel en szivtam 1szer egy baromi nagyot.
Egy assemblert csinaltam, amit a GNU assemblerenek a modositasaval 
ertem el. Sajnos az eredeti GNU assembler AT&T szintaxist hasznal es 
emiatt szinte teljesen at kellett irni, mert a "normalis" 
programozonak picit szokatlan az AT&T szintaxis. :-)
Az assembler protected modban futott es protected modu kodot is 
generalt. 

Neha elofordult a forditando kodokban is a fenti utasitassorozat. 
A lenyeg, hogy en logikusan azt gondoltam, hogy a protected modban a 
stack 32 bitenkent no vagy csokken. Igy nem is nagyon teszteltem az
ilyen utasitasparok altal generalt kodot.
Viszont a proci protected modban is tudja 4 byte helyett 2 byte-tal 
novelni vagy csokkenteni a stack pointert. Szerintem ez hujeseg.

Szoval egyszer csak elkezdtek jonni a generalis faliorak olyan 
egyszeru kodokban is ahol nem kellett volna neki jonnie.
Aztan egy kis gepi kodu nezegeteskor jottem ra, hogy elcsuszik a 
stack.
Sajna arra most nem emlekszem es nincs is nalam pentium konyv, hogy a
"push 0a000h"  tett le csak 2 bytetot a stackre vagy a 
"pop es" vett csak fel 2 byte-ot a strackrol, de szepen elcsuszott a 
stack es onnantol mar ki tudja, hogy mi volt a stacken.

Termeszetesen egy utasitas prefixxel meg lehetett neki mondani, 
hogy ilyen esetekben kovetkezetesen 2 vagy 4 byte-tal novelje vagy 
csokkentse a stacket.
En ugy oldottam meg a dolgot, hogy mindig 4 byte-onkent hasznalja a 
stacket, mert szerintem ez tisztabb.
Gondolom ennek akkor lehet jelentosege a jobb forditoknal, ha pld 
stack meret optimalizalast valasztok akkor az ilyen esetekben 2 csak 
byte-osan hasznalja a stacket.

Persze a kereskedelmi forgalomban is kaphato assemblereknek ezt a 
helyzetet rendesen kell lekezelniuk, mert kulonben eladhatatlanok 
lennek. Ugyhogy aggodasra semmi ok, csak azert irtam ezt a cikket, 
hogy okuljatok. :-)))))

Pisti

> C-ben filekezeles 

ASCII file-ok olvasasara a kovetkezo modszert ajanlom:

FILE      *fp;
char buf[200];

if ((fp = fopen("nev","r")) == NULL ){
	/* hiba jelzes ide */
} else {
	while(fgets(buf,sizeof(buf),fp) != NULL){
		/* 
		   dolgozd fel a buf valtozot, sscanf-val 
                   vagy mas modon
		*/
	}
	fclose(fp);
}

egyszeru es minden esetben jol mukodo megoldas ez, egyreszt 
atiranyitott inputnal se akad ki ha netan stringet akarsz 
beolvasni mint a scanf es a gets-gel ellentetben tul sem 
fog soha tulcsordulni a buf. Persze ha a sor hosszabb mint 
200 karakter akkor a maradekot levagja.

Es egy tetel:

scanf sucks,

Es a kovetkezmeny:

Akinek a programjaban scanf talalhato az nem ert a C-hez.

mas,

> Megprobalok objektiv maradni.

Objektivan teves informaciokat terjeszteni?

> Igaz az viszont hogy a forditott kod az kb 10%-al lasabb
> mint a C de ez sem mindig igaz.

Igaz, hogy nem igaz? A generalt kod sebessegenek elvileg
semmi koze a nyelvhez amelyben irodott. Hogy egy adott fordito
egy bizonyos problemat milyen modon optimalizal ez a sajat dolga.

> A hiresztelesekkel ellentetben nem tudtok olyat mondani amit 
> ne lehetne pascalban megcsinalni es C-ben igen.

Nem tudsz olyat sem mondani amit commodore basic-ben nem lehetne
megcsinalni sem pedig olyat amit csak SNOBOL-ban lehet. Ilyeneket
hogy ebben ezt meg lehet abban meg nem csak olyanok mondanak akiknek
fogalmuk sincs a programozasrol. Az egy teljesen mas kerdes hogy
egyes nyelvekben konnyebben lehet egy bizonyos dolgot megcsinalni,
pl SNOBOL-ban ha jol emlekszem szavakkal lehetett indexelni egy tombot.
Fura nyelv az biztos.

> hordozhatosagra torekszel, (ami azert a pascalnal nem a legjobb) 
> akkor a C kodod nem lesz igazan gyors

a hordozhatosagnak es gyorsasagnak semmi koze egymashoz. Ha ANSI C-ben
irod a kodot akkor hordozhato ha optimalizalt akkor gyors. Hol a
kapcsolat?

> Vegul is szerintem hulyeseg azon vitatkozni melyik a jo nyelv. Mindnek
> vannak elonyei es hatranyai is. Kinek mi a fontos. Na meg ki mit ismer

A lenyeges dolog az hogy az oktatasban meg kellene adni a szabadsagot
hogy azt
nyelvet tanuld meg amelyikre ugy erzed hogy szukseged lesz. Nehogy azert
tanulj Pascalt mert a tanitto bacsi csak azt tudja. Tisztan meg kell
mutatni hogy ime ezek a lehetosegek es eddig er a takaro, tudd, hogy
mibe vagsz bele.

Velem egyszer lehuzattak ket evig a basic-et aztan nyomattak a Pascalt
hogy
vegul mikor ide jottem kideruljon hogy itt FORTRAN vagy C nelkul
teljesen 
nulla vagy, azert ezt jo lett volna elore tudni.

ezert vagyok reggel mindig zsembes,

szin.

Sziasztok!

Ezt nezzetek meg. Elismeresem a tulajnak.

http://www.hszk.bme.hu/~s5098raz/codepage/

csao

Cserko

Hi!
	>Nem kell it ganyolni, kod szempontjabol a legjobb:
	>push 0a000h
	>pop es
	Miert is?

Hello!

ugy emlexem, valaki itt kerdezte, hogy file-t lehet-e bitenkent olvasni.
a coder-l listan most irta valaki, hogy a BT utasitassal, ha a celoperandus mem
oria,
akkor nem csak egy wordon belul lehet cimezni, hanem azon tul is. ugy probaltam
,
hogy 16 bites regisztert hasznaltam, es muxott. elojelesen kezeli a regisztert,
vagyis 16 bites regiszterrel max 2^15 bittel arrel levo bitet lehet vizsgalni.
32 bites reg-nel ez gondolom 2^31, ez valoszinuleg mar eleg lesz.
szoval a filebol beolvasod az adatokat egy memoriateruletre, es a BT-vel olvash
atod
agyba-fobe :)

ha nehezen ertheto, amit irtam, akkor bocs. (kicsit faradt vagyok)

Bye,
	Panther

On 14 Jun 98 at 2:13,  > wrote:

> De segitek pl. 3-al valo szorzas is egy Lea
> Lea eax, [eax+eax*2]
> Azert erdemes az eax-el csinalni mert gyorsabban vegzi a proci a szamitast
> de ez minimalis dolog.

Nem. CSAK eax-szel (pontosabban 32 bites regiszterrel) lehet ilyet
csinalni, mert 16 bites cimzeskor teljesen mas cimzesi modokat ismer
a processzor, mint 32 bitesen. Szoval olyan nincs, hogy [ax+2*ax] de
meg olyan sincs, hogy [bx+2*bx]. A 32 bites uzemmodban a cimzest
teljesen ujrairtak a 386-os mikrokodjaban, teljesen mashogy mukodik. 

István
--  Istvan Marosi  --  http://www.sch.bme.hu/~marosi  --
--  Recosoft Ltd.  --  mailto:  --