Ilyet még talán nem is láttam, hogy unsigned magában. Ez ilyenkor unsigned int lesz ugye?
Melyik micsoda és honnan jönnek ezek? Úgy értem a linuxnak muszáj vagy ez a gcc működéséből fakad és lehet, hogy más fordító nem tenné ezeket oda?
Ha tudjátok hogy mit csinálnak ezek az objectek az érdekelne.
Ilyet még talán nem is láttam, hogy unsigned magában. Ez ilyenkor unsigned int lesz ugye?
Ilyet még talán nem is láttam, hogy unsigned magában. Ez ilyenkor unsigned int lesz ugye?Keress leírásokat a C Runtime Library (magyarul C futásidejű könyvtár - talán) témakörben. Ezek alapvető szolgáltatásokat biztosítanak, ami lehetővé teszi a programnak az operációs rendszeren futtatását.
Nekem az lenne a kérdésem, bár lehet, hogy ep-t nem érinti, miért kell linuxon de lehet, hogy máshol is hozzá linkelni az alábbiakat a programhoz:
crt1.o
crti.o
crtbegin.o
crtend.o
crtn.o
Melyik micsoda és honnan jönnek ezek? Úgy értem a linuxnak muszáj vagy ez a gcc működéséből fakad és lehet, hogy más fordító nem tenné ezeket oda?
Na most lehet, hogy nagy hülyeséget kérdezek :oops:
Ezek a modern PC-s Z80 C-k tudnak kezelni többet mint 64K?
foo:
.LFB0:
.cfi_startproc
xor eax, eax
cmp esi, edi
jge .L4
.p2align 4,,10
.p2align 3
.L3:
mov edx, esi
add eax, 1
sar edx, 3
add esi, edx
cmp edi, esi
jg .L3
rep ret
.L4:
rep ret
.cfi_endprocSzerintem inkabb azt kene megvizsgalni, hogy valoban szukseg van-e arra, hogy minden mukodjon 64K-s hatart attorve, vagy elfogadhato, ha adott esetben platform specifikus dolgok vannak, akar pl ugy, hogy a megfelelo C fuggvenynek valo entitassal az ember lapozgat, mintha asm lenne a dolog. Nem tul szep, az igaz.
A MESCC-el hogy kell .com-ot készítni?
A hextobin csak annyit ír ki, hogy Missing colon.
Ha csak egy nagy méretű tömb kell, akkor annak a kezeléséhez (lefoglalás, felszabadítás, elem olvasása, elem írása) viszonylag könnyen lehet inline asm rutinokat írni. Az már problémásabb, ha a kód + változók + verem is többet igényel, mint 64K.
ezt cpm alól futtatod? mert ha nem akkor gondolom nem fog tudni hova kilépni. véget ér a program majd jó eséllyel lefagy a rendszer.
Az eredmény (a z88dk-s program azért ennyire nagy, mert tartalmaz egy 12288 byte méretű statikus tömböt), csak a decompressData rutin futásideje:
(Attachment Link) (assembly): 0.435 másodperc
(Attachment Link) (SDCC): 1.943 másodperc
(Attachment Link) (z88dk): 5.402 másodperc
nem rossz, azért nagyságrendileg hasonló lett az eredmény :-)
azért az durva, mennyivel lassabb kódot állít elő a z88dk
Ez már nem egészen fair összehasonlítás, mert a gyorsabb verziók az SDCC-vel készültek (azzal teszteltem, hogy az egyes változtatások javítanak-e a kódon), ezért bizonyos mértékben arra a fordítóra optimalizáltak. De más tesztekben is általában az SDCC jobb kódot generál - legalábbis a C runtime használata nélkül, egész számos aritmetikával. A runtime függvények és a float típus megvalósítása viszont a z88dk-ban tűnnek jobbnak, azzal jobban is futott a mandel.c és a tunnel.c.
Have you tried the latest z88dk which combines sdcc and z88dk together?
The difference between z88dk and sdcc is this:
sdcc's library is minimal and it is implemented in C. A handful of functions are implemented in asm and these include 16-bit arithmetic, memcpy, strcpy, strncpy, strchr, and memset. sdcc's compiler tries to generate optimized translated C. The idea behind sdcc's library is that, written in C, it is portable to all of its target CPUs.
z88dk's library aims for C standard compliance and it is written in assembly language. z88dk's compiler tries to generate small translated C - that's why you see many calls. The idea behind z88dk's library is that most execution time will be spent in library routines so the speed is delivered by the library and small code size is delivered by the compiler.
When you compare small C fragments that don't make use of library functions, sdcc will always generate faster code than z88dk. However, in more realistic programs where library functions are important, z88dk will normally be faster and smaller. You saw an exaggerated case of this when you compiled using float functions. sdcc's float library is 32-bit and entirely written in C. z88dk's is 48-bit and entirely in assembly language. z88dk's float implementation is almost 3 times smaller and almost 3 times faster than sdcc's despite the larger float type. Similar results come from 32-bit integer math but both z88dk and sdcc will have similar performance for 16-bit integer math since both are implemented in asm.
You can see some benchmark results here:
http://www.z88dk.org/wiki/doku.php?id=temp:front#benchmarks
sdcc and z88dk have been modified in the past year to be made compatible with each other. The new version of z88dk allows sdcc to be used as C compiler while supplying the crts and C library and improving sdcc's output. This combination produces results in code size and speed that are very good compared to commercial compilers.
If you have the new version of z88dk installed and have a [url=http://www.z88dk.org/wiki/doku.php?id=temp:front#sdcc1]patched sdcc executable,[/url] you can compile programs like this:
zcc +embedded -vn -SO3 -startup=0 -clib=sdcc_iy --max-allocs-per-node200000 test.c -o test
You will have to add a pragma to the top of "test.c" to change the org address:
#pragma output CRT_ORG_CODE = 32768
The output will be "test_CODE.bin" which is ORGed at address 32768 in this case.
Because it's the embedded target there is no stdio, stdout, stderr so printf would have to be replaced by sprintf or snprintf. %f is also disabled by default so to enable any of %aefg the library has to be rebuilt. That's the sort of thing described in the wiki.
To simply look at the translated C you don't have to generate a binary and you can use whatever functions you want:
zcc +embedded -vn -a -SO3 -clib=sdcc_iy --max-allocs-per-node200000 test.c
This combination of z88dk/sdcc is always faster and smaller than either sdcc alone or z88dk alone (except when the program contains lots of longs) and it has very good compliance with the C standard. sdcc supplies the compiler compliance and z88dk supplies the library compliance.
Unfortunately there are only three targets currently defined for this combination: +cpm +embedded and +zx. +embedded is the general target and can be used to compile for any z80 machine but of course things like stdin, stdout, stderr, graphics, sound, etc will not be available as the target hardware is undefined.
This translation is going to be terrible so I put the english into code blocks. Sorry :(I think you should start a topic "C programming (Aztec C / Hisoft C)" in the English forum instead.
A += és -= operátorok helyett =+ és =- van...
Tudtommal a B nyelvben voltak += és -= operátorok, és a C-ben már megfordították, hogy a "a =- b" kifejezés ne értelmeződjön "a = -b"-nek a "a = a - b" helyett... De ezek szerint akkor még a korai C nyelvben is így volt...
Forrásprogramot lehet kérni?a unix v7 cal.c forráskódja módosítás nélkül lefordul:
register d, i; int d;
register i;
Egyébként nem rossz dolog, hogy az Aztec először ASM forráskódot állít elő, mert így elég egyszerű még kézzel kicsit optimalizálni a kódot. (ilyenkor mindig elgondolkodok, hogy tényleg ez volt a csúcs a '80-as években? manapság el vagyunk kényeztetve a szénné optimalizált fordított kódokkal).
Ezt amugy talan Fejszen :) is kommenteltem: ez nem tudom miert meglepo, ez manapsag is pontosan igy van a UNIX-szeru op'rendszereken pl Linuxon is. Az mas kerdes, hogy "normal" esetben user szamara nem lathato, mert egy pipe-on at atadja az assembler-nek, igy az asm-al nem is talalkozol, de amugy ott van kozben az is, es egyetlen kapcsoloval ra is birhatod, hogy adja oda neked inkabb. Xep128-nal is hasznaltam pl, hogy lassam, mit produkal :-DNekem meglepő volt, mert nem nagyon használok GCC-t :-)
Kösz az infót! Be is írtam ide (http://ep128.hu/Ep_Konyv/C_Programozasi_nyelv.htm#4_7).Akkor az már nem is az eredeti könyv teljesen, hanem bővített "kiadás".
kis kiegészítés...
a CC.COM 8080 assembly-re fordít, ott csak egy változó lehet regiszterben, a BC-be kerül.
a CZ.COM viszont Z80-ra fordít, és három "register"-es változónk lehet, a másik kettőt az IX-be és IY-ba pakolja. Érdekes, hogy ugyanúgy 8080 assembly forráskódot állít elő, a Z80 specifikus (indexregiszteres) utasítások DB-vel vannak benne.
Nekem meglepő volt, mert nem nagyon használok GCC-t :-)
Akkor az már nem is az eredeti könyv teljesen, hanem bővített "kiadás".
Igen, az Aztec és a HiSoft fordítóról van benne némi plusz infó, a Unix-os dolgok viszont kimaradtak belőle (nem sok).
Amugy szoban forgo C forditok csak a K&R szintaxist tamogattak fuggevenyeknel? Marmint erre gondolok K&R kapcsan:Code: C
Mig manapsag ezt mar nem kifejezetten szokas hasznalni mar, hanem:Code: C
Az Aztec C a K&R szintaxist támogatja (a régi 7-es UNIX (és a cal.c) is azzal van írva. Az újat nem is fogadja el. A HiSooft-ot nem néztem, most a HiTech-hel próbálkozok. Az egy kicsit többet tud.
Ez is erdekes amugy, modern C compilerek meg mindig elfogadjak a "register" kulcsszot, de figyelmen kivul hagyjak, ui az optimalizalo kepessegeik alapjan onalloan, a register szerepeltetese nelkul is regiszterekbe tesznek dolgokat, attol fuggoen, hogy a cel CPU mennyit enged meg, es melyik/melyek az/azok a valtozo(k), amit erdemes szerinte.
bool IsOdd(int n)
{
return (n & 1);
}
most a HiTech-hel próbálkozok. Az egy kicsit többet tud.Itt a HiTech C-vel fordított .com.
Hasonló az inline kulcsszó a CPP-ben.