Udv Mindenkinek!

Akos  irta:
>>hogy pontosak legyunk, az cim felso bitje az elojel...
>>tehat, az ugras a kovetkezo utasitas elejetol szamitott
>>-128 es +127 tartomanyban barhova lehet 80386-ig...
>Ezert hivjak a 386-os procit 386-nak?...
>>Ez nem minden processzoron igaz, pl. az Intel 80x86-osokon _nem_! Hi
>...es a 80x86 mire vonatkozik?
>Tudna vki errol felvilagositast adni,
>mire vonatkoznak ezek az elnevezesek?

Az Intel egeszen a Pentiumokig _csak_ szamokkal jelolte a processzorait.
Azert tertek at kesobb a nevadasra, mert azt igy mar le lehetett vedeni.
Ui. egy sor gyarto dobott piacra 286/386/486/stb procikat, de Pentiumot
ezen a neven mar nem gyarthattak. Ez a szam a processzor tudasarol, vagy
felepiteserol nem hordoz informaciot!

Egy kis tortenelem: (vagy PgDn)

Az Intel elso olyan processzora, melyre mikroszamitogep epult, a
8080 nevet viselte (masneven: MCS-80). Ez egy 8 bites, 64kb 
cimtartomanyu proci volt. Ennek tovabbfejlesztett valtozata a 8085
(MCS-85), es a Zilog ceg Z80 processzora volt. Ezekre keszult az 
akkoriban nepszeru CP/M operacios rendszer.

A 8086-os (iAPX 86) processzor mar valodi 16 bites proci volt, de ujra
assembalas utan futtatni lehetett rajta a 8080 programjait is (a 8085 es
Z80 programokat mar csak sok megszoritassal).
Az IBM erre processzorra epitette elso szemelyi szamitogepet. Ez a teny
nagyban befolyasolta azt, hogy maig ezek leszarmazottait hasznaljuk.
Kijott meg egy processzor 8088 neven, a 8086 utasitaskeszletevel, amely
azonban (magasabb sorszama ellenere) nem volt teljeserteku 16 bites, 
ugyanis habar a belso szohossz 16 bit volt, a busz csak 8.
A cimezheto tartomany 1 Mb.

A 80186 es 80188 processzorok gyakorlatilag 8088 es 8086-osok,
amelyekkel nehany fontos periferiat egybeepitettek, lehetoseget
teremtve ezzel meg kisebb gepek epitesere. Ezekre a processzorokra
nem epult PC, viszont sok vezerlo elektronikaban (pl. CNC
szerszamgepek) alkalmaztak oket. Legutobb pl. egy MCA buszos 
SCSI kartyan lattam ilyet.

A 80286-os processzort az az igeny hozta eletre, hogy PC-ken
is lehessen korszeru tobbefelhasznalos (Multi-user) es
tobbfeladatos (Multi-session) operacios rendszert hasznalni.
(Elmondta vajon ezt valaki a M$-nak is?)
Ket mukodesi modja van, amint ezutan keszult 8X86-osoknak is:
- Real - 100%-ban kompatibilis a 8086-tal.
- Protected - A tobbfelhasznalos es tobbfeladatos alkalmazasokhoz
szukseg van arra, hogy a programok ne ferhessenek hozza a masik
altal hasznalt memoriahoz.
Virtualis cimtartomany 1 GB, 16 MB cimtartomanyu fizikai tarra
lekepezve. (Protected modban)

A 8X86 processzorcsalad elso valodi 32 bites tagja a 80386.
Keszult sx jelzesu valtozata is 16 bites kulso busszal.
Virtualis cimtartomany 64 TB, 4 GB cimtartomanyu fizikai tarra
lekepezve.(Protected modban)

Huhhhhh.....
Az ujabbakrol mar kevesebbet tudok. Esetleg folytathatna
valaki a hevenyeszett tortenelmi attekintest.

KASI

Hello CODERS!

>> A GOTO a regebbi nyelvekben jatszott jelentosebb szerepet, e nelkul nem
>> lehetett programozni.
>> Mara viszont a programozas rakos sejtjeve valt ....

Mar megint elkezdjuk ezt a vitat? 
Nem lehetne megegyezni abba hogy nem tudunk megegyezni?

Az alabbival lehet hogy sokat megsertek.
IMHO aki lenezi a goto-t azok el vannak kenyeztetve a mai
PC (WINDOZE) kornyezetbe es el se tudnak kepzelni programozast
egy "real time" systembe ahol a peldaul egy 128Kb EPROMba van
a progi, nincs merevlemez, nincs CD, es csak 64Kb RAM van, 
(vagy meg kevesebb) ES reagalni kell sok mindenre azonnal 
(nincs homok-ora :-))

>Ki mire hasznalja meg a goto-t?

Pelda : 16 asynchronous serial port-ot figyelni (57.6Kb mind)
es reagalni az allandoan jovo adatokra. Higgyetek el hogy
egy ket jo helyezett goto sokat szamit.

