// =============================================================================
// AstroFury: A C-Zero Language Showcase
//
// This file demonstrates the features of the C-Zero language by implementing
// a simple, hypothetical retro space shooter game. It is intended to be used
// as a comprehensive test case for a C-Zero parser and compiler.
// =============================================================================
// 1. Module System: Every file starts with a module declaration.
// This replaces C's header files.
module astrofury;
// We can import other modules. The compiler/linker is responsible for finding them.
// These are hypothetical modules representing a simple standard library.
import system::video;
import system::input;
import system::rng;
import system::math;
// =============================================================================
// 2. Constants and Compile-Time Features
// =============================================================================
// 'readonly' creates a true, type-safe constant, replacing `#define`.
// The compiler can place this data in ROM.
exported readonly uint16 SCREEN_WIDTH = 320;
exported readonly uint16 SCREEN_HEIGHT = 200;
// 'compile_if' provides structured, safe conditional compilation.
// This replaces C's `#if`/`#endif`.
internal readonly bool DEBUG_MODE = true;
compile_if (DEBUG_MODE == true) {
// This function will only exist in debug builds.
external void log_message(string msg);
}
// =============================================================================
// 3. Data Structures: Enums, Structs, Bitfields, and Unions
// =============================================================================
// 'enum' with an explicit underlying type for precise memory layout.
exported enum GameState : uint8 {
TITLE_SCREEN,
PLAYING,
GAME_OVER
}
// Another enum, this time for identifying entity types.
enum EntityType : uint8 {
PLAYER,
ENEMY_FIGHTER,
ENEMY_BOMBER,
PLAYER_BULLET,
ENEMY_BULLET
}
// 'struct' with public/private access modifiers and bitfields.
// The 'bits' block has an explicit packing order defined by the platform config.
struct StatusFlags {
public:
bits {
uint8 active : 1; // Is this entity currently in use?
uint8 shielded : 1; // Is it shielded from damage?
uint8 exploding : 1; // Is it in an exploding state?
uint8 _reserved : 5; // Reserved for future use.
}
}
// A base struct for all game objects, demonstrating composition.
struct EntityBase {
public:
EntityType type;
StatusFlags flags;
fixed x, y; // Position using platform-defined fixed-point math.
fixed dx, dy; // Velocity.
private:
uint16 internal_id; // Private members are only accessible by methods of EntityBase.
}
// A struct for the player. It uses the 'base' keyword for composition.
// This is a zero-cost abstraction for code reuse.
struct Player {
public:
base EntityBase entity; // 'base' must be the first member.
uint8 health;
uint16 score;
private:
uint8 lives;
}
// A struct for enemies.
struct Enemy {
public:
base EntityBase entity;
uint8 hit_points;
uint16 despawn_timer;
}
// A simple struct for bullets.
struct Bullet {
public:
base EntityBase entity;
uint8 time_to_live;
}
// 4. Tagged Unions: A core feature for safe polymorphism.
// This union can hold any one of our game objects. The compiler tracks the
// active variant, preventing unsafe access.
union GameObject {
PlayerObject { Player p; };
EnemyObject { Enemy e; };
BulletObject { Bullet b; };
Empty { }; // An empty variant for unused slots.
}
// =============================================================================
// 5. Globals and Hardware Access
// =============================================================================
// 'internal' is the default visibility, replacing C's `static` at file scope.
internal GameState current_state;
// 'preserve' creates a local variable that retains its value across function calls,
// replacing C's `static` inside a function.
internal uint16 generate_id(void) {
preserve uint16 next_id = 0;
next_id = next_id + 1;
return next_id;
}
// 'hardware' qualifier indicates a variable can change at any time,
// replacing C's `volatile`. Accesses to it will not be optimized away.
// Attributes are specified at the end of the declaration.
hardware uint8 VSYNC_COUNTER @(address:0xD011); // Hypothetical VSync register.
// 'fastmem' is a platform-agnostic way to request allocation in a special
// high-speed memory region (e.g., ZP on 6502).
fastmem GameObject game_objects[32];
// =============================================================================
// 6. Functions, Methods, and ABI Control
// =============================================================================
// 'external' declares a function defined elsewhere (e.g., in ROM or assembly).
// This showcases the powerful ABI control features of C-Zero.
// This function uses a named ABI from the platform config file.
external void clear_screen(uint8 color) @(abi:"fastcall");
// This function demonstrates per-parameter location specifiers.
// This syntax remains correct according to the spec.
external void draw_sprite(uint8(register:A) sprite_id, uint16(stack) x, uint16(stack) y);
// Here we use the short aliases for location specifiers.
// (A) is short for (register:A), (@0x8000) for (address:0x8000), etc.
external void set_palette(uint8(A) index, ptr uint8(@0x8000) color_data);
// An 'interrupt' function. The compiler will auto-generate code to save/restore
// all registers and use a special "return from interrupt" instruction.
interrupt void nmi_handler(void) {
// Handle a non-maskable interrupt, e.g., for music playback.
asm {
// Inline assembly is possible for ultimate low-level control.
// The exact syntax would be platform-specific.
"PLAY_MUSIC_TICK"
}
}
// A method "attached" to the Player struct using ':'.
// The 'self' pointer is implicitly available.
void Player:take_damage(uint8 amount) {
if (self.entity.flags.shielded == 1) {
return;
}
if (self.health > amount) {
self.health = self.health - amount;
} else {
self.health = 0;
self.lives = self.lives - 1;
// ... trigger explosion ...
}
}
// A 'readonly' method guarantees it will not modify 'self'.
// The compiler enforces this.
uint16 Player:get_score(void) readonly {
return self.score;
}
// A function using a pass-by-reference parameter with the 'ref' keyword.
// This function can modify the original variable passed to it.
void increase_score(ref uint16 score, uint16 amount) {
score = score + amount; // 'score' is used directly, no '*' needed.
}
// =============================================================================
// 7. Function Pointers
// =============================================================================
// Forward declarations for AI functions.
internal void ai_fighter(ref Enemy e);
internal void ai_bomber(ref Enemy e);
// A function pointer declared using the safe, list-based form.
// The compiler knows all possible targets, enabling deep analysis.
func_ptr(ai_fighter, ai_bomber) enemy_ai_behavior;
// A function pointer using the signature-based form for more flexibility.
// The compiler would warn that it cannot guarantee perfect safety here.
func_ptr(void(ref Enemy)) generic_ai_ptr;
// =============================================================================
// 8. Control Flow and Expressions
// =============================================================================
internal void update_game(void) {
// 'foreach' with 'ref' provides modifiable, zero-copy access to elements.
foreach (ref GameObject go : game_objects) {
// The vastly improved 'switch' statement is the primary way to handle
// tagged unions. It's safe and requires no breaks by default.
switch (go) {
case PlayerObject as po:
// Handle player input
if (input::is_joy_down(0, input::UP)) {
po.p.entity.y = po.p.entity.y - (1.5 as fixed);
}
increase_score(&po.p.score, 1); // Call site for 'ref' requires '&'
break; // We still need breaks to exit the switch
case EnemyObject as eo:
// Assign and call a function pointer.
if (eo.e.entity.type == ENEMY_FIGHTER) {
enemy_ai_behavior = &ai_fighter;
} else {
enemy_ai_behavior = &ai_bomber;
}
enemy_ai_behavior(&eo.e);
break;
case BulletObject as bo:
bo.b.entity.y = bo.b.entity.y - (4.0 as fixed);
if (bo.b.time_to_live == 0) {
bo.b.entity.flags.active = 0;
} else {
bo.b.time_to_live = bo.b.time_to_live - 1;
}
break;
case Empty:
// This case is for empty slots, do nothing.
break; // Explicit break
}
}
// 'switch' with ranges and explicit 'fallthrough'.
uint8 score_category = get_player().get_score() / 1000;
switch (score_category) {
case 0:
// ...
break;
case 1 .. 5:
// "Rookie" rank
log_message("Player is a Rookie");
fallthrough; // Explicit fallthrough to the next case
case 6 .. 10:
// "Veteran" rank
log_message("Player is a Veteran");
break;
default:
log_message("Player is an Ace!");
break;
}
}
// =============================================================================
// 9. Casting and Optimization Control
// =============================================================================
internal void render_frame(void) {
clear_screen(0x01); // Blue background
// 9a. Casting
// 'foreach' with 'readonly ref' provides guaranteed read-only, zero-copy access.
// This is the most efficient and safe way to iterate when not modifying elements.
foreach (readonly ref GameObject go : game_objects) {
switch (go) {
case PlayerObject as po:
draw_sprite(0, po.p.entity.x as uint16, po.p.entity.y as uint16);
break;
case EnemyObject as eo:
// Assuming enemies have a different sprite ID, e.g., 1
draw_sprite(1, eo.e.entity.x as uint16, eo.e.entity.y as uint16);
break;
case BulletObject as bo:
// Assuming bullets have a different sprite ID, e.g., 2
draw_sprite(2, bo.b.entity.x as uint16, bo.b.entity.y as uint16);
break;
// No need for an 'Empty' case, as there's nothing to draw.
}
}
// An example of a dangerous, but sometimes necessary, cast.
// 'transmute' is used to reinterpret a raw integer address as a pointer.
// The keyword is intentionally loud to signal risk.
ptr Player p_hw = transmute(ptr Player, 0xC000);
p_hw.score = 9999; // Directly manipulate memory at 0xC000.
// 9b. Optimization Control
// The 'unoptimized' block is critical for timing-sensitive operations.
// The compiler is forbidden from reordering instructions inside this block.
unoptimized {
// Wait for the start of the vertical blank.
uint8 start_vsync = VSYNC_COUNTER;
while (start_vsync == VSYNC_COUNTER) {
// This busy-wait loop will not be optimized away.
}
}
// ... swap screen buffers ...
}
// =============================================================================
// 10. Main Application Entry Point
// =============================================================================
exported int16 main(void) {
current_state = GameState.TITLE_SCREEN;
while (true) {
switch (current_state) {
case TITLE_SCREEN:
// ... show title ...
if (input::is_joy_pressed(0, input::FIRE)) {
current_state = GameState.PLAYING;
}
break;
case PLAYING:
update_game();
render_frame();
break;
case GAME_OVER:
// ... show game over screen ...
break;
}
}
return 0;
}
robinHood (./5244) :Cast "safe"
intéressant sur les switch, que réfère le "as" ?
robinHood (./5244) :
preserve et hardware c'est de la sémantique
robinHood (./5244) :
bits est sympa, change t'il l'ordre seul suivant l'architecture ?
robinHood (./5244) :
pourquoi pas mettre des soupçons de classes dans les structures, mais alors les fonctions sont externes à la déclaration ?
struct foo
{
private:
int8 bar;
}
int8 foo:get()
{
return self->bar;
}
void foo:set(int8 v)
{
self->bar = v;
}
[...]
foo a;
a:set(42);
Uther (./5245) :Oui, j'ai defini le language, je suis en train de travailler sur le parser pour l'instant.
C'est un langage que tu as fait toi même ?
Uther (./5245) :Apres je ne cherche pas a forcer qui que ce soit a l'utiliser, chacun ses preferences, perso le coté "zero overhead" et ABI sont les parties les plus importantes, ce language en theorie peux etre utilisé avec le 6502 car il peux cibler une machine avec aucune pile (ou presque) et quand c'est utilisé ainsi il y a bien sur des restrictions, il peux aussi en theorie supporter les pointeurs type far/near qu'on trouve avec le x86, mais tout ca sera lié a l'implementation du backend.
Je suis pas sur que je l'utiliserai, le Rust couvrant plus ou moins toutes les fonctionnalités (à part l'ABI custom qui est un besoin que je n'ai pas) et en offrant d'autres en plus. De plus il commence a avoir un écosystème conséquent ce qui est plus rassurant pour une utilisation pro. Mais je comprend tout a fait l'envie de rester sur un scope de fonctionnalité plus limité que Rust et avec moins de contraintes.
uninitialized int8 array[128];
char c = 42;
if (foo) bar();
int8 foo:get()
{
return self->bar;
}
int8 foo_get(foo *self)
{
return self->bar;
}
a:set(42);
->
foo_set(&a, 42);
Globalement la syntaxe est claire. On ressent bien l'envie de faire un langage proche du C dans l'idée mais sans les lourdeurs liées à l'historique et avec des fonctionnalités très bas niveau qui ne paraissent pas bricolées.
Ce qui est vraiment cool et qui manque au C :
- Modules : bien sûr c'est un point indispensable a corriger en C
- les tagged union : depuis que j'ai découvert Rust c'est la fonctionnalité qui me manque le plus dans d'autre langages
- types de base de taille clairement définie
- visibilité
- méthodes associées
- foreach
- switch avancé
Ce dont je suis pas fan :
- forward declaration : plus aucun langage moderne ne fonctionne comme ça.
- compile_if : c'est perturbant de déclarer dans ce qui ressemble à un bloc classique des éléments qui seront visibles en dehors
- la syntaxe de déclaration des tableau à la C, avec les crochets coté variable.
Ce qui a l'air intéressant mais dont je crains que ça pose beaucoup de problème à mettre en oeuvre :
- ABI custom
- L'assembleur inline nécessite généralement pas mal d'info supplémentaires pour bien s'intégrer au code
Ce que j'ai pas parfaitement compris:
- l'intéret du mot clé "base" ne me parait pas clairement expliqué. Est-ce ça signifie que l'on pourra accéder directement aux champs de l'objet contenu ?
- pour le switch, tu dis "It's safe and requires no breaks by default." mais tu utilises des break partout.
Remarques diverses en vrac :
- readonly similaire à constexpr qui est enfin arrivé dans C23
- y a il une raison de ne pas avoir fusionné completement les concepts de enum / tagged union comme en Rust ?
- on dirait que tu utilise toujours des bloc même si il n'y a qu'une instruction. C'est forcé par le langage ? Si oui c'est très bien, mais du coup, pas besoin de garder les parentèses autour des conditions des if, while, switch ,...
robinHood (./5255) :Il n'y a malheureusement pas que les stagiaires qui déclenchent des UB. Ca arrive tous les jours à des gens très compétents.
certes ça peut arriver à tout le monde mais taper une case trop loin sur un pointeur c'est généralement un truc de stagiaire ...
avoir un langage plus blindé accrédite encore plus le fait de coder en permanence les choses pour avant hier au lieu de prendre le temps nécessaire
robinHood (./5258) :On peut connaître le piège et quand même tomber dedans, s'il est particulièrement bien caché ou si on manque exceptionnellement d'attention, ce qui peut arriver à tout le monde même aux meilleurs. Le nombre de faille de sécurité qui sont découvertes tous les jours, y compris dans des logiciels sérieux niveau sécurité, en est la preuve éclatante.
je dis juste que c'est un classique, devant donc être l'objet d'une attention particulière d'un dev aguerri, on connaît les pièges ..
robinHood (./5258) :Personne ne dit qu'il faut absolument réécrire tout le C existant en urgence.
est ce que ça mérite une obligation de changer de langage car "ça peut arriver" ? pas à mes yeux.
robinHood (./5264) :Je ne voulais pas dire que ça arrive à tout le monde plusieurs fois par jours, mais que des failles de sécurité liées à ça sont découvertes tous les jours dans les logiciels les plus sérieux sur la sécurité, donc ça n'est clairement pas qu'une affaire de débutant.
mais c'est rare, non ce n'est pas tous les jours, "généralement" ton programme plante direct, et tu dois tester ton code
si c'est ultra planqué c'est aussi peut être que la structure n'est pas assez simple ou lisible
robinHood (./5264) :Ca dépend peut-être des sociétés, mais je peux te dire que c'est pas du tout ce que je constate. J'ai vu beaucoup plus de projets Java avec des politiques de qualité sérieuse que des project C ou C++.
non c'est l'inverse, ce n'est pas le C qui à plus de temps c'est l'autre qui en aura moins "le langage est safe, donc bat lec code deux fois plus vite"
robinHood (./5264) :Au risque de me répéter : Personne ne dit qu'il faut absolument réécrire tout le C existant en urgence. Juste qu'il faut bien être conscient des risques et surtout ne pas dire : "Nous on est bons, ça ne nous concerne pas."
la trisomie arrive => go le 100% éprouvette
planter ton c15 au bout de 8 ans arrive => go 100% voiture autonome
les dépassement de tampon arrivent => go interdire le C et tout réécrire
robinHood (./5264) :Encore une fois on n'impose rien a personne, on dit juste qu'il faut être conscient des problèmes potentiels.
c'est juste qu'en réalité en voulant interdire les pointeurs vous attaquez frontalement ma méthode personnelle de dev (et vous enlevez le fun absolu)
généralement je n'utilise pas de for ni de variable intermédiaire, je calcule les adresses de fin et fais des while, partout, bref calculer la fin d'un buffer c'est mon quotidien
robinHood (./5264) :On parle du langage parce qu'on est sur le sujet des langages, mais bien sur que ce n'est qu'un élément parmi d'autres. Et encore une fois on ne dit pas de mettre tout le C existant à la poubelle.
on dirait que le langage est le graal et va vous éviter tous les bugs du monde, vous faites la révolution et foutez à la poubelle la référence absolue depuis 60 ans juste pour un buffer overflow de temps en temps
Uther (./5262) :A vrai dire c'est une erreur dans le code presenté ici. Tu peux le faire, le language ne l'interdit pas, mais ce n'est pas utile non plus. Le seul cas ou c'est indispensable c'est pour des API externes.
Voila ma petite revue rapide de ce que tu nous a présenté :Globalement la syntaxe est claire. On ressent bien l'envie de faire un langage proche du C dans l'idée mais sans les lourdeurs liées à l'historique et avec des fonctionnalités très bas niveau qui ne paraissent pas bricolées.
Ce qui est vraiment cool et qui manque au C :
- Modules : bien sûr c'est un point indispensable a corriger en C
- les tagged union : depuis que j'ai découvert Rust c'est la fonctionnalité qui me manque le plus dans d'autre langages
- types de base de taille clairement définie
- visibilité
- méthodes associées
- foreach
- switch avancé
Ce dont je suis pas fan :
- forward declaration : plus aucun langage moderne ne fonctionne comme ça.
Uther (./5262) :Il n'y a pas de preprocesseur, c'est un mot clef comme un autre.
- compile_if : c'est perturbant de déclarer dans ce qui ressemble à un bloc classique des des éléments qui seront visibles en dehors
Uther (./5262) :?
- la syntaxe de déclaration des tableau à la C, avec les crochets coté variable.
Uther (./5262) :C'est optionel, et c'est surtout pour pouvoir s'interfacer avec de l'existant, par exemple sur une machine pouvoir taper dans la ROM, ou, et surtout ou, le code original est en assembleur, l'ABI est souvent tordue.
Ce qui a l'air intéressant mais dont je crains que ça pose beaucoup de problème à mettre en oeuvre :
- ABI custom
Uther (./5262) :A quoi penses tu? Si tu pense a la syntax de GCC, c'est GCC qui est tordu. Avoir une visibilite sur les variables et autre fonction est deja pas mal je pense.
- L'assembleur inline nécessite généralement pas mal d'info supplémentaires pour bien s'intégrer au code
Uther (./5262) :
Ce que j'ai pas parfaitement compris:
- l'intéret du mot clé "base" ne me parait pas clairement expliqué. Est-ce ça signifie que l'on pourra accéder directement aux champs de l'objet contenu ?
struct Entity {
[...]
};
struct Player {
base Entity entity;
[...]
};
struct Cat {
base Entity entity;
[...]
};
struct Dog {
base Entity entity;
[...]
};
Player Cat:as_Player() readonly
{
// retourner un "Player" valid avec les donnée de la structure Cat courante
}
// Valide:
Entity e = Player as Entity;
// Valide avec la methode "as_Player":
Player p = Cat as Player;
// Mais Dog n'a pas de as_Player donc ceci est invalide:
Player p2 = Dog as Player;
Uther (./5262) :A vrai dire c'est plus un moins un erreur sur le commentaire.
- pour le switch, tu dis "It's safe and requires no breaks by default." mais tu utilises des break partout.
Uther (./5262) :Pour moi ce sont deux choses differentes, un est juste une enumeration de valeurs avec un nom associe, l'autre est contiens de maniere normal des donnée.
Remarques diverses en vrac :
- readonly similaire à constexpr qui est enfin arrivé dans C23
- y a il une raison de ne pas avoir fusionné completement les concepts de enum / tagged union comme en Rust ?
Uther (./5262) :Les {} sont forcé par le language en effet.
- on dirait que tu utilise toujours des bloc même si il n'y a qu'une instruction. C'est forcé par le langage ? Si oui c'est très bien, mais du coup, pas besoin de garder les parentèses autour des conditions des if, while, switch ,...
Godzil (./28) :Je pense qu'une syntaxe de type attribut ferait le boulot. Quelque chose du genre : conditional(DEBUG_MODE) void log_message(string msg)
C'est un equivalent de #ifdef X / #else / #endif et je ne suis pas vraiment sur de comment faire autrement, mais si tu as des idees je prends. Je ne suis pas fan de la compilation conditionelle, mais il y a des cas ou ca reste utile.
Godzil (./28) :Je n'ai pas de soucis avec la syntaxe d'indexation, je parlais de la déclaration. La fait d'etre un tableau est une propriété du type pas de la variable elle même.
int8 tableau[42] ? Ou l'acces a la variable tableau[x] = 0
Godzil (./28) :Je suis pas un expert de l'ASM et encore moins de son intégration avec d'autre langage. Mais si GCC s'est embeté avec un syntaxe si lourde, c'est pas par plaisir. Les compilateur avancés ont besoin d'avoir des informations sur les effets de bord. J'ai suivi de loin l'introduction de la fonctionnalité en Rust et ça a été compliqué. Peut être que ton langage est suffisamment simple pour que ça ne pose pas de soucis, mais i tu veux utiliser LLVM, je pense que tu vas avoir besoin de ce genre d'info.
A quoi penses tu? Si tu pense a la syntax de GCC, c'est GCC qui est tordu. Avoir une visibilite sur les variables et autre fonction est deja pas mal je pense.
Godzil (./28) :A vrai dire c'est plus un moins un erreur sur le commentaire.Tout l’intérêt du break dans le switch et d'éviter le passage d'une case à l'autre. Si ça n'est pas possible, c'est juste trompeur. Si tu tiens a avoir une démarcation claire du début et de la fin d'un case, des crochets me paraissent plus adaptés que ":" et "break" qui sont un héritage du goto.
Break est implicite, mais ca reste une bonne chose que de l’écrire.
Godzil (./28) :Je remontais juste ça, car je sais qu'en Rust il les avaient laissé au début quand ils ont rendu les blocs obligatoires, avant de se rendre compte qu'il ne servaient plus a rien et de les enlever sans regret.
Quand aux (), c'est un des points de python que je n'aime pas, et encore une fois c'est inspiré du C, et c'est la logique de l'utiliser en C, ca ne *me* pose pas de probleme, c'est une question de gout comme souvent j'imagine, mais perso ca permet de marquer explicitement la valeur a tester