Hollosi Information eXchange /HIX/
HIX CODER 664
Copyright (C) HIX
1999-12-07
Új cikk beküldése (a cikk tartalma az író felelőssége)
Megrendelés Lemondás
1 Re: proci tortenelem (mind)  43 sor     (cikkei)
2 Re: Elektro (mind)  19 sor     (cikkei)
3 RE: MS VC++ kerdes (mind)  15 sor     (cikkei)
4 (k++) * (k++) & goto (mind)  25 sor     (cikkei)
5 Re: forditas (mind)  19 sor     (cikkei)
6 Re: Adalek a proci tortenelemhez (mind)  20 sor     (cikkei)
7 Re: Miert nem helyes a GOTO? (mind)  23 sor     (cikkei)
8 Re: forditas (mind)  18 sor     (cikkei)
9 Hatha valaki meg nem ismeri (mind)  16 sor     (cikkei)
10 Re: proci tortenelem (mind)  8 sor     (cikkei)
11 vb5 (mind)  6 sor     (cikkei)
12 RE:RE:R3-ABAP, SPOOL (mind)  36 sor     (cikkei)
13 Re: Proci elnevezes, ahogy en kepzelem (mind)  70 sor     (cikkei)
14 Re: Miert nem helyes a GOTO? (mind)  25 sor     (cikkei)
15 foxpro - koszonet (mind)  6 sor     (cikkei)
16 Re: MS VC++ kerdes (mind)  10 sor     (cikkei)
17 Re: Miert nem helyes a GOTO? (mind)  18 sor     (cikkei)

+ - Re: proci tortenelem (mind) VÁLASZ  Feladó: (cikkei)

>> A 80286-os processzort az az igeny hozta eletre, hogy PC-ken
>> [...]
>> Ket mukodesi modja van, amint ezutan keszult 8X86-osoknak is:
>> - Real - 100%-ban kompatibilis a 8086-tal.
>> - Protected - A tobbfelhasznalos es tobbfeladatos alkalmazasokhoz
>
>Ehhez csak egy apro kiegeszitesem lenne: a 80386 es kesobbi procik
>protected modja nem kompatibilis a 80286-eval.
Nekem pedig csak egy apro pontositasom lenne: igenis (felulrol) kompatibilis
a 80386+ procik vedett modja a 80286-osokeval.
Azt hiszem szep is lenne, ha a 386-os nem lenne felulrol kompatibilis a
286-ossal, hiszen igazabol az egesz PC sikersztori erre a tenyezore (ti. a
kompatibilitasra) vezetheto vissza...

Idezet az eredeti Intel doksibol:

"13.1  80286 Code Executes as a Subset of the 80386

In general, programs designed for execution in protected mode on an 80286
execute without modification on the 80386, because the features of the 80286
are a subset of those of the 80386.

All the descriptors used by the 80286 are supported by the 80386 as long as
the Intel-reserved word (last word) of the 80286 descriptor is zero.

The descriptors for data segments, executable segments, local descriptor
tables, and task gates are common to both the 80286 and the 80386. Other
80286 descriptors--TSS segment, call gate, interrupt gate, and trap
gate--are supported by the 80386. The 80386 also has new versions of
descriptors for TSS segment, call gate, interrupt gate, and trap gate that
support the 32-bit nature of the 80386. Both sets of descriptors can be
used simultaneously in the same system.

For those descriptors that are common to both the 80286 and the 80386, the
presence of zeros in the final word causes the 80386 to interpret these
descriptors exactly as 80286 does..."

Magyaran mondva, ha a 286-os szoftverek megirasakor betartottuk, hogy a
fenntartottnak jelolt (bit)mezoket a mindig 0 ertekkel toltottuk fel, akkor
a 286-os program barmilyen modositas nelkul (!), kozvetlenul futtathato a
80386-os processzorokon is...

Gabor
+ - Re: Elektro (mind) VÁLASZ  Feladó: (cikkei)

> Elektrotechnikailag le tudna irni vki, hogy mi is jatszodik le a
>szamitogepben,(proci, memoria,chipek,stb?) pl egy utasitas
>futtatasakor? Hogyan tarolja a RAM az adatot(kondenzator,
>tranzisztor, ilyesmi)?
> Jo reszletesen, ha kerhetem.
Szerintem jobban jarnal ha vennel egy-ket konyvet a temaban (bar a magyar
szakirodalom mar alapvetoen eleg gyer e temaban, arrol mar nem is beszelve,
hogy ami megjelent annak legnagyobb resze is csak (felre)forditas) vagy
szerteneznel a Halon ilyen temaju dokumentumok utan (ott viszont tomenytelen
mennyiseg talalhato belole)!
Azon kivul, hogy az ilyen sebtiben osszekapott iromanyok nem feltetlenul tul
pontosak, en ugy gondolom, hogy amit te elvarsz, az mar joval tulmutat "a
kolcsonos segitsegnyujtas a felmeru problemak megoldasaban" cimszon (amirol
szerintem alapvetoen ez a lista szolna)...
Persze en nem akarok a tobbiek neveben beszelni - ha ok szivenesen irkalnak
tovabbra is kisesszeket neked a legkulonbozobb temakrol, akkor felolem
nyugodtan tehetik...

