Sziasztok!

A minap jutott eszembe egy regi problema, amit annak idejen
sikerult is megoldanom, azota viszont C helyet mar C++-t
hasznalok, es kivancsi vagyok, hogy a problema itt is letezik-e.

Windows programban a memoria foglalasokhoz a GlobalAlloc
eljarast alkalmaztam, ami mint kiderult, minden handlehez egy
kulon selectort rendelt, ami annak korlatossaga miatt
(emlekeimben 2048 386-os processzorral, 3.1-es Windows)
sok tul apro foglalassal el tudott fogyni. Megoldaskent akkor
megfejeltem az eredeti eljarast annyival, hogy kis meretu
foglalasok eseten joval nagyobbat harapott, es azt tobb foglalas
kozt szetosztotta.

A kerdesem az lene, hogy a new operator megvalositasa
az altalam hasznalt Borland C++ 5.02 eseten, illetve altalaban
okozhat-e hasonlo problemat tobb tizezer egyideju, kis meretu
foglalas eseten, illetve mas programokkal konkuralva adodhat-e
ilyen jellegu problema.

udv.
Joco

A tegnapi CODER-ben errol a cimrol kertek segitseget maganba:
>>Felado :  [Romania]
>>Temakor: SOS DELPHI ( 16 sor )

Engem is erdekelne a tema, ha tud valaki segiteni, ha lehet, ne csak maganba
kuldjeted.

Koszi,
Salamon Sandor

> Van olyan asm fordito is, aminek meg tudod mondani, ez a nasm:
> (Netwide Assembler)
> 
>   add cx,1       ; imm16
>   add cx,byte 1  ; imm8

Nem pont ehhez kapcsolodik, de tenyleg van ilyen? Hozza lehet adni 16-bites
regiszterhez 8-bites operandust??? Szerintem nem. Mar a MOV helyett is
MOVZX/MOVSX kellett, de ADDZX/ADDSX utasitasokrol meg nem hallottam.

Andras

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

>"Kulturaltabb" nyelven mire gondolsz?
>(irtam korabban hogy vannak olyanok akik el vannak kenyeztetve... ;>))))))
MODULA-3. Vagy ha valami "light"-abb kell. akkor az OBERON.
"Tokeletes" nyelv azonban nincs.

>1. Ne nezd le a C-t, mert mar tobb, mint 25 eve bizonyit
Nincs lenezes. Sot, hasznalom is. A problema ott van, hogy mar regen tul
kellett volna lepni rajta. Volt alternativa: Objectiv C.

>2. C++ -ra, vagy Delphire vagy masra gondolsz, mint minden idok legjobb
>nyelvere? Tenyleg kinavcsi vagyok ra, es nem kotozkodeskeppen.
A Delphi nem rossz, bar, ha jobban megnezzuk, tkp. OBJECT PASCAL.
Szvsz a C++ legnagyobb elonye a C kompatibilitias. Egyben ez a legnagyobb
hatranya is (jo, lehet hogy kicsit sarkos a fogalmazas.)

>> Kulturaltabb nyelevekben meg ott van a strukturalt exception handling
>Lattad mar, hogy milyen ASM kod van mogotte? Valoszinuleg a programozo
>szamara kenyelmes megoldas, es biztosan attekinthetobb a forras...
Viszont a hibakezeleseket egy helyen el lehet intezni, nem kell minden hivas
utan a return code-ot elemezgetni, kiugrani, stb...
A mai gepeken az alkalmazasok 99%-anal ez nem okozhat gondot.

Marosi Pista irta (mertem volna fogadni, hogy ismered):
>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 :)
Egeszen pontosan: 
Dijkstra, E.W.: Go to statement considered harmful
CACM Vol11, N3, March 1968

>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 :)
Dijkstra egyszer izekre szedte harom amerikai cikke't valamely
folyoiratban, majd befejezesul kozolte, hogy az angolsaguk is pocsek.
A harom amerikai pontonkent megvalaszolta a kritikat, majd ugy fejeztek
be, hogy D. ur (aki azt hiszem holland) bizonyara a pocsek angolsaguk
miatt nem ertette meg a cikket ....

Na mind1, nem flame-t akartam, mindenki olyan nyelvet hasznal, amit
rakenyszeritenek.
--Udv: szm

On  7 Dec 99 at 5:57,  wrote:

> Csak egy megjegyzes: Ha jol emlexem, akkor a 80286-os nem volt teljesen
> komptabilis a 8086-ossal. Ha minden igaz, akkor a stack-re pakolgatasnal a
> masolas es a SP valtoztatasa mas sorrendben tortent...

Ez azert durva lett volna, nem ott volt a kulonbseg. Volt valami
hasonlo tenyleg, ha jol remlik, akkor egy exception-nel (talan div0)
volt kulonbseg, hogy a push-olt IP az utasitasra, vagy az utasitas 
moge mutat-e.

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

On  7 Dec 99 at 6:26,  wrote:

> > Nekem pedig csak egy apro pontositasom lenne: igenis (felulrol)
> > kompatibilis a 80386+ procik vedett modja a 80286-osokeval.
> 
> Azert vannak kulonbsegek. A 286-os nem tudott kilepni vedett modbol,
> ahhoz egy kulso aramkor reset-elte a procit. A 386-os mar tudja, de

Ez nem jelenti azt, hogy nem felulrol kompatibilis.

> ha ezt egy (286-os) program onmaga akarja vezerelni, abbol lehet
> gubanc.

Ebbol gubanc torvenyszeruen meg nem lesz. A reset-elos modszer 
mukodik ugyanis 386-osnal is.

Gond ott lehet, hogy volt a 286-osnak egy nem dokumentalt utasitasa,
loadall volt a neve, ami arra szolgalt, hogy az intel maga
tesztelhesse a procit ugy, hogy egy bedrotozott memoriacimrol betolt
a _belso_ regiszterekbe valami adatot. Igy el lehetett erni olyan
regisztereket is, amiket normal utasitasokkal kozvetlenul nem
lehetett. Lehetett pl. sima _real_ modban is betolteni egy
szegmensregiszter belso implementaciojaba olyan cimet, ami 1 mega
fole mutatott! (Ez hasonlit a 386-os nehany eve divatos "unreal"
vagy "flatreal" modjara) Igy real->protected modvaltas nelkul is el 
lehetett erni mind a 16 megat.

Nos, ez a loadall utasitas a 386-osnal eltunt (mar nem emlekszem 
pontosan, talan lett helyette hasonlo mas, de ez mindegy). Ha egy 
progi hasznalta ezt a loadall-t, abbol mar lehetett gubanc, bar ugy 
emlekszem, jobb bios-okban leszimulaltak.

Egyebkent erdekes az, hogy a real->prot illetve prot->real valtas 
tortenete hogyan alakult. A 286-osbol tenyleg 'kifelejtette' az intel 
a real-be visszavalto utasitast. Igazibol nem felejtesrol volt szo, 
hanem a proci tervezoi ugy kepzeltek, hogy minden oprendszeriro 
(ertsd: ms) orulni fog neki, hogy a procinak van protected modja, es 
real modban csak addig fut a gep, amig bekapcsolodik, es a bios 
leteszteli a gep legfontosabb elemeit. Rogton utana az opsys atvalt 
prot-ba, es hurra.

Nem igy tortent, a dos, illetve a real modu driverek meg ma is elnek. 
Ugyhogy az intel korrigalta a 'hibat', es a 386 mar megprobalt minel 
jobban egyutt elni a dos-szal (ide-oda mod valtas, V86 modban 
parhuzamosan futtathato virtualis gepek (tobb dos box)).

István