Uso Del Linguaggio C Nativamente Sul C64

[Pasquale_F]

 In questi giorni mi sto dilettando col linguaggio C sul C64, cosa che ho mai fatto a suo tempo; per la verità non ho mai usato niente di diverso che non fosse il semplice basic e un po' l'assembly.
Devo dire che il mio scetticismo iniziale a lasciato piano piano spazio ad una moderata soddisfazione; almeno, per programmi di lunghezza medio/lunga, è una scelta di gran lunga preferibile rispetto al basic interpretato.
Le scelte possibili si riducono a 2: il Power-C di Better&Working a il Super-C di Abacus.

Il primo godrebbe di una buona fama, produce codice nativo relativamente veloce, ha una libreria molto ricca, una shell unix-like con molti comandi e un assembler integrato. Ma soffre di alcuni fastidiosi bugs, sia la shell che il compilatore spesso danno i numeri e l'editor non è sicuramente dei più sofisticati; non si può certo dire che lasci molto spazio alla fantasia.

Per contro il Super-C di Abacus mi sembra molto più stabile, i programmi mi sembra siano altrettanto veloci e, anche se non ha un assemblatore integrato, dovrebbe essere possibile linkare anche codice prodotto con qualsiasi altro assemblatore. La shell CP/M (o MSDOS) like è più scarna ma molto efficace. Da che lo sto usando non ho notato problemi di sorta, neanche col compilatore e col linker.
La libreria è più misera ma permette di fare quasi tutto, forse manca qualcosa per il SID.
Comunque il suo punto di forza è l'editor, sebbene all'inizio possa sembrare poco "user friendly" ma col tempo si possono apprezzare molte sue caratteristiche che rendono la scrittura e la lettura del codice abbastanza facile e veloce.

Premetto che secondo me alcune caratteristiche del linguaggio C si possono apprezzare meglio sul C64 (o su qualsiasi altro computer di 25/30 anni fa) rispetto ad un moderno PC; per esempio la distinzione tra alcuni tipi di dati (che oggi non sembra avere molto senso), le short form di alcune operazioni sulle variabili, la possibilità di scomporre il programma in piccoli pezzi e poi di unirli (linkarli) insieme, e molto altro.

Ovviamente sul C64 è una scelta un pò "azzardata", il massimo lo si ottiene solo a basso livello, ma il C è comunque un buon compromesso e permette di affinare e di mettere alla prova le proprie capacità di programmatore su una macchina così obsoleta.

[COMMODORO]

 Interessante.
Fino a poco tempo fa non credevo fosse stato possibile programmare qualcosa in C sul C64.
Si conoscono prodotti famosi, commerciali o no per il C64 scritti usando questi compilatori? O sono stati creati più che altro per scopi didattici visto che gli eseguibili risultano di prestazioni troppo scarse rispetto a quelli possibili utilizzando l'Assembly?
 

[Pasquale_F]

 

Interessante.
Fino a poco tempo fa non credevo fosse stato possibile programmare qualcosa in C sul C64.
Si conoscono prodotti famosi, commerciali o no per il C64 scritti usando questi compilatori? O sono stati creati più che altro per scopi didattici visto che gli eseguibili risultano di prestazioni troppo scarse rispetto a quelli possibili utilizzando l'Assembly?

Alla prima domanda è impossibile rispondere con certezza ma di sicuro sono stati commercializzati software che non fossero scritti nei "soliti" basic o assembly.

Per quanto riguarda la seconda, certamente l'assembly non lo batte nessuno ma il C può avere i suoi punti di forza nel fatto di essere un linguaggio strutturato ad alto livello che permette di scrivere e gestire meglio codici di una certa lunghezza e complessità (nei limiti, ovviamente, della memoria del computer); a causa delle caratteristiche proprio del C, nel caso di programmi lunghi e complessi le differenze di "performance" con l'assembly stesso si assottigliano. Il C è stato sviluppato apposta per questo, per cui, paradossalmente, può essere più "idoneo" per il C64 piuttosto che per un moderno PC.