2 pelda: Ez a fuggveny egy megszaitasbol van hivva ami 
minden 0.122 millisecondba tortenik
void ReadRTC(void)
{
	BYTE blSec, blMin, blHour, blDate, blDay, blMon, blYear, blCentury;
	Flags.LastDateReadError = FALSE;
	bRTCAddressLatch = 0x0a;
	if (bRTCDataSpace & 0x80)
		goto _readrtcexit;
	bRTCAddressLatch = 0x00;
	if ((blSec = bRTCDataSpace) > 59)
		goto _readrtcexit;
	bRTCAddressLatch = 0x02;
	if ((blMin = bRTCDataSpace) > 59)
		goto _readrtcexit;
	bRTCAddressLatch = 0x04;
	if ((blHour = bRTCDataSpace) > 23)
		goto _readrtcexit;
	bRTCAddressLatch = 0x06;
	if ((blDay = bRTCDataSpace) > 7)
		goto _readrtcexit;
	if (!blDay)
		goto _readrtcexit;
	bRTCAddressLatch = 0x07;
	if ((blDate = bRTCDataSpace) > 31)
		goto _readrtcexit;
	if (!blDate)
		goto _readrtcexit;
	bRTCAddressLatch = 0x08;
	if ((blMon = bRTCDataSpace) > 12)
		goto _readrtcexit;
	if (!blMon)
		goto _readrtcexit;
	bRTCAddressLatch = 0x09;
	if ((blYear = bRTCDataSpace) > 99)
		goto _readrtcexit;
	/* tobb kod ami itt nem erdekes */
_readrtcexit:
	bRTCAddressLatch = bRTCAddressSave;
	Flags.LastDateReadError = TRUE;
}
Igen meg lehetne irni goto nelkul 3 fele keppen,
1. az utolso 2 sort beirni minden helyre ahol
a goto van es return, - itt az a baj ha peldaul
be kell szurni egy harmadik sort valamiert, akkor
11 helyen kell javitani a programmot - nem kivano
2. fuggvenyt hivni a goto-k helyett es return - ezzel
el kell viselni a fuggveny hivasnak a rezsijet - a gyorsasag
miatt ez nem kivano
3. inline fuggvenyt hivni es return - ez meg mivel az
EPROMba minden byte fontos - ez sem kivano.

3. pelda (mostani munkam) egy szerencsejatek gep programba
ha elveszitjuk az aramot, mikor visszajon az aram akkor a 
programnak PONTOSAN - MINDEN ESETBEN ott kell felvenni a jatekot 
ahol elment az aram...
(gondoljatok: peldaul szorja ki a penzt es felet kiszorvan
elmegy az aram, amikor visszajon az aram vissza kell menni
a programnak a penzszoro fuggvenybe es ugyanazt kiteve a
kepernyore ami az aramvesztes elott volt - folytatni a szorast 
anelkul hogy tobbet vagy kevesebbet szorjon ki.) 
Meg nem talatam semmi jobbat a goto-nal itt.

Bocsassatok meg hogy ilyen hosszura sikerult, de az en
velemenyem szerint (ami ugyanaz mint a K&R konyvbe van)
a goto-nak meg van a helye a programmozasba - BIZONYOS KEVES
ESETBE, es ha valaki meg nem jott keresztul ilyen eseten
akkor ne akarja kidobni.

Udv.

Attila Voros, Chief Engineer, ISDgames
"Real programmers are not afraid to use gotos - when it's called for"

Szia Biidzsii.

Szerintem nem a GOTO a hibas, hanem a rossz strukturák kialakitasa.
Sok nyelvben igen korulmenyesen lehet a ciklusokbol hiba eseten kilepni.
Sokszor lenyegesen egyszerubb es erthetobb ha nem veszel el a sok if ...
elseif es egyebb egymasba agyazott if-ek kozott, hanem szekvencialisan
irod hogy 

   if  feltetel then kiugrok mert hiba van  
   if  feltetel then kiugrok mert hiba van  
   if  feltetel then kiugrok mert hiba van  
   if  feltetel then kiugrok mert hiba van  
   a fentiek utan pedig megcsinalom amit kell

nem kell kulon valtozot bevezetni, hogy van-e hiba vagy sincs, nem kell
ezt mindig vizsgalnod. Volt regebben egy kiadvany Dajkstra vagy Knuth
irta es pascal algoritmusokat targyalt. Ebben irja az egyik rendezesi
modszernel (nem a legeldugottabb, soha nem hasznalt modszer), hogy
igazan atlathatoan GOTO-val lehet megoldani. Meg is adja az algoritmust.
Tehat azoknal a nyelveknel ahol tenylegesen jol van megoldva a kivetel
es hibakezeles ott nincs ra szukseg, de azt mondani, hogy a GOTO a hibas
a sok rossz, attekinthetetlen programban ez tulzas. Egyebkent JAVA-ban
is lehet olyan szornyusegeket irni, hogy az csak na. Tehat nem a GOTO-t
kell kerulni hanem at kell gondolni, hogy mit is kell csinalni es azt
hogyan kell.

Hali.
   
* -------------------------------------------*
  mailto:

>>Hogyan lehet chm kiterjesztesu file-t eloallitani egy HTML oldalbol ?

>CHM kiterjesztesu file-t a HTML Help Workshop nevu M$-os csodaval
>tudsz kesziteni.

http://msdn.microsoft.com/workshop/Author/htmlhelp
1.21-es verzio, kb. 4MB. Azt irjak, IE5 ajanlott hozza, mi az 1.1-es verziot
hasznalgatjuk, IE4-gyel.

> Es ha meg azt is el tudna valaki mondani, hogy egy HTML-t miert kell
> _compilalni_?

nehany (vitathato) erv es M$ "non-argument"
1. elvben gyorsabbnak _kellene_ lennie, mint a sima html+browser
kombinacionak
2. indexeles, kereses, stb. kepesseg. Ez persze sima html-lel is
megoldhato, de talan bonyolultabban.
3. karbantartasi, setup, stb. szempontbol jobb _egy_ chm-file,
mint egy hajorakomany html
4. [M$] ha jol tudom, a chm-formatum nem publikus.
5. [M$] csak M$ platformon futtathato

