Hello!

>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

Roppant egyszeru LEA = Load Effective Address ez egy nagyon gyors es
praktikus utasitas relativan tolt a regiszterbe es 2 (386) orajel ciklus
alatt. A proci lenyegesen gyorsabban meghatarozza a blabla cimet es
letarolja a dx-ben.
De mint lathattad en szorzasra is hasznalom(pl. LEA EAX, [EAX*4] ; SHL-nel
gyorsabb). Nagyon jo egy cim kiszamitasara.

pl. neked a karakterkeszleted kezdodik valahol es neked a 23 karakter es
egy karakter csoda modon 8 byte(ugye ez igy van mert 8*8 pixeles altalaban
egy kis karakterkeszlet 8byte*8bit)

;-------------
GetFontOffset:
;-------------
;***************************************
;IN : EBX := karakterkod := 23
;OUT: EAX := Karakter leiro adatok cime
;USE: EAX
;***************************************
lea eax, font
lea eax, [eax+ebx*8]
ret

Es mar meg is van a karakter fontkeszletben valo helye.

>> Az en moccerem: (ez a leheto legrovidebb kodu!)
>>  ASM
>>    push 0a000h     ; 3 byte
>>    pop es          ; 1 byte
>>  END

Ez tenyleg a legrovidebb, de a leglasubb is. Bar nem ront el egy regisztert
sem.

>Felado :  [United States]
>mas,
>
>> Megprobalok objektiv maradni.
>
>Objektivan teves informaciokat terjeszteni?

Koszi a kiigazitasokat. A szemelyes velemenyem irtam es tapasztalatom.
Lathatod a te soraidat is meg lehet magyarazni.

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

Akkor nezd meg a pascal <> c stringkezelest !!! es ez csak egy pelda.

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

Ha megfigyelted volna a coderben altalaban az orok harc dult a c, pascal es
asm programozok kozt. Erre probaltam meg reagalni. Abban igazad van egy JO
programozo nyelvfuggetlen vagyis algoritmusokat, technikakat ismer aztan
teljesen mindegy miben kell neki megvalositani a feladatot.

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

Minden C-nek van sajat gepfuggo konyvtara ha te azokbol hasznalsz akkor az
adott geptipuson gyorsabb lesz a geped mivel hasznalja a hardware-t. Ha
csak ANSI C-t hasznalasz ami majdnem mindenhol egyforma(en programoztam meg
Zx Spectrumot C-ben hidd el hogy ott azert mas az alap C). Erre ertettem a
hordozhatosag neha lassulassal jar. Software-t te sohasem fogsz
leoptimalizalni ugy mintha en felprogramozom a hardware-t. 

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

Ha nem ismered a nyelveket akkor hogyan valasz belole. Te is irtad barnmibe
barmit megirsz akkor minek valasztani ugy is teljesen mindegy mit tanulsz.
Te is mint programozo dolgozol gondolom. Tudod mindig a megbizo donti el
neki miben kell a stuff. Hiaba mondod te hogy iszonyu nagy C fun vagy es
ket het alatt osszedobod neki ami kell es O ragaszkodik a Pascal-hoz. Tehat
szerintem jo az ha megtanulod az egyszeru nyelvekben az
algoritmusokat(lassu meg minden) azutan amikor mar tied a tudas akkor
barmilyen nyelbe tudod az implementalni. Ehhez ki kell fejlodni egy
szemleletnek.

>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 ha te nem ismerted akkor a C de lattak benned azt hogy te tudsz
es csak 1-2 het es bevalsz akkor megsem lehetsz annyira 0.

>ezert vagyok reggel mindig zsembes,
>szin.

En meg nem szeretem ha teljesen feleslegesen felremagyarazzak a szovegem.
Nincs harag! :)

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

Ezt en egy szoval sem allitottam hogy van ilyen [ax+2*ax]. Azert is irtam
hogy ezt pascalba, regi assemblerekbe sajnos hexaban vagy db-vel kellett
beirni esetleg advenced programozok macro-kent, include-kent. A 286-os nem
is ismerte a LEA-t.

Na ismet szereztem egy-ket rajongot magamnak.

Udv,
		Moonlight.

Na szoval a problema a kovetekezo. Van egy ciklus ami filebol olvas ki
adatokat. 
Csakhogy eggyel tobbszor megy vegig mint kene. Ugy ertem a feof azutan
billen be miutan mar a file vege utan megegyszer vegigfutott. Miert van ez?
En sehogyan sem tudtam kitalalni.
Itt a ciklus:

adatok=fopen("data.dat","r+b");
clrscr();
do
	{
	fread(&output,sizeof(char),1,adatok);
	printf("%c",output);
	
    }
while(!feof(adatok));
fclose(adatok);


Asszem ennyi. Elore is koszonom segitsegedet.
Bye

Hi!

> >> 		Les	;praktikusabb	
> 
> Hat itt kicsit elhamarkodtam, ugyanis ez csak cimrol mukodik. Vagyis
> 
> LES DI, [Kepernyocim] igy di:=0, es:=0A000h
>  ...
> Kepernyocim 	dw 0A000h	; lehet hogy forditva kell erre mar nem emlekszem
> 		dw 0

Igen, forditva kell. Eloszor az offset, aztan a segmens. Egyebkent ezert
'szoltam be', mivel azt irtad, hogy ez praktikusabb, de aztan megse...

	Geza

Sziasztok!
> =======================================================
> Felado : Gaal Laszlo (Redmond, USA)
> E-mail :  [United States]
> 
> > 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.
Ebben igazad van, de en pentiumra irtam a fejleszto rendszert es 
minden 32 bites volt, meg a szegmensleirok is.

Egyre tobb emlek ugrik be.
Ha minden igaz akkor az volt a baj, hogy a 
push 0a000h
utasitasnal a compilerem kimatekolta a konstans erteket es ha 
belefert 16 bitbe akkor 16 bites push-t generalt.
A pop es meg mindig 32 bitet vesz fel a stackrol annak ellenere, hogy 
az es 16 bites reg. A maradekot eldobja a proci.

A megoldas az volt, hogy azt mondtam az assemblernek, hogy push 
utasitasnal mindig 32 bites legyen a parameter, ha az konstans.
Tehat nem kell prefix, mert a szegmenleiro 32 bites-> rovidebb lett a 
generalt kod es meg el sem szallt. Hurraaaa!
> 
> 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):
 ......