Gabor
+ - RE: MS VC++ kerdes (mind) VÁLASZ  Feladó: (cikkei)

> En vagyok bena, vagy tenyleg nem lehet MS VC++ 4.0
> -ban az RC file szovegesen szerkeszteni?

Ugyanugy tudod szerkeszteni, mint barmilyen mas szoveges
filet, csak be kell toltened, mint szoveges file. A file
megnyitasnal az open as: auto-t at kell allitanod text-re.
Bar az is igaz, hogy ennyi erovel barmilyen mas programot
is hasznalhatsz.

Udv:
Ebux

Eberhardt Gergely
ICQ UIN: 22870683
http://www.vbuster.hu mailto:
+ - (k++) * (k++) & goto (mind) VÁLASZ  Feladó: (cikkei)

Hello Istvan!		

>A mellekhatas vegrehajtasanak ideje
>viszont fuggetlen lehet a kifejezeskiertekelestol. Hogy miert, azt ne
>kerdezd, igy van definialva (pontosabban igy nincs definialva) a
>szabvanyban, es kesz.

Miert ? ;>)
Ezt leirja K&R (section 2.12):
"When side effects (assignment to actual variables) take place is left 
to the discretion of the compiler, since the BEST ORDER STRONGLY
DEPENDS ON MACHINE ARCHITECTURE"

 .......................................................................

KEDVES szm!
>Az olyan sz@r nyelvekben, mint pl. a C, nem a goto hasznalata a ...
>Kulturaltabb nyelevekben meg ott van a strukturalt exzception handling

"Kulturaltabb" nyelven mire gondolsz?
(irtam korabban hogy vannak olyanok akik el vannak kenyeztetve... ;>))))))

Udv.

Attila Voros, Chief Engineer, ISDgames
+ - Re: forditas (mind) VÁLASZ  Feladó: (cikkei)

> MOV-nak cimezi mod es/vagy opeandus nelkul. Ez olyan lenne (sajat
> peldadnal maradva) mint amikor a fuggvenyhivasbol kihagyod az aktualis
> parametereket - es  a fordito is hibat jelez ilyenkor...

Pontosan errol van szo! Nem azt allitottam, hogy a MOV-nak van ertelme
operandusok nelkul. Itt te magad is parhuzamot vonsz a C fuggvenyekkel: a
legtobb C fuggvenynek sincs ertelme parameter nelkul. Csupan azt
fejtegettem, hogy az _en_ elkepzeleseim szerint a MOV utasitas ugyanugy
MOV marad MOV AX, BX vagy MOV AX,CX eseten is. Egyszoval az en
ertelmezesem szerint a MOV maga az utasitas, az operandusok pedig az
utasitas operandusai, es nem reszei annak.

Na mindegy, ugylatom egymagamban maradtam -- gyozzenek a ludak! :-))

Udv, Tamas

Tamas Rudnai / Sophos Plc
mailto:
http://www.sophos.com
+ - Re: Adalek a proci tortenelemhez (mind) VÁLASZ  Feladó: (cikkei)

> Gyanitom, hogy  kevesen tudjak, hogy a PX hajnalan
> a 8086-os processzorhoz (PC XT) szuletett egy
> CP/M86, a CP/M PC-s valtozata. A Linuxhoz hasonloan
> konzolt lehetett valtani, es multitaskos (max 4) volt.
> M$ mikor is lett ilyen?

Elore bocsajtom, hogy nem vagyok MS hivo, de ne felejtsetek el, hogy a DOS
1.0 egy CP/M valtozat volt PC-re, es a MS-nak is volt egy XENIX nevu
oprendszere (h a jol tudom meg az SCO-val is egyuttmukodott), ami 286-oson
kituno UNIX klon volt virtualis konzolokkal (Alt-F1 - F6 ha jol
emlekszem). Es azt se felejtsetek el, hogy a MS az IBM-el kezdte kozosen
fejleszteni az OS/2-t (egeszen 1.3-asig, ha megint jol tevedek). Csak
idokozben kapott egy gellert, es igy lett Bill a vila g leggazdagabb
embere...

