Szia Horty!

> Miért kell cikizni a nagy ASM-eseknek a csóró Pascal-osokat, meg C-seket?

Lehet, hogy en voltam figyelmetlen, de itt szerintem senki nem cikizett senkit.
Meg ami meg szurja a szemem: csoro C-sek???

> Ezek a nyelvek mára fejlett objektumorientált nyelvekké feljlödtek, majd

A C++ eseteben biztos hogy igy van, a Borland fele pascalok hagynak kivanni val
ot
maguk utan objektumoriantalt ugyben imho. (mas pascalt nem ismerek, ami nem
jelenti azt hogy nincs ;) de ez egy masik tema.

> 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?

Eleg eros a pelda. Hat persze, hogy ugyviteli(?) programot nem assemblyben
(es nem asemblerben) csinalsz. Szerintem ez itt senkinek nem is jutott az eszeb
e!
Szoval: hogy mit hasznalsz szerintem normalis esetben elsosorban a feladattol
fugg!, utana attol hogy mit ismersz/szeretsz/szoktal meg. De ha jol ertem erre
gondoltal te is :-)

> 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.

Bar nem teljesen ertem milyen peldarol van szo, de _biztos_, hogy meg lehet
csinalni pascalban es c-ben is! es az is biztos, hogy _nem_erdemes_ valami
bazinagy adatbaziskezeloben megoldani. Es senki nem fog lebaltazni ;-)

Udv:
Tibi.

Hello,

> Es egy tetel:
>
> scanf sucks,
>
> Es a kovetkezmeny:
>
> Akinek a programjaban scanf talalhato az nem ert a C-hez.

Ezt szakmai szempontbol elfogadom, de azert tulzas!
Mert lehet, hogy valami baromsagot irok a tanar bacsinak, annak meg jobban
is fog tetszeni a scanf ;-) (mert c-t tanit es abban benne van a scanf)

> 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.

En commodore64 basiccel kezdtem (tele gotokkal :-).
Az rendben van, hogy megmutatjak mik a lehetosegek es meddig er a takaro,
de en a c64-es basic tudasommal aligha birtam volna eldonteni hogy mit
akarok, es a masik, hogy ha beleugrasztottak volna a c-be, szerintem nekem
egybol fakereszt!
Szoval ahogy en (szerencsesen) jartam, (es szerintem ez egy jo oktatas volt,
azert irom le peldanak):