Ad 4.: nem ismer valaki egy chm-decompiler-t? Vagyis chm->html.
hlp->rtf konvertorom van.

Balazs Gyuri, Praga

Hello mindenkinek!

	Egy nagyon rovid kerdesem volna:
	Hogyan mukodik a cimben megadott kifejezes !
	A furcsa az, hogy kulombozo nyelvekben kulombozo eredmenyt ad vissza.

	Peldaul (k++)*(k++) 12-ot ad vissza, ha k 3 volt. A vegso k ertek 
        pedig 5 lesz.
	Mi van akkor, ha csak k*(k++) irok ? Vagy forditva (k++)*k ?
	De az elobbiek is 12-ot adnak vissza, a k pedig termeszetesen 4 lesz.
	Ha elhagyjuk a zarojeleket, az eredmenmyek valtozatalanok maradnak.
	Mindez igy mukodik Borland C++ 3.1-ben.Viszont Visual C++ 5.0-ban mar
        kulombozik.
	Sajnos az ottani eredmenyekre mar nem emlekszem.

	Szoval szerintetek hogy van ez ?

joco

> Ez erdekes... "Letrehozni nem, hasznalni annal inkabb."  Biztos, hogy en
> vagyok a hulye, de szerintem ez paradoxon... Kifejtened ezt egy kicsit
> bovebben is?

Termeszetesen: a mai processzorok tobbsege -- beleertve a
mikroprocesszorokat is -- nem softcode-osak, azaz nem lehet uj
utasitasokat letrehozni bennuk. Ilyen modon letrehozni nem tudok
utasitast. Hasznalni a meglevoket termeszetesen igen. Igy ertettem.

> Valoban tevedtem - igenis letezik egy operandus nelkuli muvelet: a "nop"...

Ha nagyon szorszalhasogatoak szeretnenk lenni, akkor a nop nem parameter
nelkuli, mivel az egy xchg ax, ax muvelet -- a processzor valojaban
dolgozik, de megsem produkal lathato eredmenyt -- de ez mar valoban
szorszal hasogatas...

> vele... A fent felsorolt utasitasok pedig "rejtett" operandusokkal
> dolgoznak: az elso kettonek egy-egy flag, mig a harmadiknak az IP (es
> esetleg a CS) a rejtett operandusa...

Rendben, ha igy gondolod, akkor nincs operandus nelkuli utasitas (a lock
operandusa a rendszer busz, a hlt operandusa az utasitas vegrahajto egyseg
stb...). Akkor viszont vannak huzalozott operandusokkal rendelkezo utasitasok
(mint pl. aaa; aad; ret stb... [a stb nem utasitas :-) ]) es vannak ... hat
nevezzuk dinamikus operandusokkal rendelkezok, mint pl. ret 2; imul ax, bx, 2;
mov ax, cx; stb...

> Ertsd mar meg: a "mov" nem utasitas (legalabbis nem a gep szamara) - az
> legfeljebb csak egy mnemonik...!

Nyilvan, epp emiatt kell "gepi kodra" forditani, azaz a mov utasitast (es a
tobbit) binaris alakba foglalni. Pl:

1011 0000 mov al, imm
1011 0001 mov cl, imm
1011 0010 mov dl, imm
1011 0011 mov bl, imm
1011 0100 mov ah, imm
1011 0101 mov ch, imm
1011 0110 mov dh, imm
1011 0111 mov bh, imm
1011 1000 mov ax, imm
1011 1001 mov cx, imm
1011 1010 mov dx, imm
1011 1011 mov bx, imm
1011 1100 mov sp, imm
1011 1101 mov bp, imm
1011 1110 mov si, imm
1011 1111 mov di, imm

 ...de...

10000010 szinten mov al, imm... Csak ebben az esetben az AL huzalozottan benne
van az utasitasban.

Persze az Intel kezikonyve kicsit maskepp csoportositja a biteket, de a
lenyeg, hogy van egy utasitas, ami lene esetben 4 bites, majd egy
operandus (nevezhetjuk mezonek), ami szinten 4 bites. A nezetkulonbseg
kozottunk csak annyi, hogy te ugy gondolod, hogy az utasitas ettol 8
bitesnek tekintendo, en pedig ugy, hogy 4-nek...

>Mikor egyezo ket utasitas? Akkor, amikor ugyanazt a muvelet(sort) vegzik
>el... Csak hogy a "mov cx, ax" es a "mov ax, 0" meg csak nem is hasonlit

Mondom, nezetkulonbseg. Szerintem az utasitas akkor utasitas, amikor
ugyanazt a muveletet vegzik el, esetleg mas operandusokkal. Ugyanugy, ha
van egy C fuggvenyed, akkor nem tekintheto mas fuggvenynek, ha mas
parameterekkel hivod meg. Tulajdonkepp meg akkor is egy azon fuggveny, ha
pl. C++ -ben mas szamu ill. tipusu parameterekkel hivod meg, ami
ilyenforman kulon van deklaralva -- tehat fizikailag mas fuggvenyt hivsz
meg. Pl. a mov es, ax utasitasnak egeszen mas az _utasitas_ mezoje, mint a
mov cx, ax -nak... Megis "ugyanazt" a muveletet vegzi , viszont mas
parameterekkel es raadasul egeszen masfajtakkal, tehat jogos is, hogy mas
a kodja.