Tamas

Tamas Rudnai / Sophos Plc
mailto:
http://www.sophos.com
+ - Re: Miert nem helyes a GOTO? (mind) VÁLASZ  Feladó: (cikkei)

> Olvassatok el Dijkstra: Goto statement harmful ... c. (korszakalkoto) cikket.

Hol lelheto fel?

> Az olyan sz@r nyelvekben, mint pl. a C, nem a goto hasznalata a
> legveszelyesebb.

1. Ne nezd le a C-t, mert mar tobb, mint 25 eve bizonyit
2. C++ -ra, vagy Delphire vagy masra gondolsz, mint minden idok legjobb
nyelvere? Tenyleg kinavcsi vagyok ra, es nem kotozkodeskeppen.

> Kulturaltabb nyelevekben meg ott van a strukturalt exzception handling

Lattad mar, hogy milyen ASM kod van mogotte? Valoszinuleg a programozo
szamara kenyelmes megoldas, es biztosan attekinthetobb a forras + konyebb
tovabbfejleszteni stb, de a vegeredmenyt nem talaltam kielegitonek... Bar
nyilvan rosz kompilerrel keszult programokat elemezgettem.

Udv, Tamas

Tamas Rudnai / Sophos Plc
mailto:
http://www.sophos.com
+ - Re: forditas (mind) VÁLASZ  Feladó: (cikkei)

>> asm forditodnak nem tudod megmondani, hogy te most 
>> az imm8 vagy az imm16 valtozatot akarod, pedig neha bizony
>> hasznos lenne, ha meg tudnad mondani... 
>
>Van olyan asm fordito is, aminek meg tudod mondani, ez a nasm: 
>(Netwide Assembler) 
>
>add cx,1       ; imm16 
>add cx,byte 1  ; imm8 

Tasm-nak is meg lehet magyarazni:
add cx, word ptr 1
add cx.byte ptr 1

Egyebkent en is a nasm-ot reszesitem elonyben.......
--
JimBoo >
Suse 6.0 v2.2.7
+ - Hatha valaki meg nem ismeri (mind) VÁLASZ  Feladó: (cikkei)

Hello!

Megegy adalek, - ezuttal vicc - a processzor elnevezeshez.

Bizonyara tobben emlekeztek ra, hogy a pentiumok
elso sorozata hibas volt. Ha jol emlekszem, a lebegopontos
aritmetika szamolt bizonyos esetekben rosszul.
Akkor szuletett az alabbi vicc, ha esetleg akad meg aki
nem ismerne:

Miert neveztek el a pentiumot pentiumnak, es nem 586-nak?
Mert az Intel hozzaadott a 486-hoz 100-at, de az lett az eredmeny,
hogy 485,999999999...

Udvozlettel
Andras
+ - Re: proci tortenelem (mind) VÁLASZ  Feladó: (cikkei)

> Nekem pedig csak egy apro pontositasom lenne: igenis (felulrol)
> kompatibilis a 80386+ procik vedett modja a 80286-osokeval.

Igazad van, bennem csak annyi maradt meg, hogy egyszer valahol elterest
olvastam kozottuk. Azt nem tudom, hogy emiatt van-e, de van olyan program,
ami meg 286 pmode extenderrel keszult, es win alol nem megy.

Miki
+ - vb5 (mind) VÁLASZ  Feladó: (cikkei)

tudja valaki ?
hogyan lehet visualbasicben dos alatt futo exe-t inditani, parmeterezni

maganba valaszolj. Kosz.  Czibula Mihaly
> --------------------------------------------------------------

+ - RE:RE:R3-ABAP, SPOOL (mind) VÁLASZ  Feladó: (cikkei)

On 4 Dec 99, at 3:38,  wrote:
Hali
Koszonom Joe-nak a kezdo lokest.

> SELECT-OPTIONS PARTNER FOR BUT000-PARTNER.
> 
> INITIALIZATION.
>    LOOP AT SCREEN.
>      IF (    SCREEN-NAME(7)   = 'PARTNER'
>          OR  SCREEN-NAME+2(7) = 'PARTNER')
>         AND SCREEN-INPUT = '1'.
>         SCREEN-INPUT = '0'.
>         MODIFY SCREEN.
>      ENDIF.

vegul is ez lett az en verziom

SELECT-OPTIONS PARTNER FOR BUT000-PARTNER ... MODIF  
                                                                               