Ovviamente stiamo parlando di un linguaggio che ha bisogno pur sempre del "suo spazio" (così come tutti i linguaggi strutturati) per cui la scelta sembra quanto meno "azzardata" sul C64 da cui comunque è possibile (nei limiti della macchina) creare qualcosa di "usabile"; tutto dipende anche dalle capacità di gestione delle risorse da parte del programmatore.
Per questo, a mio avviso, il C sul Commdore 64 può rappresentare un "buona" palestra.

[Pasquale_F]

 Qui è possibile trovare tante soluzioni "esotiche" per il nostro commodore 64:

http://commodore64.wikispaces.com/Programming+languages

Ovviamente il mio consiglio è quello di provare l'Abacus-C, non conoscendo (basic a parte) gli altri linguaggi. È presente anche una versione "hackerata". Confermo di non avere avuto una buona impressione del Power-C, per come è strutturato tanto vale usare solo l'Assembly.

Dell'Abacus-C la documentazione è disponibile qui:

http://www.lyonlabs.org/commodore/onreques...er-C-Abacus.pdf

Tenendo presente che si tratta di un compilatore che è conforme con il vecchio standard k&R prima versione, per cui le funzioni si dichiarano così:

Codice: [Seleziona]

int moltiplicazione(x,y) int x; int y; {
        return(x*y);
}
mentre le procedure si scrivono così:

Codice: [Seleziona]

void mio_nome() {
        printf("\nIo mi chiamo Pasquale\n");
}
Manca degli (inutili) bit fields. Per il resto accetta la stessa sintassi di qualsiasi moderno compilatore. Ha una libreria grafica che però permette di disegnare grafici e sprites solo a bassa risoluzione (almeno questo mi pare di aver capito) ma  comunque dalle buone performance. Non dovrebbe però essere difficile crearne ad alta risoluzione, magari scrivendo librerie apposite.
Non mi pare che ci sia grande supporto per il SID, ma anche in questo caso è possibile risolvere facilmente il problema.

Nella documentazione non si fa riferimento alla possibilità di linkare o comunque integrare codice assembly (si usa un linguaggio ad alto livello apposta per evitare quest'ultimo o comunque di limitarne l'uso), non ho fatto prove a riguardo, ma penso dovrebbe essere possibile.

Nonostante i suoi bibblici tempi nella compilazione e nel linking (ma stiamo pur sempre parlando del commodore 64, no ;-)...................) è una delle migliori scelte per ovviare alle deficienze croniche del basic v2 evitando di s-cervellarsi coll'assembly.

[Pasquale_F]

 In aggiunta al precedente messaggio, gli include vanno scritti così:

Codice: [Seleziona]

#include "stdio.h"e non così:

Codice: [Seleziona]

#include <stdio.h>

[iAN CooG]

 

In aggiunta al precedente messaggio, gli include vanno scritti così:

Codice: [Seleziona]

#include "stdio.h"e non così:

Codice: [Seleziona]

#include <stdio.h>

spiega anche il perche', altrimenti la tua affermazione e' falsa

[Pasquale_F]

 

In aggiunta al precedente messaggio, gli include vanno scritti così:

Codice: [Seleziona]

#include "stdio.h"e non così:

Codice: [Seleziona]

#include <stdio.h>

spiega anche il perche', altrimenti la tua affermazione e' falsa

Scarica il compilatore e comincia a usarlo e a scriverci qualcosa: ti accorgerai che è vera.

[4e1541]

In aggiunta al precedente messaggio, gli include vanno scritti così:

Codice: [Seleziona]

#include "stdio.h"e non così:

Codice: [Seleziona]

#include <stdio.h>

spiega anche il perche', altrimenti la tua affermazione e' falsa

Scarica il compilatore e comincia a usarlo e a scriverci qualcosa: ti accorgerai che è vera.