>regiszterben... Ilyen alapon egyebkent az "xor ax, ax" utasitas egyezne a
>"mov ax, 0"-val, hiszen a te felfogasod szerint mindketto pontosan ugyanazt
>csinalja, nem? (Nem neztem meg - lehet, hogy a flageket nem ugyanugy

Nem, nem ugyanazt csinalja -- egeszen mast. Az eredmeny persze ugyanaz lesz.
Lasd meg fentebb.

> Visszaterve az eredeti kerdesre: a te altalad hozott parosnal sokkal jobban
> hasonlit egymasra mondjuk a "mov ax, cx" es a "mov ax, dx", de ezek sem egy
> es ugyanaz az utasitas, hiszen nem ugyanazt, hanem csak egy nagyon hasonlo
> muvelet(sort) vegeznek el... Marpedig ugye az elobbi lenne a kriteriuma az
> "azonossag"-nak...

Ahogy mondtam, szamomra ez ugyanaz a muvelet: mozgatni adatot egy 16 bites
regiszterbol az AX-be. Az Intel az AX-et specialisan kezeli, a mov ax,....
mindig leirhato rovidebb formatumban is, mint a mov cx,... mov dx,... stb.
Ugyanis az ax sok utasitasban huzalozott, mint celoperandus. A forras operandus
nyilvan kulonbozo, es utasitastol fuggoen vagy egy masik byte-ban, vagy
ugyanabban a byte-ban, de altalaban az utolso 3 biten van elkodolva. Pl. az

90h -- 10010 000 xchg ax, ax --- avagy nop
91h -- 10010 001 xchg ax, cx
92h -- 10010 010 xchg ax, dx
93h -- 10010 011 xchg ax, bx
94h -- 10010 100 xchg ax, sp
95h -- 10010 101 xchg ax, bp
96h -- 10010 110 xchg ax, si
97h -- 10010 111 xchg ax, di

De ugyanezeket le lehetne irni tobb byte-os formaban is, a procinak edes
mindegy, a program meretenek nem...

En tortenetesen nem "oskolaban" tanultam meg programozni, de ettol
fuggetlenul nem hinnem, hogy le kellene nezni valakit azert, mert valamit
nem sajat tapasztalatbol vagy "IQ-bol" tud, hanem mert ugy tanitottak
neki...

> Es akkor arrol meg nem is beszeltunk, hogy ugye a vinyo-gyartok bevett
> szokasa az "1 megabajt = 1000 kilobajt" (es tarsai) megfeleltetesek
> alkalmazasa az amugy altalanos elfogadott 1024-es valtoszam (pl. 1kilobajt =
> 1024 bajt) helyett, ami ugye nagyobb meroszamot eredmenyez ugyanakkor
> kapacitas mellett...

Ez nem a winyogyartok bevett szokasa, hanem az 10-es szamrendszer... Itt
angliaban mindenki hasznalja -- nemcsak szamitastechnikusok -- a kilo
jelzest (pl. fizetest nem ugy jelolnek, hogy 18 ezer, vagy 18000, hanem
18k). Mas kerdes, hogy a szamitogepek eseteben a decimalis kilo nem szamit
kereknek, ezert fel kell "kerekiteni" 1024-re. Megint mas kerdes persze,
hogy hasonloan a byte = 8 bit bevett szokasokhoz a kilo a
szamitastechnikaban 1024-et jelent, a mega pedig 1024 * 1024 -et. A
winchester gyartoknak tehat kovetniuk kellene ezt a szabvanyt, mivel igy a
felhasznaloknak az a benyomasuk, hogy atvertek oket -- vettek egy 2.5
gigas diszket, de csak 2 gigat jelez a gepuk, azaz hova tunt a fel giga?

OK, legkozelebb nem fogok belekotni a byte kifejezesbe -- ez igy megnyugtato
szamodra?

Tamas

Tamas Rudnai / Sophos Plc
mailto:
http://www.sophos.com

Hi inet,"HIX CODER" >!

> Persze egyebkent tortenetesen egy jol megirt soros-port kezelonek az sem
> okoz gondot, ha ugyanazt a megszakitast tobb adapter is hasznalja... (Ti. az
> IIR segitsegevel egyertelmuen azonosithato, hogy melyikuk valtotta is ki
> valojaban az aktualist megszakitast...)
iC> Gondolom az IIR valami Interrupt-al kapcsolatos dolog, de pontosan mi?
igen.. a soros port megszakitasaval kapcsolatos...
interrupt identify register a becses neve... es arra jo,
hogy ra lehet jonni az also 3 bitjet nezegetve, hogy miert
is abajgat bennunket az a franya 8250 es csipp...

iC> Es melyik IO cimen erheto el?
a com port base addressetol szamitott +2 re van....;))
/azaz, ha 3f8 on van az uart, akkor 3fa-n lesz az iir....;))))/
arra figyejl, hogy csak olvashato, ha irod, az mar mast csinal...;)))

na tovabbi jo kodolast mindenkinek.... Mc

Hi inet,"HIX CODER" >!

> ui: amugy a megszakitasokat oda 'teszed' at, ahova csak
> akarod... azaz... a pic felsetupolasaval meg kell hatarozni
> az interrupt base vektort, ahova a pic majd az irq-kat fogja
> jelezni... ennek igazan vedett modban van jelentosege, ahol
> az int 7 nel meg javaban exceptionok vannak....
iC> Errol tudnal adni reszletes informaciot? (Ez volt nekem mindig a furcsa,
iC> hogy vedett modban hogy nem akadnak ossze az exception-ok az IRQ-kal...)
hat most mondom... en az oprendszeremben ugy csinaltam, hogy fogtam,
es az 1, picet attettem 40h-ra, a 2. picet pedig 48h ra... igy egymas
utan jottek 40..4f ig az irq-k.. es igy mar nem akadtak ossze...
/ime egy kis kod, amivel ezt meg tudod tenni:

;-----------------------------------
proc SetUpPIC
;in: cl-master begin;  ch-slave begin
mov al,11h      ;initialization sequence
call pic_out20  ;send it to 8259A-1
call pic_outA0  ;and to 8259A-2
mov al,cl       ;start of hardware ints 1
call pic_out21
mov al,ch       ;start of hardware ints 2
call pic_outA1
mov al,04h      ;8259-1 is master
call pic_out21
mov al,02h      ;8259-2 is slave
call pic_outA1
mov al,01h      ;8086 mode for both
call pic_out21
call pic_outA1
mov al,0h       ;there are no disabled interrupts
call pic_outA1
call pic_out21
mov al,20h      ;sign end of pending irq!
call pic_out20
call pic_outA0
ret
;---------------------
pic_outend:
db 0ebh,00       ;'jmp short $+2' in tasm...
ret
;---------------------
pic_out20:
mov dx,20h
out dx,al
jmp byte pic_outend
;---------------------
pic_out21:
mov dx,21h
out dx,al
jmp byte pic_outend
;---------------------
pic_outA0:
mov dx,0A0h
out dx,al
jmp byte pic_outend
;---------------------
pic_outA1:
mov dx,0A1h
out dx,al
jmp byte pic_outend
endp
;-----------------------------------

na tovabbi jo kodolast.... Mc

Hi inet,"HIX CODER" >!

>Szerintem inkabb pontosabb, ha a gepi kodot byte-ok
>sorozatnak tekintjuk. Mivel minden utasitas hossza
>egesz byte. Az utasitasok persze bitmezokbol epulnek fel.
iC> Ez nem minden processzoron igaz, pl. az Intel 80x86-osokon _nem_!

iC> Az i80x86-on vannak valoban 1 byte-os utasitasok, de vannak rovidebbek,
iC> ahol - legtobbszor 3 biten -- az operandust is belekodoljak
iC> a byte-ba, mint legkisebb cimezheto tarolo egyseg. De vannak 2 sot
iC> 3 byte-os utasitasok is, pontosabban ott is mar 1 vagy 2
iC> operandus bele van kodolva a byte-okba, tehat maga az utasitas rovidebb.
iC> Azutan mi van a prefixumokkal? Tudnek 4 KByte-os utasitast is
iC> csinalni, amit valoban a proci vegre is hajt, es igaz maga az utasitas
iC> hossza nem valtozik, de ha a prefixumokat is az utasitas reszekent
iC> kezeljuk, akkor 4 KByte-osnak is mondhatjuk azt az 'egy' utasitast...
na igen... ez a felteves /4k hosszu utasitas;)/ valoban megvalosithato...
de csak 8086, 80186 es 80286 processzorokon, mivel 386 es ujabbakon
a leghosszabb elfogadhato utasitas meretet limitaltak 15 bytera...
ha annal hosszabb, akkor ex#13-al (GenProtFault) jelzi a processzor...

idezet kovetkezik az "INTEL 80386 PROGRAMMER'S REFERENCE MANUAL 1986" -bol,
annak is a "14.7  Differences From 8086" fejezetebol:
> --------------------------------------------------------------------------
  6.  Redundant prefixes.
      The 80386 sets a limit of 15 bytes on instruction length. The only
      way to violate this limit is by putting redundant prefixes before an
      instruction. Exception 13 occurs if the limit on instruction length
      is violated. The 8086/8088 has no instruction length limit.
> --------------------------------------------------------------------------

aki meg mindig nem hiszi, jarjon a vegere...
-----------------------------[test.asm]-----------------------------
db 13 dup (2eh)   ;par "cs:" prefix...
   mov ah,0eh     ;igy ez 15 byte lett...;)))
mov al,'a'
int 10h

db 14 dup (2eh)   ;par "cs:" prefix...
   mov ah,0eh     ;igy ez 16 byte lett...;)))
mov al,'a'
int 10h

ret               ;<-- folosleges, ide mar ugyse jut el...
-----------------------------[test.asm]-----------------------------

na tovabbi jo kodolast.... Mc

On Tue, 30 Nov 1999 12:13:11 EST,   wrote:

>iC> es ha nagyobb a ciklusmag 127 byte-nal ugyanis a JNZ utasitas csak
>iC> annal kisebb tavolsagra hasznalhato (az utolso bit az elore/hatra
>iC> iranyt  hatarozza meg) Valamint tudni kell hogy a JNZ (es mas
>iC> felteteles ugrasok) 2 byte-osak a JMP pedig legalabb 3 viszont
>iC> univerzalis
>hogy pontosak legyunk, az cim felso bitje az elojel...
>tehat, az ugras a kovetkezo utasitas elejetol szamitott
>-128 es +127 tartomanyban barhova lehet 80386-ig...
Igen, igy a pontosabb :-)
>mivel onnantol van a conditional jump nak egy near
>valtozata, amivel mar barhova lehet ugralni...
Ezt én nem tudtam...

