SDCC Part 1 of 4 : Introducing C for the Amstrad CPC
For the two last decades, programming on Amstrad CPC was doable in BASIC or, for the most advanced stuff, using assembly language. Of course there were other languages available at the time, but they were poorly implemented (SmallC, Pascal..) and restricted to CP/M environment.
Now that cross-platform programming became mainstream, we can benefit of the power of the nowadays machines to generate Z80 code using advanced and modern compilers. Several compilers and languages are available, this article will focus on C compilers, and most especially SDCC.
The aim of these tutorials is to allow you to create, compile and test source-codes on a CPC emulator the good way. With the hope that you will be able to start development by yourself and introduce C compilers in your Amstrad CPC developments soon ! :)
Now that cross-platform programming became mainstream, we can benefit of the power of the nowadays machines to generate Z80 code using advanced and modern compilers. Several compilers and languages are available, this article will focus on C compilers, and most especially SDCC.
The aim of these tutorials is to allow you to create, compile and test source-codes on a CPC emulator the good way. With the hope that you will be able to start development by yourself and introduce C compilers in your Amstrad CPC developments soon ! :)
Is C language really a viable solution ?
At some point, you may wonder why using C for such a small system like the Amstrad CPC. I think the best answer is to look on what has been already produced using the language. Some of them are really CPU-intensive, so I guess these are good demonstrations of viability :
Games : the Mojon Twins platform games, Blue Angel 69,..
Demos : Phat, Pheelone, Phreaks, Chunky Chan,..
Utilities : HxC Floppy Emulator Manager,..
Games : the Mojon Twins platform games, Blue Angel 69,..
Demos : Phat, Pheelone, Phreaks, Chunky Chan,..
Utilities : HxC Floppy Emulator Manager,..
When targeting Amstrad CPC, you still need to use assembly language
Yeah, really. Don't expect writing a C program without a single line of assembly language. Whatever you do, you will need to use asm inline to declare your org &XXXX statements, provide faster implementations for inner loops, manage low-level stuff such as CRTC, Gate Array, etc.
Still, using C is a real improvement over classic assembly language for most of regular cases.
These articles will assume you have good knowledge of both C and assembly language.
Still, using C is a real improvement over classic assembly language for most of regular cases.
These articles will assume you have good knowledge of both C and assembly language.
Why SDCC, and not Z88dk or PhrozenC ?
PhrozenC is based on original base code of SmallC, dated from 1981. The compiler is a K&R one, meaning the syntax is clearly deprecated. Being able to run directly on Amstrad CPC machines, it does not feature code optimizations so it generates very slow, large code. Still, it gets handy to keep it for small projects (such as demos) as it allows to design a program the better way (versus a complete implementation done in assembly language).
There are also z88dk and SDCC compilers. Both of them are pure ANSI C compilers, so they fully respect the nowadays standards. It means that you can pick a source-code from Internet and adapt it to CPC with - in theory - minor modifications (those modifications being adaptations to the Amstrad CPC, being a small embedded system - so the focus would be on memory usage & system handling (video output, file management, etc)). Of course, don't expect to port Doom game tomorrow :) Both compilers are able to generate highly optimized Z80 code so it gets pretty interesting to use them.
While making Phat demo, I used z88dk. I was pretty satisfied with it ; it does the job as advertised even if you have to use some workarounds to get it working as expected - the authors coming from ZX Spectrum community, they hardcoded DI instruction usage in their default CRT startup routine which is a pretty bad in Amstrad CPC context.
Then while creating Pheelone, I started to evaluate other available C compilers. I found out at this time SDCC was clearly the best choice, it generated much smaller code compared to z88dk, the documentation was more mature and overall implementation much cleaner from what I found with z88dk. Also, the changelog of SDCC was less stressful than the z88dk one (in SDCC, they are currently adding features where z88dk people still stick with fixing critical bugs on code generation).
Of course, all these compilers are free to use so it would be so sad to discard them !
There are also z88dk and SDCC compilers. Both of them are pure ANSI C compilers, so they fully respect the nowadays standards. It means that you can pick a source-code from Internet and adapt it to CPC with - in theory - minor modifications (those modifications being adaptations to the Amstrad CPC, being a small embedded system - so the focus would be on memory usage & system handling (video output, file management, etc)). Of course, don't expect to port Doom game tomorrow :) Both compilers are able to generate highly optimized Z80 code so it gets pretty interesting to use them.
While making Phat demo, I used z88dk. I was pretty satisfied with it ; it does the job as advertised even if you have to use some workarounds to get it working as expected - the authors coming from ZX Spectrum community, they hardcoded DI instruction usage in their default CRT startup routine which is a pretty bad in Amstrad CPC context.
Then while creating Pheelone, I started to evaluate other available C compilers. I found out at this time SDCC was clearly the best choice, it generated much smaller code compared to z88dk, the documentation was more mature and overall implementation much cleaner from what I found with z88dk. Also, the changelog of SDCC was less stressful than the z88dk one (in SDCC, they are currently adding features where z88dk people still stick with fixing critical bugs on code generation).
Of course, all these compilers are free to use so it would be so sad to discard them !
Conclusion
Yep, it's already the end of this article. It did not need to be a large one.
Next time we will focus on our first build, and I'm pretty excited about this ! :)
Next time we will focus on our first build, and I'm pretty excited about this ! :)