Non ho provato il compilatore, ma il problema dipende probabilmente da una limitazione del filesystem del c64 ripetto alle direttive standard del k&r.

con
#include "include.h"  il preprocessore carica il file dalla stessa cartella locale, solitamente gli include tra """"  identificano file scritti dall'utente.

con
il preprocessore carica il file dalla cartella di sistema indicata in una variabile d'ambiente. Gli include tra <> solitamente identificano file standard di libreria.

A parte queste differenze e' chiaro che sotto c64 tutti i file devono risiedere nella stessa directory per limitazione del DOS (a parte il caso del 1581).

ciao

p.s. ma il cc65 no?

[Pasquale_F]

 

Non ho provato il compilatore, ma il problema dipende probabilmente da una limitazione del filesystem del c64 ripetto alle direttive standard del k&r.

con
#include "include.h"  il preprocessore carica il file dalla stessa cartella locale, solitamente gli include tra """"  identificano file scritti dall'utente.

con
il preprocessore carica il file dalla cartella di sistema indicata in una variabile d'ambiente. Gli include tra <> solitamente identificano file standard di libreria.

Non accetta #include è basta; altri compilatori che ho provato invece si, direttive k&r a parte.

p.s. ma il cc65 no?

Lo sai che c'è anche un emulatore software che riproduce alla perfezione il c64 in tutte le sue parti? Cosa te ne fai di quello vero?
Buttalo nell'immondizia!

[4e1541]

 

Non ho provato il compilatore, ma il problema dipende probabilmente da una limitazione del filesystem del c64 ripetto alle direttive standard del k&r.

con
#include "include.h"  il preprocessore carica il file dalla stessa cartella locale, solitamente gli include tra """"  identificano file scritti dall'utente.

con
il preprocessore carica il file dalla cartella di sistema indicata in una variabile d'ambiente. Gli include tra <> solitamente identificano file standard di libreria.

Non accetta #include è basta; altri compilatori che ho provato invece si, direttive k&r a parte.

p.s. ma il cc65 no?

Lo sai che c'è anche un emulatore software che riproduce alla perfezione il c64 in tutte le sue parti? Cosa te ne fai di quello vero?
Buttalo nell'immondizia!

Ma tu hai compreso la logica per cui probabilmente non viene accettata la direttiva #include <> dal compilatore?

Ti sei chiesto il motivo, oppure e' cosi e basta?

Il cc65 non e' un emulatore ma un cross compiler, chiedevo solo se lo hai provato...

[Pasquale_F]

 

Ma tu hai compreso la logica per cui probabilmente non viene accettata la direttiva #include <> dal compilatore?

Ti sei chiesto il motivo, oppure e' cosi e basta?

Il C è un linguaggio "universale" creato per poter facilitare il porting di codici da un sistema ad un'altro; quindi sono stati scritti compilatori per i più svariati sistemi opertativi. Originariamente è nato sui sistemi unix e di questi ne riflette molte caratteristiche tra le quali le variabili d'ambiente (visibili e modificabili attraverso il comando "set").
Resta il fatto però che molti altri sistemi, più rozzi e meno sofisticati (come il C64), non permettono settaggi del genere, anzi, a dire il vero, non permettono originariamente neanche la suddivisione in cartelle sui dischi.

Per poter facilitare il porting del codice però, molti compilatori accettano sintassi che sui sistemi in cui girano non trovano alcun riscontro, giusto per non creare problemi.

Nel caso specifico gli sviluppatori dell'Abacus hanno però applicato alla lettere le dirrettive K&R sul richiamo degli headers, per cui:

#include "stdio.h"

e non

#include

Ovviamente chi volesse "trasferire" un codice da un sistema Minix al C64 e volesse usare il compilatore della Abacus, deve avere l'accortezza di fare delle piccole modifiche al codice stesso, in particolare al richiamo degli headers, onde evitare di incorrere in errori che puntualmente il compilatore farebbe presente.