>[..]
>iC> Remelem nem bonyolitottam tul a dologot.
>iC> Viszont segithet, ha megnezel egy gepi-kod tablazatot: egy kozonseges
>iC> ADD, vagy JMP assembly utasitasnak is tobb tucatnyi gepi kodja van...
>iC> Azt azert tudni kell, jogy az assembly 1:1-ben megfeleltetheto a gepi
>iC> kodnak.
>azert ennek ellentmondanek...;))))

Teljesen igazad van, csak en az egy utasítason a ADD CX, 1-sort
ertettem (szerintem így, egy osszetartozo egesz), s nem onmagaban a
ADD-ot. Es ebbol csak egyfele gepi kod keletkezhet, vagyis egyazon
assembly forrasprogrambol csak egyfele gepikod allhat elo (mar ha
kikapcsolja az ember a fordito NOP bepakolaszasat)...

ZsZs.

Hali

A fent emlitett nyelven lenne szuksegem segitsegre.
SELECT-OPTIONS -nal, hogy lehet megoldani, hogy a szelekcios 
kepernyon egy mezot ne lehessen modositani, de jelenjen meg. 
Erteke a programbol DEFAULT-tal be van allitva.

elore is koszi...
                                                         bye...
> ----------------------------------------------------------
E-Mail: 
PMail32 v3.12a
Web: www.tar.hu/mephysto

> Es ha meg azt is el tudna valaki mondani, hogy egy HTML-t miert kell
> _compilalni_?

Gondolom azert, hogy mas browser ne tudja beolvasni...

Andras

>>>Szerintem inkabb pontosabb, ha a gepi kodot byte-ok
>>>sorozatnak tekintjuk. Mivel minden utasitas hossza
>>>egesz byte. Az utasitasok persze bitmezokbol epulnek fel.
>>Ez nem minden processzoron igaz, pl. az Intel 80x86-osokon _nem_!
>> stb....
>Ez erdekes, legyszives irj mar le egy darab olyan 80x86-os utasitast ami nem
>egesz szamu byte-bol all. Egyebeknt pedig gondolom tudod egy utasitasba azert
>sok minden bele lehet kodolva de attol az meg egy utasitas marad.
>Masreszt az Intel doksikban a prefixeket az utasitassal egybe kezelik.
>Eppen ezert irjak azt a General Protection-nél, hogy kiválthatja az
>utasitashossz 15 byte-nyi korlatjanak atlepese. ( Es itt bele ertik a
>prefixet az utasitashosszba.) Ugyhogy
>15 byte-nal hosszabb utasitast szerintem nem tudsz futtatni, vagy ha igen
>azt is mutas egyet. Kuldhetnel egy 4KB utasitast is, kivancsi vagyok,
>hogy megy a gepemen.
Most nem azert, hogy igazat adjak Rudnai kolleganak (sot! szereny velemenyem
szerint eleg nagy badarsag az eszmefuttatas amit itt az utasitas-hosszakrol
eloadott), de azert ebben a dologban _reszben_ igaza van:
Idezet az eredeti Intel 80386-osrol szolo konyvbol:

"  6.  Redundant prefixes.

      The 80386 sets a limit of 15 bytes on instruction length. The only
      way to violate this limit is by putting redundant prefixes before an
      instruction. Exception 13 occurs if the limit on instruction length
      is violated. The 8086/8088 has no instruction length limit."

Ez ugye azt jelenti, hogy bar a 386-os 13-as kivetelt general 16 vagy annal
tobb bajtbol allo, redundans prefixeket tartalmazo utasitasok eseten,
azonban a 8086-os proci siman benyeli!
Persze ennek ellenere szerintem a dolog semmikeppen sem tamasztja ala a
mondandovalojanak helytallosagat, es foleg nem erv akkor, amikor mar 386-os
procikat is csak muzeumokban lehet fellelni. (486-os es Pentium+ procikrol
sajnos nincs doksim, de feltelezem, hogy azok is hasonloan limitaljak a max.
utasitas-meretet...)

Gabor

>Van valaki aki már találkozott ezzel a
>hibaüzenettel, hogy CAB error?
>Mi okozhatja?
Ha Windows-zal kapcsolatban jon elo, akkor feltetelezem, hogy azert kajabal
a program, mert megserult valamelyik telepito-lemezen egy (vagy tobb)
fajl... (Ti. a W9X-ek meg pl. az IE4+-ok is ilyen .CAB kiterjesztesu
tomoritett allomanyokkal dolgoznak...)

Gabor

>>Es te tudsz operandus nelkuli utasitasokat "letrehozni"? Meg ha tudnal is -
>
>Letrehozni nem, hasznalni mar annal is inkabb. Gondolom tudsz ASM-ben
Ez erdekes... "Letrehozni nem, hasznalni annal inkabb."  Biztos, hogy en
vagyok a hulye, de szerintem ez paradoxon... Kifejtened ezt egy kicsit
bovebben is?

>programozni, szerintem neked is eszedbe fog jutni egy par ilyen....
>
Valoban tevedtem - igenis letezik egy operandus nelkuli muvelet: a "nop"...
De ez az egyetlen - es slussz-passz! (Szoval "par ilyen" biztos nem fog
eszembe jutni...) Remelem nem arra gondoltal, hogy az "stc", a "cli" vagy
mondjuk a "jmp" operandus nelkuli muveletek... Akkor ugyanis nagyon
tevedsz - az operandus nem attol operandus, hogy a bevezeto mnemonik utan
szokozzel elvalasztva all, hanem attol, hogy muveletet vegzunk rajta vagy
vele... A fent felsorolt utasitasok pedig "rejtett" operandusokkal
dolgoznak: az elso kettonek egy-egy flag, mig a harmadiknak az IP (es
esetleg a CS) a rejtett operandusa...
Egyebkent is - ha egy utasitasnak nincs operandusa az azt jelenti, hogy nem
vegez muveletet semmilyen adaton/adattal, magyarul az utasitas nem csinal
semmit... Ennek pedig mi ertelme lenne  - plane ha mar egy pontosan ilyen
"funkcioju" utasitasunk mar eleve van (gyk. "nop")???

