Help za men - lamera...

Hi,
razgledah temite i t.k. vijdam che ima razbirachi na C, a se spomenava i Borlab C++ 3.1 reshih da se oarna kam vas. Ta s vaprosnia kompilator imam slednia problem - koda mi stana dosta goliam i kompilatora dava greshka - koda nadhvarlial 64K.
Izpolzvam proekt i Large model. Pedi vreme imah sashtia problem. Togava obache ne izpolzvah proekt i reshenieto beshe prosto - proekt. Sega pak kakvo stana - proekta li e goliam. Imali niakakvo reshenie na problema.
Probvah Hug model - veche ne izliza greshkata za nadhvarleni 64K, no pri izpalnenieto na programata OS-sa ia terminira i dava niakakav problem sas steka.
Stava vapros za proekt s uchebva cel. Vsichko e lamerska rabota znam, no mi e interesno imali niakakv nachin za reshavane na problema. Neshto kato za nachinaesht.
10x +

mozhe bi trjabwa da probvash da izpolzwash overlays (.OVL)

dokato pisheh pod DOS predi wsichko Borland Pascal 7.00 izpolzwah - i tam izpolzwaneto na overlay beshe lesno - neznam pri Borland C/C++ dali e de - mozhe bi trjabwa da razbiesh njakoi ot chastite na programa si na parcheta...

kakuw tip programa e - naprimer, ako e sus njakakuw GUI (Turbo Vision Library da kazhem) - togava sigurno shte moje da se pomogne... opishi za kakvo stava duma..

tirulirutatuutuu

При Large модел с това C нещата стоят така: кода и данните могат да надхвърлят 64 кб, но при определени условия.

Като ползуваш проект, разбиваш програмата на модули - отделни файлове. Условието е всеки файл, като се компилира, да не надхвърля 64 кб. Ако надхвърли - разцепваш модула на две и проблема изчезва.

Всички статични и константни данни се събират в DATA сегмента. Ако той надхвърли 64кб, проблема е по-сложен.

Ако имаш заделени статични масиви, по-добре ги махни и алокирай динамична памет.
Ако имаш големи масиви със статични данни, добре е да ги извадиш в отделен модул. В този случай помага и ако в декларацията на масива използуваш и "far": указва на компилатора да сложи масива в отделен DATA-сегмент (само че не винаги, трябва да се погледнат и опциите на компилатора, сега съм забравил).

Изобщо, ако възникне такъв проблем, правиш следното: изхвърляш част от данните, докато се компилира програмата, и разглеждаш MAP-файла, който ще създаде компилатора. Там се вижда кое в кой сегмент е и колко е голямо. Сегментите които са много пълни - работиш за да изхвърлиш неща от тях.

Първо ако не си разбрал това е клуб "Програмисти", а не "Програмиране" и тук за работа не говорим много-много. Просто си се заяждаме, щото всички се смятаме за велики.
Второ, ако си съумял да сътвориш сам 64K код за учебна програма по-добре отърви света от software-а си и не пиши нищо повече.

Контрольорите приличат на Батман.

Човека ти обяснява, че му се компилира, ама гърми. Според мен не е възможно да е натворил толкова код сам. По-вероятно данните му идват в повече. И то не като цяло, а има да кажем някой масив над 64K, ама май това не можеше... Аз съм на приницпа, че ако някой може да изпише 64К никой не може да му помогне :-)

Контрольорите приличат на Батман.

Аз навремето доста го бях разчепкал компилатора точно около тоя проблем. Има възможност да извадиш стека в отделен сегмент (опции на компилатора за SS != DS) и печелиш малко място. Само че тогава се появяват разни проблеми с променливите в стека, които са описани в хелпа. Всъщност в huge-режим SS != DS, и явно затова му гърми програмата - не е спазил някои от изискванията.

Спомням си за един проблем, който едва успях да го преборя: едни данни по никакъв начин не искаха да ходят в друг DATA-сегмент. Записах ги в един двоичен файл, конвертирах го като OBJ с BGIOBJ.EXE и ги линкнах като код-сегмент. И това е решение :))

От меню Options|Compiler|Entry Exit Code
се избира DOS Overlay.
След това се избират файловете от проекта, които ще бъдат overlay-и. Принципа, на който се разделят би трябвало да е да са сравнително независими части от проекта...

oops! znachi ima (taka de nema kak da ne moje)

prosto overlayi samo sus Turbo Pascal sum izpolzwal (predi wreme w Burgas na C programistite se gledashe s losho oko - samo Pascala se prinzawashe - obache az taino si uchih C - zelenata kniga!! i taka - no do overlays ne stignah)