par honap dos, hogy tudjuk miaza pc, es utana pascal (sok kezdo, mint en is vol
tam
eloszor talalkoztam strukturalt programozassal, es erre a tipusszigoru pascal
tokeletes volt, igy utolag: imho a legjobb!).
utana jott egy ev assembly, hogy tudjuk hogy a fenebe lett a pascal forrasbol e
gy
processzoron futni kepes program ;-)
es akkor jott a C, ami a kezdetektol fogva ugy c, ahogy van :-) es akkor tudtuk
ertekelni a nyelv adta lehetosegeket, es szabadsagot, es jo sokat szoptunk is
mutatokkal, elszallasokkal. aztan jott egy kis clipper, mint adatbaziskezeles,
es feluduleskent bepillantottunk a basicbe, meg az elanba is.
ja, es mindezzel parhuzamosan volt csinos elmelet is :-)
(csak kar, hogy kimaradt a unix, vms, a nagy halozatok, es az ezeken hasznalt
fejlesztoeszkozok. De ez mar nem fert bele negy ev kozepiskolaba. meg a
parhuzamos pogramozas sem ;(

Szoval amit ki akarok hozni az egeszbol: szerintem nem nagyon kell (tulnagy)
szabadsagot adni az oktatasban. Ha a tanitobacsi csak pascalhoz ert, es
programozast tanit, haat... az ciki.

> 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.

Szerintem nem volt szerencsed ;-)

Tibi.

Most en is mondok velemenyt a dologrol.
Azzal kezdenem, hogy a kovetkezo nyelveken tudok programalni:
Basic, Pascal, Delphi, C, C++, Java, ASM ezt nem azert mondom hogy most
bolcskodjek hanem azert mert szerintem nincs olyan hogy egy nyelvel valaki
boldoguljon. Hiaba tudod az ASM mert Linux alatt nem boldogulsz vele. Hiaba
tudod csak a Pascalt mert ugyanugy nem boldogulsz vele konkretabb programoknal
mint ASM-vel. Viszont ha tudod az ASM, C, C++, Pascalt akkor mar tobb mint
valoszinu hogy barmilyen progit megirsz.

Szoval ne azon tanakodjunk, hogy melyik jobb hanem azon, hogy mikent lehet oket
jobban felhasznalni.

PS: Ha valaki olyan programot ir ASM-be amely barmely gepen elindul az szoljon
nekem is. Ezt ugy ertem hogy fuggetlen legyen az OS es a procitol. (Vagyis
olyan legyen mintha C-be irtad volna)
--
Bye
AlexK
-If at first you don't succeed -- give up!  No use being a damn fool.

>Nem tudsz olyat sem mondani amit commodore basic-ben nem lehetne
>megcsinalni sem pedig olyat amit csak SNOBOL-ban lehet.
OK,varom azt a commodore basic-ben irt programot, amivel kiirsz modjuk egy
10 karakteres szoveget a _keretre_.

>Ilyeneket
>hogy ebben ezt meg lehet abban meg nem csak olyanok mondanak akiknek
>fogalmuk sincs a programozasrol.
Mar pedig ez igy van. Vannak olyan dolgok amit (foleg a lassu valaszido es
a magasszintu nyelvek "koritese" miatt) nem lehet megcsinalni assembly
betet nelkul.
ennek ellenere nem szivesen kezelnek adatbazist c-ben vagy pascal-ban, csak
ha nagyon muszaj.

A'kos

Hi coders!
Koztudott, hogy a lemezen levo sector-okat record-oknak is szoktak hivni
(Boot Record), innen szarmazik az en subject-em is.
Van egy olyan problemam, hogy van a PC-tol egy teljesen eltero gep (nem
Commodore, de nagyon hasonlit ra). Ez a gep olyan 5.25 inch-es floppyt
hasznal, melyen a sector-ok merete 128 byte. Hogyan tudom ezeket PC-n a
BIOS rutinok beallitasaval/meghivasaval olvasni? Ki lehet valahogy hagyni
a Floppy Controller programozasat? Esetleg hogyan es hol allitsam at a
Disk Parameter Table-t (hol van a memory-aban)?
Pascal-ban volt egy formazo progi, atirtam benne a sector meretet 128
byte-osra, meg is formazta a lemezt, de utana a lemezre se irni, se
olvasni nem tudtam, mert a BIOS rutinok allandoan 512 byte-os sector-okat
akartak irni/olvasni.
Mit tegyek?

A valaszokat elore is koszonom. . .
A megoldast varja:

                                  Laci

 wrote:

Hello!

> > 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
szerintem arra gondolt, hogy az eax hasznalataval gyorsabb, mint pl ebx-szel.
nem tudom, hogy ez gyorsabb-e, de az akkumulator altalaban gyorsabb, vagy
rosszul tudom?

Bye,
	Panther

> Felado :  [Hungary]
> Temakor: Re: ES=0a000h (Re: Re: Kis tanfolyam) ( 48 sor )
> 
> 
> 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.
> 
Nem. A protected mode az protected mode a 286-on (16 bites proci)
es a [3456]86-on (32 bites proci) is, azaz
protected mode <> 32 bites kod.

A 286-tal valo kompatibilitas miatt minden kodszegmens
szegmensleirojaban benne van, hogy az 16 vagy 32 bites kod,
ennek megfeleloen az alapertelmezett regiszterek, cimszamitas
stb. is 16 vagy 32 bites default-tal mukodik.

> Termeszetesen egy utasitas prefixxel meg lehetett neki mondani, 
> hogy ilyen esetekben kovetkezetesen 2 vagy 4 byte-tal novelje vagy 
> csokkentse a stacket.
> 
Majdnem; emlekeim szerint az utasitasprefix a kovetkezo utasitasra
vonatkozo defaultot negalja, tehat (nagyon bena pszeudokodban):

egy 16 bites kodszegmensben a 

	mov	<0. regiszter>, <valami memoriacim>

a 	mov	ax, memcim	; 16 bites mozgatas utasitast irja le (mert
16 bites a default)

mig egy 32 bites szegmensben ugyanez a binaris kod a 

	mov	eax, memcim	; 32 bites mozgatas utasitast irja le (mert
16 bites a default)


Ha ele teszed a prefixet, akkor a 

	<prefix>
	mov	<0. regiszter>, <valami memoriacim>

hatasa:

16 bites szegmensben 32 bites lesz a mozgatas, 32 bitesben meg 16 bites.

Mindez (szerintem) elsosorban azert, hogy 16 bites kodban is hasznalhass
32 bites aritmetikat; illetve azert, hogy a 32 bites oprendszerek (Intel
processzoron)
tovabbra is direktben tudjak futtatni a regebbi 16 bites programokat


> En ugy oldottam meg a dolgot, hogy mindig 4 byte-onkent hasznalja a 
> stacket, mert szerintem ez tisztabb.
> 
Azt hiszem a legegyszerubb lett volna 32 bites szegmensleirokat generalnod
valahogy.

Udv

	- Laci

> Amikor adatokat olvasok ki a file-bol akkor eggyel kessob veszi a FEOF jelet.
Gondolom while(!feof(f)){getc(f)} stilusu kodrol van szo.
Ez feature, nem bug. Utolsokent meg egy EOF (-1) karaktert tudsz olvasni
a file-bol, csak aztan ut be a feof();

Szia,
rob - László, Róbert -  - http://www.sch.bme.hu/~rob