>>Magyarul az utasitas az nem az, hogy "mov", hanem az hogy pl. "mov az, 0",
>>"mov cx, ax", stb.
>
>Ha igy veszed, akkor igazad van. Csakhogy a "mov" utasitasnak rengeteg
>gepi kod felel meg, meg a mov ax, bx-nek is igy operandusokkal egyutt.
>Olvasd el az Intel
Ertsd mar meg: a "mov" nem utasitas (legalabbis nem a gep szamara) - az
legfeljebb csak egy mnemonik...!

>kezikonyvet! Ha ugy lenne, ahogy te mondod, akkor a mov cx, ax mas utasitas
>lenne, mint a mov ax, 0. Szerintem csak mas a cel es a forras operandus, de
>lehet, hogy tevedek...
Mikor egyezo ket utasitas? Akkor, amikor ugyanazt a muvelet(sort) vegzik
el... Csak hogy a "mov cx, ax" es a "mov ax, 0" meg csak nem is hasonlit
egymasra: az egyik ket regiszter kozott mozgat adatot, a masik pedig a
memoriabol (!) olvas be egy implicit erteket (!) es ezt tarolja el egy
regiszterben... Ilyen alapon egyebkent az "xor ax, ax" utasitas egyezne a
"mov ax, 0"-val, hiszen a te felfogasod szerint mindketto pontosan ugyanazt
csinalja, nem? (Nem neztem meg - lehet, hogy a flageket nem ugyanugy
modositjak, de ebbe legyszi most ne koss bele, mert nem ez a lenyeg benne..
Ha keresnek, biztosan talalnek olyan utasitaspart is, amelyek ebben a
tekintetben is egyeznek... Kosz.)
Marpedig a szoban forgo ket utasitas nem egyezik, csak legfeljebb ugyanazt
az eredmenyt szolgaltja.. Ez pedig azt hiszem ket kulonbozo dolog...
Visszaterve az eredeti kerdesre: a te altalad hozott parosnal sokkal jobban
hasonlit egymasra mondjuk a "mov ax, cx" es a "mov ax, dx", de ezek sem egy
es ugyanaz az utasitas, hiszen nem ugyanazt, hanem csak egy nagyon hasonlo
muvelet(sort) vegeznek el... Marpedig ugye az elobbi lenne a kriteriuma az
"azonossag"-nak...

>>processzorokon egesz szamu bajtnyiak (magyarul: bitekben vett meretuk 8
>>egesz szamu tobbszorose) azert IMHO egy kicsit durva...
>
>Bocsanat, nem ez volt a megkozelites, hanem ez:
>
>>>Szerintem inkabb pontosabb, ha a gepi kodot byte-ok
>>>sorozatnak tekintjuk. Mivel minden utasitas hossza
>>>egesz byte. Az utasitasok persze bitmezokbol epulnek fel.
>
>Nem ugy tortent a kijelentes, hogy "minden utasitas beleertve operandusokat
>prefixumokat byte-ok sorozatakent tarolodik".
>
>>Szerintem a "byte" az mindig is 8 bit volt es lesz is... (Erdekes, hogy
pl.
>
>Igy tanitjak az oskolaban?
En tortenetesen nem "oskolaban" tanultam meg programozni, de ettol
fuggetlenul nem hinnem, hogy le kellene nezni valakit azert, mert valamit
nem sajat tapasztalatbol vagy "IQ-bol" tud, hanem mert ugy tanitottak
neki...

>>az RFC-kben is megprobaljak kovetkezetesen az "octet" szot hasznalni, de
>>azert csak becsuszik neha egy-egy "byte" is... Azert ez elarul valamit,
>>nem?)
>
>A rossz bevett szokasok. Nezz korul egy kicsit (tanulmanyozz regebbi
gepeket is
>pl.) es rajossz, hogy a byte = 8 bit kisse pontatlan, legfeljebb altalaban
igaz
> .
>
>>Persze mondjuk nem hiszem, hogy sikerulne olyan autentikus szemelyiseget
>>talalni, aki barmelyikunkek is _hitelt erdemloen_ igazat tudna adni e
>>kerdesben. (Ez a "a byte hany bit" kerdes tipikusan olyan, mint a nyelv
>>alakulasa: valojaban _nem_ a nyelveszek, hanem az emberek alakitjak es
>>formaljak a nyelvet - a nyelveszek inkabb csak rogizitik a
valtozasokat...)
>
>Igen, epp emiatt hasznalja nehany felhasznalo a "flopitot" kifelyezest a
floppy
>targyas esete helyett, emiatt tarsitjak a "PC" betuosszetetelt az
IBM-PC -vel es
>emiatt gondoljak, hogy az "Intel processzor" kifejezes egyertelmuen behatarolja
>az Intel 80x86 processzor csaladot. Nem kerem, ha altalanossagban beszelunk
>valamirol, akkor pontosan fogalmazzunk -- pontatlanul fogalmazhatunk akkor, ha
>egy adott kornyezetben (mindenki szamara vilagos, hogy melyik) hasznalunk
>valamit. A "gepi kod" azonban nem hatarol be sem processzort sem pedig
>platformot vagy miegyebet, tehat ez esetben a "byte" nem mondja meg hany bitrol
>is van szo...
Nem vagyok nyelvesz, de szerintem a "gepi kod" (gyujto)fogalom es mint ilyen
nem is az a feladata, hogy egy konkret dolgot hataroljon be... Igy nem ertem
min megy a vita...