ID 'MO1'.
AT SELECTION-SCREEN OUTPUT.
LOOP AT SCREEN.
    IF SCREEN-GROUP1 = 'MO1'.
              SCREEN-INPUT = '0'.
              MODIFY SCRREN.
    ENDIF.
    /*...*/
ENDLOOP.

a MODIF ID0-fel el lehet kerulni az IF es dolgokat.
+1 koszi...
                                                         bye...
> ----------------------------------------------------------
E-Mail: 
PMail32 v3.12a
Web: www.tar.hu/mephysto
+ - Re: Proci elnevezes, ahogy en kepzelem (mind) VÁLASZ  Feladó: (cikkei)

On  5 Dec 99 at 16:09,  wrote:

> Koszonet a proci elnevezesekre adott attekintessel.A kerdesem arra
> vonatkozott, hogy miert pont az lett az elnevezes, ami lett? 

Ja, az teljesen torvenyszeruen adodott ugy, ahogy adodott, nem volt 
semmi 86 eves anyos...

Kicsit korabban kell kezdeni, 1971-ben. Akkor jelent meg a vilag elso
mikroprocija (750kHz orajel!), ami 4 bites volt. Pontosabban kivul minden
(adat, kod, cim) 4 bites volt, belul viszont adat=4bit, kod=8bit,
cim=12bit. (Ez a furcsa kettosseg ugy adodott, hogy olcsobb volt plusz
tranzisztorokat berakni 4->8->12 valamint 12->8->4 bit multiplexelesre,
mint hogy a procinak meg a tobbi chipnek nehannyal tobb _laba_ legyen!!!)
Ennek az intel procinak 4004 volt a neve, ami elegge ertheto: Szep
szimmetrikus, es kifejezi, hogy a proci 4 bites.

Egy evvel kesobb nagyot lepett elore az intel: ha jol szamolom,
megengedtek a fonokok, hogy 2 labbal tobb legyen a tokozason, igy meg
lehetett csinalni, hogy 8 bites legyen a kulso busz, tehat nem
kellett annyira bonyolult RAM/ROM modulokat hasznalni a multiplexeles
miatt. Ez lett az elso 8 bites proci, a 8008-as. Ez az elnevezes is
logikus kovetkezmenye a korabbinak.

Masfel evvel kesobb mar eszrevehetoen beindult az uzlet, ugyhogy az
eddigi 18 labu tok helyett kapasbol 40 labut engedelyeztek, igy a
tovabbfejlesztett procinak mar kulon cim es adat busza is volt, ez
tovabb egyszerusitette a kulso elemeket, nem kellett semmit sem
multiplexelni. A stack-et kiraktak a RAM-ba (eddig belul volt,
korlatozott melysegben), igy a szubrutinok sokkal egyszerubben
hasznalhatok. Gyorsabb tranyokat is tettek bele, 2 MHz orajel. Az
utasitaskeszlet is szuperebb lett, bar felulrol kompatibilis maradt a
8008-cal. Tovabbra is 8 bites maradt a proci belseje, de a
modositasok megertek a nevben egy nagysagrendnyi valtast, igy lett
8080 a neve. 

Ez utan kisebb kitero kovetkezett (a proci neve 3000 volt, nem is
illik bele a sorba) majd egy kisebb modositas csak 5 egyseget ert
meg a nevben, igy jott ki a 8085-os proci.

Ezek utan valoszinu valami rovidzarlat lehetett a PR-osok fejeben,
amikor a 16 bites proci nevenek a 8086-ot javasoltak. Valoszinu a
8080-as sikere miatt nem akartak nagyon elszakadni a jol bevalt
elnevezestol, es csupan az utolso helyierteken egy 6-ost
engedelyeztek, hogy a 16 bitet jelkepezze. A proci olcsobbik
fajtajanal (8 bites kulso adatbusz) az elnevezesnel mar nem volt
nagy mozgaster, egyetlen lehetosegkent maradt a 8088. Kicsit
ellentmondasos, hogy nagyobb a szama, mint a nagybatyjae, de vegulis 
szimpatikus szam...

A tovabbiak mar automatikusan adodtak. Nem volt celszeru elszakadni a
86-os szamtol, hisz jol be lett jaratva. A fejlodest is kar lenne
lekicsinyiteni azzal, hogy 100-nal kevesebbet ugrik a proci neve,
ugyhogy jottek a 80186, 80286, stb. Mivel a kezdo 80 jelentosege mar
a regmultba veszett, a koznyelv csak 286, 386, 486-rol beszel. A
80586 vedjegy okok miatt nem lett volna eleg eros nev, ellatinosodott
tehat, es Pentium lett belole. A folytatasnal megint gondban voltak a
PR-osok, Hexium legyen, vagy mi? :) Aztan kiderult, hogy a 80686
tulsagosan 32 bitesre sikeredett, es a 16 bites DOS/Win-es progikat
eleg rosszul futtatja, nem er meg egy nagy ugrast a nev (nehez lenne
bevezetni), ugyhogy kompromisszumkent lett belole Pentium-II. Ez 
aztan megtetszett, igy most mar a Pentium-III viszi tovabb az osi 
nevet a szerver kategoriaban... stb.stb., de bocs, most latom, hogy 
eleg hosszura sikeredtem...

