sdcc oder z88dk

Naja, wenn man hardwarenah programmieren moechte, dann ist natuerlich Assembler die beste Wahl (aber das kann man ja auch ueber das #asm Tag bei den C-Compilern). Ansonsten bevorzuge ich Z88dk als Cross-Compiler, da hier bereits zwei Programmierbibliotheken existieren (CPCRSlib und Crocolib) und man sowohl im Wiki als auch im Forum von Z88dk meist gute und schnelle Hilfe bekommt.
In Sachen Codegenerierung bin ich mir nicht mehr ganz sicher, welcher Compiler der bessere ist, da ich mittlerweile ein paar Vergleiche gesehen habe, wo SDCC bei der Codegroesse besser wegkommt. Bei Z88dk arbeiten dafuer die Programmierer daran, dass alle Funktionen der mitgelieferten Bibliotheken nach Assembler konvertiert werden, was entsprechend Geschwindigkeit und kleinere Dateien bewirkt.
Letztendlich wirst du aber mit beiden Compilern alles erledigen koennen, was du moechtest.

Wichtiger Nachtrag: Solltest du dich mit Z88dk auseinandersetzen, dann solltest du unbedingt auf die Bibliotheken im Entwicklungsverzeichnis updaten. Die derzeitige Version hat ein Problem beim Interception-Code, der dafuer zustaendig ist bspw. bei Fliesskommanroutinen auch den Zweitregistersatz freizuraeumen. Das funktioniert nicht richtig und fuehrt gerne mal zum Absturz.

Als Grafik- und Programmiertool kann ich ausserdem TommyGun empfehlen: http://www.users.on.net/~tonyt73/TommyGun/. Ist ein ganz nettes Crossdevelopment Tool. Arbeite da momentan mit dem Entwickler daran, dass TommyGun mit der CPCRSlib einwandfrei zusammenarbeitet.

Also ich habe beide getestet und der z88dk ist der jenige, der auch zu den cpc-Eigenarten passt. Ohne die internen Anpassungen, das siehst du an den cpc-lib, läuft der z88dk schlecht und recht. Weil die aber erstellt worden sind speziell für den cpc, laufen die erstellten Programme hervorragend.

Für den anderen gibt es nur eine Handvoll erstellte spezielle cpc-Eigenschaften. Mit diesen kommt man nicht weit.

Obwohl wiedrum die Verbesserungen(Updates) bei letzteren fast Täglich kommen, wird an den cpc-Teil wenig zur verfügung gestellt.

Kommt auch daher, weil es wenige User gibt bzw interesse haben den cpc mit "c" zu proggen. des weiteren sehe ich das der Programmierteil hier sehr rar besucht ist. Es wird mehr gezockt als Programmiert.

mfg

Zum Thema C-Compiler habe ich mal ein kleines Update. So wie es aussieht, haben die Jungs bei SDCC ordentlich reingeklotzt und das Ding ordentlich optimiert. Zur naechsten Version, die wohl im Maerz dieses Jahres kommen soll, werden die Binaerdateien wohl nochmal um ~4% kleiner werden. Einen Vergleich gibt es hier:
http://sdcc.wiki.sourceforge.net/Philipp's+TODO+list.
Mal schauen, ob ich die Tage mal dazu komme mir den SDCC Compiler anzuschauen.

Mal schauen, ob ich die Tage mal dazu komme mir den SDCC Compiler anzuschauen.

Der den auf dem CPC nutzen möchte, gibt er fasst garnichts her mit der Unterstützung.

Es gibbet einen neuen z88dk, da gibt es viel neues für den CPC.

Ich habe die FIle in/out noch nicht getestet.

So sieht beim z88dk die h aus:

/*
 *      Small C+ Library
 *
 *      fnctl.h - low level file routines
 *
 *      djm 27/4/99
 *
 *	$Id: fcntl.h,v 1.10 2009/01/13 17:48:01 stefano Exp $
 */




#ifndef __FCNTL_H__
#define __FCNTL_H__


#include <sys/types.h>




#define O_RDONLY  0
#define O_WRONLY  1
#define O_APPEND  256


#define SEEK_SET 0
#define SEEK_CUR 1
#define SEEK_END 2




/* O_BINARY has no significence */
#define O_BINARY  0


typedef int mode_t;




extern int __LIB__ open(far char *name, int flags, mode_t mode);
extern int __LIB__ creat(far char *name, mode_t mode);
extern int __LIB__ close(int fd);
extern size_t __LIB__ read(int fd, void *ptr, size_t len);
extern size_t __LIB__ write(int fd, void *ptr, size_t len);
extern long __LIB__ lseek(int fd,long posn, int whence);


extern int __LIB__ __FASTCALL__ readbyte(int fd);
extern int __LIB__ writebyte(int fd, int c);


/* Open a file returning the explicit filename, with length len */


extern int __LIB__ open_z88(far char *name, int flags, mode_t mode, char *explicit, size_t len);


/* As above except the filename is near - good for ZSock devices (z88)*/


extern int __LIB__ nropen(char *name, int flags, mode_t mode, char *explicit, size_t len);


extern int __LIB__ mkdir(char *, int mode);
extern char __LIB__ *getcwd(char *buf, size_t maxlen);


/* Following two only implemented for Sprinter ATM (20.11.2002) */
extern int  __LIB__ rmdir(char *);
extern char __LIB__ *getwd(char *buf);




#endif /* _FCNTL_H */

GRuss

Zitat

Naja, wenn man hardwarenah programmieren moechte, dann ist natuerlich Assembler die beste Wahl (aber das kann man ja auch ueber das #asm Tag bei den C-Compilern).

Hier ein kleines Muster für den z88dk zur Ermunterung, dem sind keine Grenzen gesetzt.
Die Variablen werden über den Stack eingelesen:

#include <stdio.h>
#include <stdlib.h>


#pragma -zorg=16384


void draw(unsigned int codeint, unsigned int codeint1 ){
#asm
        ld      hl,4
        add     hl,sp
        ld      a,(hl)
        ld      e,a


        ld      hl,5
        add     hl,sp
        ld      a,(hl)
        ld      d,a


        ld      hl,2
        add     hl,sp
        ld      a,(hl)
        ld      c,a


        ld      hl,3
        add     hl,sp
        ld      a,(hl)
        ld      b,a


        ld      h,b
        ld      l,c
        call    0xBBF6
        ret
#endasm
}


int main(void){


   unsigned char c;

   draw (640,200);

   c = getchar();


   return 0;
}