A "byte" kerdesben pedig mar kifejtettem a velemenyem: mivel a "byte" szo
nem ugy alakult ki, hogy leult x ember, eldontottek, hogy ez mit fog
jelenteni, es foleg nem rogzitettek ezt egy dokumentumban, ezert nincs
hivatkozasi alap ami alapjan barki kijelenthetne, hogy 1 byte = x bit...
De..... - es ez itt a lenyeg - a legtobb (>99.9%) rendszer, gep,
architektura eseteben a byte fogalma egyertelmuen a 8 bitet jelent.. Ennel
fogva azt hiszem teljesen logikusan az "1 byte = 8 bit" konvencio (!)
szerinti alkalmazasa...
Azt hiszem eleg durva lenne, ha azert mert en holnap epitenek egy gepet es
azt mondanam, hogy "az en gepemben 1 kilobajt = 4322 bajt es 3 bit", azert
masnaptol senki sem hasznal(hat)na a kilobajt kifejezest, mert hogy nem
egyertelmuen azonositja a mennyiseget...
Es akkor arrol meg nem is beszeltunk, hogy ugye a vinyo-gyartok bevett
szokasa az "1 megabajt = 1000 kilobajt" (es tarsai) megfeleltetesek
alkalmazasa az amugy altalanos elfogadott 1024-es valtoszam (pl. 1kilobajt =
1024 bajt) helyett, ami ugye nagyobb meroszamot eredmenyez ugyanakkor
kapacitas mellett...

>Irod, hogy kotozkodok -- eddig nem tettem, de ezzel az utolso bekezdessel mar
>valoban ez volt a szandekom.

Kar.

Gabor

Hello Coder-ek!

Tudna nekem valaki segiteni?
Szuksegem lenne egy kis assembly progira ami a kovetkezoket tudja:
Ket gepet osszekapcsol a parhuzamos porton es azon keresztul fileokat vagy kara
ktereket kuld at. Ezt opcionalisan lehessen menubol valasztani.

Ja es az egesz full assemblyben kell, hogy legyen.

Akinek van ilyen progija, vagy egy par ora alatt ki tudd izzadni egyet az kerem
 jelentkezzen, mert eleg surgos 
lenne!!!!

Az an--yagiakban megegyezunk!!!!
Tel.:06-20/98-49-247

Szevasztok !

  Ki tudna ellkuldeni egy leirast arrol hogy a CD-ROM-ba milyen bitek
mennek. Tehat arra volna szuksegem, hogy hogyan lehetne vezerelni a
CD-Romot. Ilyen adatokra lenne szuksegem: 
  play,skip,replay,program,stb. megvalositasahoz szukseges adatok, hogy 
megtervezzem a vezerlest es,hogy szamitogep nelkul zene cd lejatszasara
tudjam hasznalni.
  A valaszokat kuldjetek a  cimre.

Szevasztok !

 wrote:

> >>Hogyan lehet chm kiterjesztesu file-t eloallitani egy HTML oldalbol ?
> >>Feltetelezem a chm a compilled html roviditese, vagy valami ehhez
> >>hasonlot jelenthet.
>
> >Es ha meg azt is el tudna valaki mondani, hogy egy HTML-t miert kell
> >_compilalni_?
>
> Hat, ha jol tudom csak azert, hogy egy darab help fileba legyen az
> egesz,
> es ne sok kulon html-be. Egyebkent pedig nem tudom, hogy miert
> keresel ertelmet abban amit az M$ csinal?

Tokeletesen igazad van.
Az egyetlen elonye, hogy 1 azaz egy file lesz belole. Igy kivaloan alkalmas
nemcsak help file keszitesere, hanem tobb mas hasznos dologra is.
Nekem peldaul azert kell, mert a kulonbozo grafikonokbol es meresi
adatokbol es egyeb formazott szovegbol allo nyomtatasi kepet (amit errefele
ugy hivnak, hogy Quality Assurrance Certificate) kell olyan file-ba
lementenem, ami eleg szeles korben elterjedt formatum. A kedves ugyfel
elektronikus formaban megkapja a termek adatait es otthon a sajat gepen, a
sajat programjaval megnyitja es nezegeti.
Jelenleg Acrobat Pdf formatumban mentjuk az adatokat, de az ActiveX-es
kapcsolat  nap 24 orajaban folyamatosan hasznalva eleg lassunak bizonyult,
tul sok eroforrast kot le. Raadasul az ugyfelnek fel kell installalni
Acrobat Reader-t ha meg akarja nezni.

Gondoltam egy miset meger, hogy kiprobaljam a chm-et. Hatha ez gyorsabb.
Internet Explorer meg amugy is benne van a Windows-ban /pont emiatt van a
per is :-)/, igy nem kellene kulon file nezegeto programot feltenni a
gepre. Egyetlen kerdes maradt mar csak: a sebesseg.

HA VALAKINEK VAN EGYEB OTLETE A FENTI FELADAT MEGOLDASARA, AZT SZIVESEN
OLVASOM !

Amugy Gergely, koszonom szepen az infot, mar letoltottem.

Udv,
Papp Andras