1: Når jeg kompilerer det minste mulige C++ -programmet er kildekoden
på 19 bytes, men programmet (n.exe) er på 85 kb. Hvorfor er
forskjellen så stor?
Kildekoden er: void main () {;}
2: Når jeg kompilerer dette til n.com og prøver å kjøre det i en
dos-boks under Win98, får jeg beskjeden: Programmet er for stort til å
få plass i minnet. Det er litt merkelig siden jeg har 572 kb ledig
konvensjonelt minne. Kan noen forklare hvorfor?
--
--------------------------------------------
Carl A. Myrvang, MCSE *** a.k.a. Eldhannas
mailto:Eldh...@c2i.net *** ICQ #14812107
--------------------------------------------
Life is just a figment of your imagination
--------------------------------------------
Fordi du får med masse ekstra moro som du kan få bruk for. Det som
kan hjelpe er f.eks å ikke kompilere inn debug-info og å strippe
den kjørbare filen for unødvendige data.
Jeg får:
[stig@palomba ~]$ cat hei.cpp
int main() { return 0; }
[stig@palomba ~]$ c++ hei.cpp
[stig@palomba ~]$ strip a.out
[stig@palomba ~]$ ls -l a.out
-rwxr-xr-x 1 stig users 3040 nov 22 17:36 a.out
[stig@palomba ~]$
>Kildekoden er: void main () {;}
main() bør vel kanskje returnere et heltall i c++?
>2: Når jeg kompilerer dette til n.com og prøver å kjøre det i en
>dos-boks under Win98, får jeg beskjeden: Programmet er for stort til å
>få plass i minnet. Det er litt merkelig siden jeg har 572 kb ledig
>konvensjonelt minne. Kan noen forklare hvorfor?
Du forteller oss ikke hvilken kompilator du har, og com-formatet
er vel ikke det som folk jobber hardest for å støtte for tiden.
Aner ikke om det virker på winXX en gang. Hva med å forsøke på
"virkelige problem"?
--
------------------------------------------------------------------
Stig Erik Sandoe st...@ii.uib.no http://www.ii.uib.no/~stig/
M.a.o. a.out utgjør 3040 bytes av 85243 bytes?
>
> >Kildekoden er: void main () {;}
>
> main() bør vel kanskje returnere et heltall i c++?
Hvorfor det i dette tilfellet? Poenget var å skrive det minste
programmet man kan kompilere i C++, og tallet som returneres brukes
for å sjekke om noe går galt. Hvis ingenting skjer, kan heller ikke
noe gå galt :-D
> >2: Når jeg kompilerer dette til n.com og prøver å kjøre det i en
> >dos-boks under Win98, får jeg beskjeden: Programmet er for stort til å
> >få plass i minnet. Det er litt merkelig siden jeg har 572 kb ledig
> >konvensjonelt minne. Kan noen forklare hvorfor?
>
> Du forteller oss ikke hvilken kompilator du har, og com-formatet
> er vel ikke det som folk jobber hardest for å støtte for tiden.
Bruker DJGPP v.2.02
> Aner ikke om det virker på winXX en gang.
Joda, WinXX startes med win.com
> Hva med å forsøke på "virkelige problem"?
Vel, jeg er på Dag 4 av "Teach Yourself C++ in 21 Days" av Jesse
Liberty, så jeg er ikke klar for å skrive de helt store programmene
ennå :-)
Mao så er mitt tilsvarende program 3k hvor ditt er 85k. Dette er
likevel ikke spesielt interessant, da det er for større program det er mer
interessant å måle størrelse. Dessuten er mitt program linket dynamisk
til libc, mens ditt trolig er linket statisk.
>> >Kildekoden er: void main () {;}
>>
>> main() bør vel kanskje returnere et heltall i c++?
>
>Hvorfor det i dette tilfellet? Poenget var å skrive det minste
>programmet man kan kompilere i C++, og tallet som returneres brukes
>for å sjekke om noe går galt. Hvis ingenting skjer, kan heller ikke
>noe gå galt :-D
Nå kan sikkert noen andre sitere fra standarden for deg, men i C++
returnerer faktisk main() int. Hvis det er C++ du har tenkt å skrive
bør du gjerne forsøke å skrive C++ og ikke "et eller annet som
kompilatoren spiser".
>> Du forteller oss ikke hvilken kompilator du har, og com-formatet
>> er vel ikke det som folk jobber hardest for å støtte for tiden.
>
>Bruker DJGPP v.2.02
Finn en mer oppdatert kompilator hvis du har tenkt å skrive (nyere)
c++. Det enkleste er vel her å få fatt i en un*x boks og kompilere
opp siste versjon av gcc.
>> Hva med å forsøke på "virkelige problem"?
>
>Vel, jeg er på Dag 4 av "Teach Yourself C++ in 21 Days" av Jesse
>Liberty, så jeg er ikke klar for å skrive de helt store programmene
>ennå :-)
Da spiller det vel liten rolle hvor stor programmene blir ennå.
> >
> >M.a.o. a.out utgjør 3040 bytes av 85243 bytes?
>
> Mao så er mitt tilsvarende program 3k hvor ditt er 85k.
OK
>
> >> >Kildekoden er: void main () {;}
> >>
> >> main() bør vel kanskje returnere et heltall i c++?
> >
> >Hvorfor det i dette tilfellet? Poenget var å skrive det minste
> >programmet man kan kompilere i C++, og tallet som returneres brukes
> >for å sjekke om noe går galt. Hvis ingenting skjer, kan heller ikke
> >noe gå galt :-D
>
> Nå kan sikkert noen andre sitere fra standarden for deg, men i C++
> returnerer faktisk main() int. Hvis det er C++ du har tenkt å skrive
> bør du gjerne forsøke å skrive C++ og ikke "et eller annet som
> kompilatoren spiser".
>
Beklager, standarder er til for å følges, men oppgaven i boka var å
skrive det minste programmet som kunne kompileres, og i dette
spesielle tilfellet mente jeg en return-value hadde lite for seg.
Kompilatoren advarte forresten om at main() skulle være av type int.
> >> Du forteller oss ikke hvilken kompilator du har, og com-formatet
> >> er vel ikke det som folk jobber hardest for å støtte for tiden.
> >
> >Bruker DJGPP v.2.02
>
> Finn en mer oppdatert kompilator hvis du har tenkt å skrive (nyere)
> c++. Det enkleste er vel her å få fatt i en un*x boks og kompilere
> opp siste versjon av gcc.
Learning Red Hat Linux er på vei posten fra England as we write, så
det skal nok bli en mulighet for det :-)
| Vel, jeg er på Dag 4 av "Teach Yourself C++ in 21 Days" av Jesse
| Liberty, så jeg er ikke klar for å skrive de helt store programmene
| ennå :-)
bøker av typen "Teach yourself X in Y days" har rykte for å være svært
dårlige.
se forøvrig <URL:http://www.norvig.com/21-days.html>.
--
mvh
Tor Henrik Hanken
>On Mon, 22 Nov 1999 16:12:31 GMT, Carl A. Myrvang <Eldh...@c2i.net> wrote:
>>...som jeg håper noen kan svare på:
>>
>>1: Når jeg kompilerer det minste mulige C++ -programmet er kildekoden
>>på 19 bytes, men programmet (n.exe) er på 85 kb. Hvorfor er
>>forskjellen så stor?
>
>Fordi du får med masse ekstra moro som du kan få bruk for.
[snip]
.. og filformatet har også noget at sige. .com er 'raw' og begrenset
til et segment - første byte er første kode. .exe har op til
et-eller-andet antal sektioner tilegnet code, data, debug,
relocation-table og sådan.. disse er envidere beskrevet i nogle
header sectioner - og alt alignes på en eller anden boundary. Så
selvom selve koden er lille, vil der være en del andet som tager
plads.
>>2: Når jeg kompilerer dette til n.com og prøver å kjøre det i en
>>dos-boks under Win98, får jeg beskjeden: Programmet er for stort til å
>>få plass i minnet. Det er litt merkelig siden jeg har 572 kb ledig
>>konvensjonelt minne. Kan noen forklare hvorfor?
>
>Du forteller oss ikke hvilken kompilator du har, og com-formatet
>er vel ikke det som folk jobber hardest for å støtte for tiden.
>Aner ikke om det virker på winXX en gang. Hva med å forsøke på
>"virkelige problem"?
.com virker fint i windos xx. En del af de kendte dos-ting som følger
med windos 98 er stadig i .com format (som edit, format - og
command.com)
Men.. brug hellere .exe
-Henrik Gram
> On Mon, 22 Nov 1999 16:12:31 GMT, Carl A. Myrvang <Eldh...@c2i.net> wrote:
> >...som jeg håper noen kan svare på:
> >
> >1: Når jeg kompilerer det minste mulige C++ -programmet er kildekoden
> >på 19 bytes, men programmet (n.exe) er på 85 kb. Hvorfor er
> >forskjellen så stor?
>
> Fordi du får med masse ekstra moro som du kan få bruk for. Det som
> kan hjelpe er f.eks å ikke kompilere inn debug-info og å strippe
> den kjørbare filen for unødvendige data.
> Jeg får:
> [stig@palomba ~]$ cat hei.cpp
> int main() { return 0; }
> [stig@palomba ~]$ c++ hei.cpp
> [stig@palomba ~]$ strip a.out
> [stig@palomba ~]$ ls -l a.out
> -rwxr-xr-x 1 stig users 3040 nov 22 17:36 a.out
> [stig@palomba ~]$
La oss leke litt. Først lager vi en objektfil som er så liten som
mulig.
hb:/tmp:(527)$ cp /dev/null tom.c
hb:/tmp:(538)$ gcc -g -c tom.c
hb:/tmp:(539)$ ls -l tom.o
-rw-r--r-- 1 steinarh fall 1924 Nov 23 20:08 tom.o
hb:/tmp:(530)$ gcc -c tom.c
hb:/tmp:(531)$ ls -l tom.o
-rw-r--r-- 1 steinarh fall 662 Nov 23 20:04 tom.o
hb:/tmp:(532)$ strip tom.o # nå kan den ikke lenkes med men...
hb:/tmp:(533)$ ls -l tom.o
-rw-r--r-- 1 steinarh fall 432 Nov 23 20:05 tom.o
hb:/tmp:(546)$ gcc -S tom.c
hb:/tmp:(547)$ cat tom.s
.file "tom.c"
.version "01.01"
gcc2_compiled.:
.ident "GCC: (GNU) 2.8.1"
altså 1924 med alle debuggingssymboler, 662 med symboler, og 432
strippet for alle symboler. (Dvs fil-header-info(ELF) og strengene.)
Litt større program:
hb:/tmp:(534)$ cat abc.c
int main() { return 0; }
hb:/tmp:(548)$ gcc -g -c abc.c
hb:/tmp:(550)$ ls -l abc.o
-rw-r--r-- 1 steinarh fall 2036 Nov 23 20:14 abc.o
hb:/tmp:(536)$ gcc -c abc.c
hb:/tmp:(537)$ ls -l abc.o
-rw-r--r-- 1 steinarh fall 695 Nov 23 20:07 abc.o
hb:/tmp:(551)$ strip abc.o
hb:/tmp:(552)$ ls -l abc.o
-rw-r--r-- 1 steinarh fall 444 Nov 23 20:15 abc.o
hb:/tmp:(556)$ gcc -S abc.c
hb:/tmp:(557)$ cat abc.s
.file "abc.c"
.version "01.01"
gcc2_compiled.:
.text
.align 4
.globl main
.type main,@function
main:
pushl %ebp
movl %esp,%ebp
xorl %eax,%eax
jmp .L1
.align 4
.L1:
movl %ebp,%esp
popl %ebp
ret
.Lfe1:
.size main,.Lfe1-main
.ident "GCC: (GNU) 2.8.1"
Litt større, men faktisk bare 12 bytes når vi har strippet vekk alt
bortsett fra intruksjonene.
Og så linker vi det hele.
hb:/tmp:(562)$ ls -l abc
-rwxr-xr-x 1 steinarh fall 25119 Nov 23 20:24 abc*
hb:/tmp:(563)$ gcc abc.c -o abc
hb:/tmp:(564)$ ls -l abc
-rwxr-xr-x 1 steinarh fall 24783 Nov 23 20:24 abc*
hb:/tmp:(565)$ strip abc # denne skal ihvertall ikke lenkes mer...
hb:/tmp:(566)$ ls -l abc
-rwxr-xr-x 1 steinarh fall 6800 Nov 23 20:24 abc*
Her har det vokst riktig så mye. Mesteparten skyldes antagelig:
hb:/tmp:(568)$ ls -l /usr/lib/crt?.o
-rw-r--r-- 1 root root 876 Jul 14 1998 /usr/lib/crt1.o
-rw-r--r-- 1 root root 1092 Jul 14 1998 /usr/lib/crti.o
-rw-r--r-- 1 root root 838 Jul 14 1998 /usr/lib/crtn.o
crt?.o gjør all magien rundt det å starte (og avslutte) programmet,
sette igang dynamisk lenking hvis nødvendig osv... (kort sagt alt det
du abstraherer bort ved å tenke at programmet starter og ender i
main())
Tilslutt kan vi prøve å lenke statisk:
hb:/tmp:(570)$ gcc -g -static abc.c -o abc
hb:/tmp:(571)$ ls -l abc
-rwxr-xr-x 1 steinarh fall 453492 Nov 23 20:27 abc*
hb:/tmp:(572)$ gcc -static abc.c -o abc
hb:/tmp:(573)$ ls -l abc
-rwxr-xr-x 1 steinarh fall 453156 Nov 23 20:28 abc*
hb:/tmp:(574)$ strip abc
hb:/tmp:(575)$ ls -l abc
-rwxr-xr-x 1 steinarh fall 97328 Nov 23 20:28 abc*
Det ble stort det. Men likevel veldig mye mindre enn libc selv:
hb:/tmp:(576)$ ls -l /usr/lib/libc.a
-rw-r--r-- 1 root root 7593636 Jul 14 1998 /usr/lib/libc.a
Forklaringen er at når du lenker statisk inkluderer lenkeren kun de
delene av libc som er brukes av programmet. (og det er jo ikke mye)
Steinar
Du kan lage en objektfil av en tom translation unit, men for å ha et
_program_ må du ha en "main" å linke med.
En mulighet for å få noe kortere enn
int main() { return 0; }
er
int (*main)();
(vi bryr oss ikke så mye om hva den peker på. Dette vil selvfølgelig
ikke _kjøre_.) Noen bedre?
Steinar
> En mulighet for å få noe kortere enn
>
> int main() { return 0; }
>
> er
>
> int (*main)();
>
> (vi bryr oss ikke så mye om hva den peker på. Dette vil selvfølgelig
> ikke _kjøre_.) Noen bedre?
Tja, hva med
int main=0;
Eller hvis du vil trigge FOOF-buggen i Pentiumen din
int main = -926478352;
Kanskje ikke helt ansi/iso kosher?
Mvh,
--
Hans Peter Verne ( hpv @ kjemi.uio.no ) Phone: (+47) 22 85 54 14
Dept. of Chemistry, University of Oslo. Fax: (+47) 22 85 54 41
`It would seem that you have no useful skill or talent whatsoever,
have you thought of going into teaching?' -- Terry Pratchett, "Mort"
> .com virker fint i windos xx. En del af de kendte dos-ting som følger
> med windos 98 er stadig i .com format (som edit, format - og
> command.com)
DOS bruker ikke filnavnet for å finne ut om en fil er i com eller exe
format. F.eks. så har command.com vært en exe-fil lenge, selv om den
har beholdt navnet. Jeg vil tro dette gjelder også for de andre filene
du nevner, selv om jeg ikke har sjekket det opp. Når det er sagt så
klarer nok fremdeles Windows å kjøre ekte com-filer.
--
Håvard Kvålen ** http://home.sol.no/~havardk/
Det er vel _svært_ avhengig av forfatteren, vil jeg tro. Poenget er
bare at man skriver boken slik at det man skal lære bort er delt opp i
deler av omtrent lik lengde, og ikke gaper over for mye. Dette er
tross alt nybegynnerbøker for å få et grunnlag innen emnet.