tirulirutatuutuu

Nachi qwno problema ti e che imash dannowa struktura po golqma ot 64k (naj-weroqtno statichen masiw s mnogo elementi) reshenieto e da q razbiesh na chasti i togawa s Large modela nqma da imash problemi. Ako e masiw probwaj da go oabrbnesh na swarzan spisak ot zapisite mu kojto sazdawash dinamichno. Drugo reshenie e da minesh w 32b flat mode (po now kompilator - konzolni .exe ta za windows ili nekaf DOS extenter (Win95)) twa e.

Za toq deto smqtash e ce 64K sa mnogo - mi ne sa batka az kam mopmenta kompiliram ~1M sobstwen kod

------------------------------
I got a COMPILER, and I'm not afraid to use it!

Samo da dopalnia, che kakto e sega taka nedokosnat koda s tova saobshtenie za nadhvarleni 64K, ako da rechem mahna dva reda kod saobshtenieto za greshka izchezva!
Redovete koito maham sa da rechem:
textattr(15+(3<<4)); gotoxy(5, 6); cprintf("Neshto si");
textattr(15+(4<<4)); gotoxy(5, 7); cprintf("Ala-bala");

Razbij koda na po-malki proceduri/funkcii i gi raznesi iz razlichni fajlowe mini ma Large model i ako ne stane go z`aebi!

------------------------------
I got a COMPILER, and I'm not afraid to use it!

Niakoi spomena za Map faila ot kadeto da se videlo kade se nadhvarliat 64K. Eto negovoto sadarjanie, samoche na me ne mi stava mnogo iasno kade tochno se nadhvarliat 64K.

Error: Group DGROUP exceeds 64K

Start Stop Length Name Class

00000H 0667BH 0667CH _TEXT CODE
0667CH 06938H 002BDH PROCES_TEXT CODE
06939H 06C91H 00359H MYFOPEN_TEXT CODE
06C92H 06D78H 000E7H WAIT_TEXT CODE
06D79H 07206H 0048EH VMENUS_TEXT CODE
07207H 07522H 0031CH ERRTEST_TEXT CODE
07523H 0765BH 00139H AUTODATE_TEXT CODE
0765CH 079F3H 00398H LOGO_TEXT CODE
079F4H 085C9H 00BD6H STOKSCRL_TEXT CODE
085CAH 089B5H 003ECH SPINOUT_TEXT CODE
089B6H 0914CH 00797H SPGRAF_TEXT CODE
0914DH 09C1FH 00AD3H GRAF_TEXT CODE
09C20H 09E5EH 0023FH OLDOUTST_TEXT CODE
09E5FH 0EB40H 04CE2H KLIENTI_TEXT CODE
0EB41H 0EC9EH 0015EH ERRINFO_TEXT CODE
0EC9FH 0FD00H 01062H KREDINFO_TEXT CODE
0FD01H 183E3H 086E3H OUTSTOKA_TEXT CODE
183E4H 19E6CH 01A89H DOP_TEXT CODE
19E6DH 1C1B6H 0234AH OUTSCROL_TEXT CODE
1C1B7H 1CA16H 00860H PASSWORD_TEXT CODE
1CA17H 1CD60H 0034AH GRUPSCR_TEXT CODE
1CD61H 1E298H 01538H KLNSCROL_TEXT CODE
1E299H 20612H 0237AH DOPFUN_TEXT CODE
20620H 22D96H 02777H EMU_PROG CODE
22DA0H 23367H 005C8H E87_PROG CODE
23370H 23370H 00000H _FARDATA FAR_DATA
23370H 23370H 00000H _FARBSS FAR_BSS
23370H 23370H 00000H _OVERLAY_ OVRINFO
23370H 23370H 00000H _1STUB_ STUBSEG
23370H 32E93H 0FB24H _DATA DATA
32E94H 32E97H 00004H _CVTSEG DATA
32E98H 32EA3H 0000CH _SCNSEG DATA
32EA4H 32EA4H 00000H _CONST CONST
32EA4H 32EC7H 00024H _INIT_ INITDATA
32EC8H 32EC8H 00000H _INITEND_ INITDATA
32EC8H 32ECDH 00006H _EXIT_ EXITDATA
32ECEH 32ECEH 00000H _EXITEND_ EXITDATA
32ECEH 33397H 004CAH _BSS BSS
33398H 33398H 00000H _BSSEND BSSEND
333A0H 334AFH 00110H _STACK STACK

ne sum mnogo siguren za DOS kompilatora kojto polzwash,

no BSS sekciata (statitchnite promenlivi koito sa neinizializirani) i DATA ne se li grupirat wuw DGROUP - logichno e da e taka;

eto primer

static int someArray[100]; /* Tova shte otide wuw BSS - unitilizaed section */

static int someOtherArray[100]={0}; /* Tova shte otide wuw _DATA - initializirana sekcia */

kompilatora i linkera razdeljat tezi neshta - zashtoto izpolzwaneto na neinitializirani sekcii mozhe da namali razmera na EXE faila (obache ne vinagi - osobeno sus Borland productite) - no po princip sa edno i sushto neshto - po skoro po edin i sushti nachin se polzwat, no BSS sekciata predi da se izwika main() se nulira cjalta (_cinit pravi tova na povecheto kompilatori, pri drugi e prosto stub funckia izwikwana predi main)

taka che ti nadwishawash DGROUP-a (smetni BSS + DATA) i shte widish

tirulirutatuutuu

wsuhnost BSS+DATA = 0xFFF0,

ne sum siguren no e wuzmozhno i drugi sekcii da se grupirat wuw DGROUP,

naprimer INIT sekciata, bi trjabwalo sekcia s podobno ime da sudurzha imena na razni funckii koito da se izwikat predi main() - imashe njakakwa pragma (#pragma startup???) ili neshto ot tozi rod wuw Borland C-to - kudeto w daden .C fail mozhe da pishesh funckia kojato da se izwika awtomatichno predi main()-a,

adresite na tezi funckii se durzhat naj-verojatno w masiv void *initFuncs[0x24/4] - i se wikat predi main...

wuobshte naj -verojatno tova da ti e cjalata DGROUP-a

23370H 32E93H 0FB24H _DATA DATA

32E94H 32E97H 00004H _CVTSEG DATA

32E98H 32EA3H 0000CH _SCNSEG DATA

32EA4H 32EA4H 00000H _CONST CONST

32EA4H 32EC7H 00024H _INIT_ INITDATA

32EC8H 32EC8H 00000H _INITEND_ INITDATA

32EC8H 32ECDH 00006H _EXIT_ EXITDATA

32ECEH 32ECEH 00000H _EXITEND_ EXITDATA

32ECEH 33397H 004CAH _BSS BSS

33398H 33398H 00000H _BSSEND BSSEND 

33398 - 23370 = 10028 -> ili sus 0x28 baita nadwurljash ;)

reshenie za tova - e da proverish razni statichni masivi, konstanti - ako si izpolzwal int na mesta kudeto mozhe da izpolzwash short int ili char - zameni gi,

proveri si alignmenta w strukturite - naprimer

typedef struct {

       char a;

       short b;

       char c;

};

e po-dulgo otkolkoto

typedef struct {

      short b;

      char a;

      char c;

}

swurzano e sus alignmenta i optizimatiziite za chetene ot alignat adres.

Ako wse oshte imash problemi - prati chast ot sorsa - [email protected].

W momenta ne sum siguren - no STRINGOVETE w kompilatora kojto polzwash kude se puhat ?

da kazhem

printf("Test a test"\n")

wuw DATA ili TEXT sekcia shte otide - proveri dali njama opcii na kompilatora za puhaneto na stringovete (ili stringpoola) da e wuw coda...

naj-dobre pusni opciite na kompilatora i imeto tuka ;) - mozhe da se setim neshto

tirulirutatuutuu

В опциите на компилатора (от меню Options | Compiler) намери къде е опцията "Merge duplicated strings" (не съм много сигурен за името но звучи по подобен начин) и я избери. след това си прекомпилирай проекта.
М/у другото съобщението не означава, че си написал твърде много код, а че имаш много константни данни (static променливи, низове и т.н.).
Айде успех!

Blagodaria za novite saveti - shte gi izprobvam.
No vi dalja edno izvinenie, zashtoto ne sam bil dostatachno tochen. Triabvashe oshte ot samoto nachalo da vi citiram saobshtenieto za error, vapreki che vie kato profesionalisti sami go razbrahte:

Compiling GRUPSCR.CPP:
Compiling KLNSCROL.CPP:
Compiling DOPFUN.CPP:
Linking ..\..\OUTPUT\OUTST.EXE:
Linker Error: Group DGROUP exceeds 64K

Izbqgwaj da polzwash globalni promenliwi - losh stil e, kakto i zadrastwa pametta nenujno.
Ako si sazdawsh struktorite kogato ti trqbwat - bilo to kato lokalni promenlivi w procedurite ili kato dinamichno zadelqni blokowe pamet - pochti e sigurno che nqma da widdish podobni problemi - togawa na moda izlizat stack overflow i out of memory :))

------------------------------
I got a COMPILER, and I'm not afraid to use it!