Il cc65 non e' un emulatore ma un cross compiler, chiedevo solo se lo hai provato...

So cos'è il CC65 ma trovo molto più "sensato" usare il c64 per poter fare o scrivere programmi, se stiamo qui sempre a dire che esistono emulatori o cross compiler o cross assembler, non vedo che senso ha avuto (almeno per me)  andare a scomodare il c64 dalla soffitta e cercare di renderlo utile a qualcosa dopo quasi vent'anni, soprattutto dopo averci speso dei "soldini" sopra; tanto vale averlo buttato nella spazzatura.
 

[iAN CooG]

 finisco il mio inutile intervento, con powerc e cc64 (si, cc64 non cc65) non ci fai niente di utile, NIENTE.
cc65 di contro offre una libreria piu' standard, produce ESEGUIBILI STANDALONE e di conseguenza e' utile. Il resto e' solo un inutile esercizio di sadomasochismo.
 

[tsm_carmine]

 

Nel caso specifico gli sviluppatori dell'Abacus hanno però applicato alla lettere le dirrettive K&R sul richiamo degli headers, per cui:

#include "stdio.h"

e non

#include

Dipende solo dal fatto che (di solito) in ambiente C64 non esistono le sottodirectory, poiché le varianti "..." e <...> erano previste già nello standard K&R, sia in The C programming Language (second edition - ANSI C) che nella primissma versione (purtroppo difficile da reperire).
Cito da "Amiga - Linguaggio C" di Huckert, Kremser:

[...]
Si sta preparando una normativa ANSI
[...]
Forse avremo già notato che la maggior parte dei comandi #include contiene i nomi di file immediatamente successivi all'interno dei simboli < > (come nell'esempio precedente), ma che tuttavia alcuni di essi presentano l'indicazione del file in due versioni diverse. Quindi, per lo stesso nome di file, sono possibili ambedue le varianti:

#include
#include "xyz.h"

Nel primo caso la ricerca viene effettuata dapprima in una directory particolare, quindi in quella attuale. Nel secondo caso la sequenza di ricerca è invertita: dapprima si cerca il file xyz.h nella directory attuale.

E, visto che nel C64 (di solito) si ha solo la directory attuale, ha senso solo la variante tra " ".

[Pasquale_F]

 

finisco il mio inutile intervento

lo è questo come lo sono la maggior parte di tutti quelli che hai fatto su questo forum.

Il resto e' solo un inutile esercizio di sadomasochismo.

Di conseguenza lo è anche accedere un c64.
 

[Pasquale_F]

 

Nel caso specifico gli sviluppatori dell'Abacus hanno però applicato alla lettere le dirrettive K&R sul richiamo degli headers, per cui:

#include "stdio.h"

e non

#include

Dipende solo dal fatto che (di solito) in ambiente C64 non esistono le sottodirectory, poiché le varianti "..." e <...> erano previste già nello standard K&R, sia in The C programming Language (second edition - ANSI C) che nella primissma versione (purtroppo difficile da reperire).
Cito da "Amiga - Linguaggio C" di Huckert, Kremser:

[...]
Si sta preparando una normativa ANSI
[...]
Forse avremo già notato che la maggior parte dei comandi #include contiene i nomi di file immediatamente successivi all'interno dei simboli < > (come nell'esempio precedente), ma che tuttavia alcuni di essi presentano l'indicazione del file in due versioni diverse. Quindi, per lo stesso nome di file, sono possibili ambedue le varianti:

#include
#include "xyz.h"

Nel primo caso la ricerca viene effettuata dapprima in una directory particolare, quindi in quella attuale. Nel secondo caso la sequenza di ricerca è invertita: dapprima si cerca il file xyz.h nella directory attuale.

E, visto che nel C64 (di solito) si ha solo la directory attuale, ha senso solo la variante tra " ".

Grazie Carmine, come al solito se stato molto esplicativo.