Szoval ez a sztori :))

István
--  Istvan Marosi  --  http://www.sch.bme.hu/~marosi  --
--  Recosoft Ltd.  --  mailto:  --
+ - Re: Miert nem helyes a GOTO? (mind) VÁLASZ  Feladó: (cikkei)

On  5 Dec 99 at 11:55,  wrote:

> Olvassatok el Dijkstra: Goto statement harmful ... c.
> (korszakalkoto) cikket.

Pontosabban Goto statement considered harmful. Ez volt a kezdete az
elso flame war-nak :) A lap kesobb el is hatarozta, hogy ezentul nem
kozol ennyire sarkitott cikket, mert nem kell neki meg egyszer egy 
ilyen felbolydulas :)

> Az olyan sz@r nyelvekben, mint pl. a C, nem a goto hasznalata a
> legveszelyesebb.

No, ebbe ne kezdjunk bele szvsz itt se ;)

Mindenesetre poenbol egy torteneti adalek: a Dijsktra cikke utani 
vitaban felmerult az otlete annak, hogy aki nem akar goto-t 
hasznalni, azok szamara hasznos lenne egy comefrom nevu utasitas 
egyes atlathatatlanul strukturalt programokban valo eligazodashoz :)

Forras: Jargon

István
--  Istvan Marosi  --  http://www.sch.bme.hu/~marosi  --
--  Recosoft Ltd.  --  mailto:  --
+ - foxpro - koszonet (mind) VÁLASZ  Feladó: (cikkei)

Koszonom mindenkinek, aki segitett a Foxpro-s problemamban a szakdoli
keszitesenel! Ugy nez ki, lassan osszejon a dolog. (kaptam 1 het haladekot
is) Szoval mindenkinek koszi, de spec thanks Horvath Zsoltnak, aki meg
nagyon sokat segitett.
Hali:
Fozo Attila
+ - Re: MS VC++ kerdes (mind) VÁLASZ  Feladó: (cikkei)

Hello!

> En vagyok bena, vagy tenyleg nem lehet MS VC++ 4.0-ban
> az RC file szovegesen szerkeszteni?

A projektnev.rc-t nem hagyja, viszont beincludeolja (hu de szep szo :)
a res\projektnev.rc2-t (VC5). Oda is irja melle, hogy "non-Microsoft 
Visual C++ edited resources". Ezt mar lehet kezzel szerkeszteni.

Udv/Gabor
+ - Re: Miert nem helyes a GOTO? (mind) VÁLASZ  Feladó: (cikkei)

Hali mindenkinek!

> Olvassatok el Dijkstra: Goto statement harmful ... c. (korszakalkoto)
> cikket.

Errol tudnal adni egy url-t? Erdekelne csak nem lelem.

> Amugy szvsz hibakezelesle szabad hasznalni (bar en nem szoktam).
> A Microsoft szokta. Az olyan sz@r nyelvekben, mint pl. a C, nem a
> goto hasznalata a legveszelyesebb.
> Kulturaltabb nyelevekben meg ott van a strukturalt exzception handling

Szerintem egy nyelv nem attol jo vagy rossz mert van/nincs benne exception
handling. Ha jol emlekszem a C-nek az  az alapfilozofiaja, hogy "hagyd a
programozot--tudja mit csinal" :) Es kulonben is "az igazi programozo nem
fel a goto-tol" :)))

Udv/Gabor

AGYKONTROLL ALLAT AUTO AZSIA BUDAPEST CODER DOSZ FELVIDEK FILM FILOZOFIA FORUM GURU HANG HIPHOP HIRDETES HIRMONDO HIXDVD HUDOM HUNGARY JATEK KEP KONYHA KONYV KORNYESZ KUKKER KULTURA LINUX MAGELLAN MAHAL MOBIL MOKA MOZAIK NARANCS NARANCS1 NY NYELV OTTHON OTTHONKA PARA RANDI REJTVENY SCM SPORT SZABAD SZALON TANC TIPP TUDOMANY UK UTAZAS UTLEVEL VITA WEBMESTER WINDOWS