Vlákno názorů k článku Překladače na platformě IBM PC: od assembleru k C (32bitový kód a FPU) od atarist - Hodilo by se dodat, ze sice DJGPP (tedy...

Hodilo by se dodat, ze sice DJGPP (tedy GCC) asi mel nejlepsi vysledny kod, ale preklad trval VEKY. Na 486 Borland C prekladal prakticky okamzite, Watcom C nas kod rekneme do 2-3 sekund, ale DJGPP na tom sedel klidne pul minuty. A to bez vypnutych optimalizaci, jen zakladni preklad.

(navic, jestli si pamatuju, umel Borland C nejak cachovat include soubory do nejake predpripravene binarky)

Tak dlouhý čas je zvláštní. Nebylo to spíš nedostatkem paměti než kompilátorem samotným? DJGPP chtělo dost paměti - na 4 MB RAM mi tehdy běžně šly to swap, který CWSDPMI podporovalo.

Tyjo to je možný. Měl jsem 4GB a potom 8GB (víc do mé desky 486 nešlo narvat). Ale když jsem dělal v DJGPP, tak to asi byly ty 4GB.

* dneska dost směšné hodnoty, že?

GB->MB sorry, opravit to uz nemuzu

Ani ne tak "předpřipravené" (význam tohoto patvaru mi vždycky unikal - jakou funkci v něm plní ta předpona "před"?), jako předkompilované.

U nás ve firmě skladníci používají výraz "předpříjemka" :-D Ta předpona je prostě univerzálně na vše "temporary"...

28. 5. 2025, 14:38 editováno autorem komentáře

Zajímavé. Mně to zatím dávalo jakýs-takýs smysl, když se zeptám, zda-li už je něco hotové a dotyčný mi odpoví, že to má předpřipravené, přeložím si to jako "úplně jsem se na to vykašlal". :)

Dlouhy peeklad delal klidne I borland kdyz si vypnul preklad knihoven do obj.
Dalsim trikem bylo ze si borland pamatoval cas prekladu a kdyz se casova znacka nezmenila pak neprekladal. Stacilo posunout cas PC do minulosti a on prekladal vsechno furt. A to trvalo.

Nee, myslel jsem fakt cast prekladu DJGPP, ne porovnani s BC, kterej nepreklada obj v pripade, ze se zdrojaky nezmenily. To se resilio i kdekoli jinde pres Make a RHIDE presne takto vytvorilo projekt - byl tam Makefile a prekladal se (dloooouho) vzdycky jen ten jeden malej zdrojak, ktery se menil. Ostatni se jen slinkovalo.