Aha most mar nekem is beugrott, tenyleg ezt csinalta a prefix.
> 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
Hat igen az a franya kompatibilitas. :-(((((((((
Sok cegnek szarabbak a termekei, mint lehetnenek, mert fent kell 
tartaniuk a kompatibilitast.
Sajnos ez az intel-re is igaz.
Az MMX-et is ugy elcsesztek a kompatibilitas miatt ahogy kell.
Marmint a lebegopontos regiszterek hasznalatara gondolok es a 
koltseges kapcsolgatasra a ket mod kozott.

Pisti

p.s.: Laci szeretnek kerdezni toled valamit. 
Latom az MS-nel dolgozol es most en is felszalltam az MS vonatra.
VC++ 5.0-at hasznalok es egy activeX objectet kell csinalnom 
(nem activeX controlt), hogy akar VB-bol is hivhato legyen, mind
early mind late binding-gal. Ez a dual interface, mert azt is 
tamogatnom kell. 
ATL projectet hasznalok. Sajnos nem talaltam olyan pelda progit, 
amibol ertekes infot tudnek kihalaszni.
Egy XML fat kell megvalositanom. Hasonlot a ti msxml.dll XML 
parseretek.
A gondom a dual interface megvalositasaval es azzal van hogy at kell 
tudnom venni olyan objectumokat is pld a VB-tol, amik az en 
objectumaim, de a VB hozta letre a dual interfacen keresztul.
Orulnek ha tudnal segiteni barmiben. 
Nem gond ha angolul van ha van valamid a szamomra.

Koszi

> PC-kozelbe. Ezeket a gepeket mind BASIC-ben programoztam -- a C16-ost,
> Enterprise-t, C64-et, C128-at ertheto okbol, a PC-t pedig azert, mert az
> elso tortenetesen egy 360 K-s floppyval felszerelt XT volt, winchester
> nelkul, amin eszebe se jutott volna senkinek Turbo Pascalt futtatni. (Fut.)

Tiltakozom!!! :-)
En pont egy ilyen PC-n kezdtem Pascalozni... :-)

>   Ja, meg egy mukk arrol, hogy miert nem szeretem a Pascalt. Mert nem
> letezik. Mar senki sem hasznalja. Kobold eppen most kozolt egy kis
> forraskodot:

En hasznalom... Most is van benne egy 2000+ soros kis programom allando 
hasznalatban / modositasban, igaz, a VESA-s 
kepkirakas/egerkezeles/ilyesmi az ASM benne, de a fo reszek nem. Tudom, 
jobb lenne a C, csak hat...

(De nem hiszem, hogy lenne ertelme pascal-vitaforumozni... :-) )

Ghosty

Hello,

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

A kovetkezot allitom:

Barmilyen programozasi nyelvben amely letezik :

1. felteteles elagazas (if)
2. ciklus(for, while do stb.) vagy feltetel nelkuli ugras (goto) 
3. direkt memoria eleres

szoval egy nyelv amely bar csak ezt a harom elemet tartalmazza, nos ez
ez a nyelv is kepes "barmilyen" programozasi feladat megvalositasara.
Azt termeszetesnek vettem hogy a nyelv kepes egyszeru valtozok
kezelesere.

Sejtem a kerdest: Hogyan tudod ebben a nyelvben azt megcsinalni, hogy
ctrl-shift-et nyomva harom piros mano hat hangon az Oromodat enekelve
egymasra atomcsapasokat merjen a kepernyon?

A valasz: Meg lehet ezt csinani az adott hardveren? Letezik
billentyuzetfigyelo megszakitas? Van hangtamogatas? Van grafikus
tamogatas? Van ezeknek cimezheto memoriakepuk? Ha nincs az nem a
nyelv hibaja, dobd ki a hardvert. Ha igen  fogj neki cimzegetni es 
rogvest megvan.

igy,

szin.

ps.

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

Lehet hogy itt nem ugyanarrol a dologrol beszelunk? Szamomra az hogy 
nem lehet azt jelenti hogy lehetetlen hogy az eredmeny ugyanaz legyen
mind a ket esetben.  Ugy latom szamodra a lehetetlen azt jelenti, 
hogy ugyanannyi ido alatt ugyanazon erdemeny.

Hi !

> Koztudott, hogy a lemezen levo sector-okat record-oknak is szoktak hivni
> (Boot Record), innen szarmazik az en subject-em is.

IMHO  a szektor # (!= , <>) Record-dal ! A Boot record sem egyenlo a
boot sectorral.

A Boot sector ugye az 1 sav elso szektora, es ez egyetlen mas szektorra
sem teljesulo feltetel (Az MBR-rol most nem beszelek). A Boot record az
ennek a tartalma, illetve Boot record lehet masutt is, mivel ez egy
logikai strukturat jelolo fogalom.

Ez valahol az a fajta ertelem keveredes mint a "Veletlen (!!!) eleresu
memoria" A hatam borsozik amikor ilyet mondanak. Miert nem tudjak
megnezni a masodik szotari alakot, hogy Kozvetlen Eleresu Memoria ami
ugye a tenyleges eszkozt is sokkal jobban specifikalja. (A "veletlen"
eleresu memoriak nalam a kukaban vegzik ! :-) )

Hogy erdemibb valaszt is adjak a fustolgesen kivul  ajanlom figyelmedbe 

Petho Adam: A ROMBIOS es ami mogotte van

cimu konyvet. Jo regi konyv, viszont sok jo hardverkozeli leiras van
benne. (meg persze nehany hiba is)
Ismet csak IMHO a dolgot nem fogod meguszni controller programozas
nelkul.
Mivel en ezt mar probaltam (marmint a kontroller programozast), csak sok
sikert tudok hozza kivanni, mert nem lesz egy leanyalom.

Udv : Csiszar L.

Hi everybody,


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

A Pascalosok nem csorok, a C-sek pedig foleg nem! ASM-ben mindent meg lehet
irni, kerdes, hogy mennyi ideje van ra az embernek... Manapsag ugysem
erdekel senkit, hogy a kod mekkora lesz, vagy hogy epp 32 vagy 64 mega RAMon
fut-e :((

Annyit azert illik hozzatenni, hogy azert az ASM tudasa vagy nem tudasa
nemcsak az alacsonyszintu rendszermuveletek megirasabol all, hanem sajnos a
mai elvadult vilagban sokszor van szukseg arra Pascalban es C-ben is, hogy a
programozo tudja, mikent fog kinezni a leforditott program... Szamomra
nagyon idegennek tunt eloszor a C-ben, hogy nem tudhattam kapasbol, hogy egy
adott fordito az altalam hasznalt valtozonak mennyi helyet allokal (hat
igen, az ASM es a Pascal karos hatasa :)

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

 ... es az objektum-orientalt nyelvek egyik diszpeldanya a Windows 95/98...
:>
A UNIXban soha nem fordulnak elo olyan "kivetelek", melyeken az ember mar
meg sem utkozik a Windowsos programok futtatasakor... Lam-lam a UNIXot
bezzeg jo oreg C-ben irkaltak ossze :) Azon azonban kar vitatkozni, hogy
melyik kornyezet hasznalhato jobban, melyik a felhasznalobaratabb, szebb es
dizajnosabb.


Ajanlom figyelmetekbe a home page-emen talalhato aprocska OOP-s
erdekesseget, nem volt kepem bevagni ide az egeszet, reszletekben viszont
nem olyan elvezetes :)
(Mellesleg az oop.html lap keszitese kozben haromszor is elszallt a
Netscape-em... No persze nem X-es Netscape volt :>

OOP Suxx: http://ond.jupiter.vein.hu/~fiery/oop.html


Udv,
Fiery - author of sysinfo tool ASMDEMO


Ui.: Egyebirant pedig mindenki olyan nyelven programozik, ahogy jolesik, es
ugyis meg fogja tanulni az ASM-et, amint a Pascal vagy C lehetosegeinek
hataraba utkozik.....

Gyerekek! Ne kezdjunk hitvitakat!!!

On 16 Jun 98 at 4:58, Velencei Tibor > wrote:

> Szoval: hogy mit hasznalsz szerintem normalis esetben elsosorban a feladattol
> fugg!, utana attol hogy mit ismersz/szeretsz/szoktal meg.

Ezzel tokeletesen egyetertek! Hasznalja mindenki azt, amiben a 
legotthonosabban erzi magat, mert abban lesz a legproduktivabb.

Legyen ez akar Pascal, akar C, akar ASM, akar ... akarmi.

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

On 16 Jun 98 at 14:17,  > wrote:

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

Lehet, hogy erre gondolt :)

Attol gyorsabb neha az akku, mert kulon utasitas van arra, hogy

  mov  ax,[fixcim]
  mov  [fixcim],ax

  xchg ax,reg

  add  ax,konstans
  xor  ax,konstans
  test ax,konstans
  ... (tobbi aritmetikai/logikai muvelet)

amik igy 1 byte-tal rovidebbek, mintha ax helyett mondjuk dx lenne.
(Persze ax helyett eax is lehet, sot, a legtobb esetben al is.)

A lea viszont nincs ezen utasitasok kozott!

Maguk az utasitasok egyebkent orajelben nem gyorsabbak! Csak attol
lesznek ezek gyorsabbak, mert eggyel kevesebb byte-bol allnak, ettol
a prefetch gyorsabb lehet (de nem feltetlenul gyorsabb a modern
prociknal). 

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

Kedves koderek!

Volna egy surgos Win16 kerdesem, hatha van valaki a listan, aki tudna
segiteni:
Szeretnek egy olyan fuggvenyt irni C-ben, amelyik vegigsetal a stack-en, es
megmondja, hogy milyen fuggvenyhivasokon keresztul jutott hozza a vezerles.
A celom ezzel az volna, hogy ha a progim valahol kiakad, olyan infot tudjak
egy fajlba kiirni, ami segit felderiteni a hibat. A progi C-ben irodott es
DPMI16-os progi, ami fobb vonalaiban olyan, mint egy Win16 program GUI
nelkul.
Az mar megvan, hogy hogyan tudok a stack-en vegigszaguldani, es kiirni a
visszateresi cimeket. Borland C-t hasznalok, annak a debug infoit is be
tudnam olvasni, eezl meg tudom mondani, hogy egy adott szegmens adott
offset-jehez melyik forrasfajl melyik forraskodja tartozik. Csak egy dolog
hianyzik, es ez a kerdesem:
Hogyan lehet megtudni, hogy egy adott szegmensszelektort melyik
kodszegmensemhez rendelt hozza a Windows? Hogyan tudom osszerendelni a
NewExeHeader-ben felsorolt szegmenseket a futaskori tenyleges
szelektorokkal?

Elore is kosz.
Gyuri

--
Foldvari Gyorgy ,