C Programming on Amstrad (SDCC, Z88dk and CCZ80) (http://www.genesis8bit.com/index.php#c-programmation-amstrad-cpc-sdcc-z88dk-ccz80)
25 December 2011, 2:06 am
C Programming on Amstrad (SDCC, Z88dk and CCZ80)
Source: Genesis8 Amstrad Page (http://www.genesis8bit.com/index.php)
QuoteFirst,the windows C compiler SDCC v3.1.0 (http://sdcc.sourceforge.net/) targetting Z80 is out.
Not true. SDCC is not a "windows" C compiler. It's just a C compiler, and is available for multiple platforms. It's part of the repository of Ubuntu for example.
(Just thought it should be mentioned).
Quote from: mr_lou on 17:07, 25 December 11
Not true. SDCC is not a "windows" C compiler. It's just a C compiler, and is available for multiple platforms. It's part of the repository of Ubuntu for example.
Thanks, I corrected this mistake.
I didn't know we had 3 different C compilers to choose from. Never heard of CCZ80 before.
As far as I can see, SDCC seems to be the preferred choice with most CPC coders. But it would be nice to hear from experiences from people using the different compilers. (I know this has been talked about earlier, and I'd use the search if there was one, but there's no search-button anymore in the dark theme I'm using).
I've used Z88DK myself earlier with CPCRSlib and found it to be a good solution for what I needed at the time. I'm looking forward to digging deeper into SDCC with my current sMIDP2lib project though.
Anyone used CCZ80?
I know arnoldemu used Z88DK for some projects, but I don't remember how he liked it.
How strange is that? Not a single C compiler for the CPC was mentioned, and there are a lot: Small-C, Aztec-C, Arnor-C, Hitech-C, FrozenC and much more...
Quote from: TFM/FS on 10:21, 26 December 11
How strange is that? Not a single C compiler for the CPC was mentioned, and there are a lot: Small-C, Aztec-C, Arnor-C, Hitech-C, FrozenC and much more...
Yea, the title is somewhat misleading, since it's not really about C programming
on the CPC, but rather
for the CPC.
On the one hand I think it's quite amazing that todays supercomputers can be used to create machine code from C language source code including all kind of "modern" constructions.
On the other hand I always have a strange feeling when I depend on another machine to use "my" machine. The logical consequence of using a supercomputer (and yes, the PC in one, since it's CPU has roughly 100.000 times more power than the Z80 with 4 MHz) would be: Create the code on it, and also for it! Because there it will run faster.
So in a way I prefer to have it ALL on a CPC.
Funny thing is: There are some CPC users creating whole software environments on PC targetting the CPC, but the same persons refuse hardware expansions on a CPC.
Well, I'm sorry for getting offtopic here, it's X-mas, we got time ;-)
Quote from: mr_lou on 09:42, 26 December 11
I didn't know we had 3 different C compilers to choose from. Never heard of CCZ80 before.
As far as I can see, SDCC seems to be the preferred choice with most CPC coders. But it would be nice to hear from experiences from people using the different compilers. (I know this has been talked about earlier, and I'd use the search if there was one, but there's no search-button anymore in the dark theme I'm using).
I've used Z88DK myself earlier with CPCRSlib and found it to be a good solution for what I needed at the time. I'm looking forward to digging deeper into SDCC with my current sMIDP2lib project though.
Anyone used CCZ80?
I know arnoldemu used Z88DK for some projects, but I don't remember how he liked it.
I've used ccz80 a lot over the last 2 years or so.
I absolutely love it.
C-syntax, without all the faffing about with header files and other such nonsense.
And it produces fast binaries.
In-line assembler is easy to incorporate, although you have to put quotes around each machine code instruction.
eg.
LD A,1
ADD A,A
ADD A,B
would be written as
asm
{
"LD A,1",
"ADD A,A",
"ADD A,B",
}
This is initally a bit annoying, but it soon becomes second nature.
Also, it is really easy to incorporate the compiled BIN file into a DSK, or to simply load it into WinAPE via the assembler.
And (like the other compilers, I presume?) you can export the compiled machine code to an asm file. I do that all the time in order to get a base for further optimisation. Fantastic stuff.
My Chunky Pixel Collision project is being written in ccz80.
I can't imagine producing a cpc program without it.
If anyone feels like playing with ccz80 and needs help getting it going (it's not hard), I'm happy to help.
:)
@ervin, what about assembler syntax?
SDCC requires us to use ASxxxx. (Although we can have SDCC just compile into assembler, and then use NoRecess' translator before using Pasmo to compile, expect it doesn't always work).
And I think Z88DK uses Maxam syntax.
Quote from: mr_lou on 09:20, 27 December 11
@ervin, what about assembler syntax?
SDCC requires us to use ASxxxx. (Although we can have SDCC just compile into assembler, and then use NoRecess' translator before using Pasmo to compile, expect it doesn't always work).
And I think Z88DK uses Maxam syntax.
Unfortunately I am a bit clueless with differences in assembler syntax.
The only assembly code I've ever tried is within ccz80, so I don't know what other syntaxes look like. :-[
I've attached some ccz80-generated assembly code, in case that helps.
It's also worth noting that ccz80 seems to be really good regarding undocumented z80 instructions, although I haven't tried
all of them. :)
EDIT: It seems that attachments are a bit wonky on cpcwiki at the moment.
Here is a link to the example assembly code:
http://dl.dropbox.com/u/339282/dbuffer.asm (http://dl.dropbox.com/u/339282/dbuffer.asm)
Quote from: TFM/FS on 21:01, 26 December 11
Funny thing is: There are some CPC users creating whole software environments on PC targetting the CPC, but the same persons refuse hardware expansions on a CPC.
But that may change if some become very popular ;D
Quote from: fano on 18:40, 27 December 11
But that may change if some become very popular ;D
Thanks' for that X-Mas gift. It brings back hope to me :)
Quote from: mr_lou on 10:29, 26 December 11
Yea, the title is somewhat misleading, since it's not really about C programming on the CPC, but rather for the CPC.
I corrected the title and the news according to what TFM and you wrote (a few days ago).
QuoteOn the one hand I think it's quite amazing that todays supercomputers can be used to create machine code from C language source code including all kind of "modern" constructions.
On the other hand I always have a strange feeling when I depend on another machine to use "my" machine. The logical consequence of using a supercomputer (and yes, the PC in one, since it's CPU has roughly 100.000 times more power than the Z80 with 4 MHz) would be: Create the code on it, and also for it! Because there it will run faster.
So in a way I prefer to have it ALL on a CPC.
Funny thing is: There are some CPC users creating whole software environments on PC targetting the CPC, but the same persons refuse hardware expansions on a CPC.
:D
Sadly most stuff like good old CPC C compilers do have outdated interface and few of the modern commodities like copypast, automatic words, GUI debugger and so on.
Or am I wrong ?
Also you have to often save on disk (or whatever you have) and can't run a MP3 or porn while coding. :)
Anyway, now I have Hardware extensions, I hope your new FutureOS will be top notch.
when will we have Java for CPC too ?
Hi guys! I'm new about assembler programming and now I found this page and I wish to know more about C programming but on a real cpc464, is there a tape or an mp3 file containing a C compiler for the cpc...and where can I find one? Thanks for your help!
Quote from: philip on 06:45, 26 April 15
Hi guys! I'm new about assembler programming and now I found this page and I wish to know more about C programming but on a real cpc464, is there a tape or an mp3 file containing a C compiler for the cpc...and where can I find one? Thanks for your help!
Hi Phillip,
Initially I thought Hisoft C might of been made for Tape and Disc, but now it appears it's a Disc only. The Languages on offer here (SDCC, Z88DK and CCZ80) are languages you run through your Windows, Linux, MacOS(?) Box, which then compile the programs that you can run through your CPC or Emulator.
So there doesn't appear to be any C Language available on tape, which leaves you with Pascal, Forth, or some BASIC compiler. This page (http://www.cpcwiki.eu/index.php/Programming_software) lists all the Languages (which also includes the PC based ones which only create programs for CPC), any of those which include AMSOFT will most likely have a Tape.
Personally I use Hisoft Pascal 4T which exists on Tape, which has an online manual on here and have made a thread of stuff here (http://www.cpcwiki.eu/forum/programming/hisoft-pascal-4t/), though much of it is rewritten programs from BASIC type-ins and some of that 10-Liner BASIC stuff easily becomes 100 Lines of Pascal Code, but it's probably the closest thing to C like language that exists on Tape. Hisoft Pascal 4T also allows for easy Integration of Firmware, which is the BASICs of using Assembly and I've also integrated RSXs into that as well.
I haven't had much to do with Forth, there seems to be Forth (http://www.cpcwiki.eu/index.php/Forth) and Fig-Forth (http://www.cpc-power.com/index.php?page=detail&onglet=dumps&num=3173) and have only really played around with it as a System Language on a Jupiter Ace emulator, though it's supposed to be powerful language when a combination of routines are applied.
BASIC wise I'm only familiar with the Laser BASIC Compiler (http://www.cpcwiki.eu/index.php/Laser_BASIC_Compiler) which is available on Tape
Quote from: AMSDOS on 12:13, 26 April 15
Initially I thought Hisoft C might of been made for Tape and Disc, but now it appears it's a Disc only.
I know it's been ages since Phillip wrote in asking about a C Compiler for his 464, and no reply was ever made, but there seems to be evidence contrary to what I've quoted earlier...
(http://www.cpc-power.com/extra_lire_fichier.php?extra=pub&fiche=4244&slot=2&part=A&type=.jpg)
...So the burning question is where to find a Tape Copy of Hisoft C?
I don't know how usable it was or what "C" would it be.
My experience with my first PC (8086, 512KB RAM, DOS 3.0, no HDD) was that running "make" to compile a "hello world" in C required changing diskette 3 times. It was not usable without a hard disk.
Nice finding though.
Quote from: reidrac on 09:05, 27 November 15
I don't know how usable it was or what "C" would it be.
It's Hisoft C, 3rd program down under their Amstrad CPC software. This particular language was available for AMSDOS as well as CP/M. If I correctly recall, @arnoldemu (http://www.cpcwiki.eu/forum/index.php?action=profile;u=122) suggested this compiler was used once to write the Ocean game Miami Vice, if that's any indication on how usable it was, though while I've played Miami Vice, it's a very frustrating game to play. :D
Quote
My experience with my first PC (8086, 512KB RAM, DOS 3.0, no HDD) was that running "make" to compile a "hello world" in C required changing diskette 3 times. It was not usable without a hard disk.
Not Turbo C by any chance? Usually when I saw a system like that it had 2 x 5.25" drives.
Quote
Nice finding though.
This was the other Hisoft ad I initially saw. While it's clearing stating it's on Tape/Disk & CP/M, no mention regarding if it's 464 friendly, maybe it's like Advance Art Studio, which was available on Tape, though 128kb required?
EDIT: Sorry having problems uploading image! :(
Quote from: AMSDOS on 09:46, 27 November 15
It's Hisoft C, 3rd program down under their Amstrad CPC software. This particular language was available for AMSDOS as well as CP/M. If I correctly recall, @arnoldemu (http://www.cpcwiki.eu/forum/index.php?action=profile;u=122) suggested this compiler was used once to write the Ocean game Miami Vice, if that's any indication on how usable it was, though while I've played Miami Vice, it's a very frustrating game to play. :D
It mentions "C integer K&R"; don't know what that "integer" means but my experience with Kernighan & Ritchie is that... you want ANSI C :)
(EDIT: I see "with the exception of float point support", so that's the "integer" part of it)
Quote from: AMSDOS on 09:46, 27 November 15
Not Turbo C by any chance? Usually when I saw a system like that it had 2 x 5.25" drives.
Yes, I think it was Turbo C. I had only a 730K diskette drive, that was OK for GWBASIC or RMI Cobol (both had IDE + interpreter self-contained in one single program).
Quote from: AMSDOS on 09:46, 27 November 15
This was the other Hisoft ad I initially saw. While it's clearing stating it's on Tape/Disk & CP/M, no mention regarding if it's 464 friendly, maybe it's like Advance Art Studio, which was available on Tape, though 128kb required?
Yep, that "tape" is interesting. The 6128 was a great machine for development back then, but I believe it was mostly because the disk drive was amazing :)
Quote from: reidrac on 09:55, 27 November 15
It mentions "C integer K&R"; don't know what that "integer" means but my experience with Kernighan & Ritchie is that... you want ANSI C :)
Hmmm ::) Cannot get image up, be faster typing in Hisoft's Description of their C.
Quote
AMSTRAD
£34.95
tape
£39.95
[/size]disc
All our versions of C adhere very closely to the Kernighan & Ritchie definition of the language with the exception of floating-point. The Amstrad and Spectrum versions come with libraries supporting the sound and graphics of these machines (including GSX for Amstrad CPC6128 and PCW8256/8512!). Thew compilers are very fast, produce quick, compact code and come with interactive editors which make error correction a natural part of the programming process. See the reviews in this issue for details.
The integer they mention in their case means their language only supports Integer, more or less a step backwards from their earlier AMSOFT Hisoft Pascal 4T, which supports Floating Numbers, Integers, Char, but no Byte.
ANSI I understand is the implementation of standardizing C. K&R I presume means to prepare for the unexpected.
Quote
Yes, I think it was Turbo C. I had only a 730K diskette drive, that was OK for GWBASIC or RMI Cobol (both had IDE + interpreter self-contained in one single program).
I don't know much about Turbo C, and for some reason I thought I had something like 2 files for the whole thing, though that can't be right if C is based on being a collection of Library Files to compile the program, a 720Kb disk probably isn't much if compiled programs were large.
Quote
Yep, that "tape" is interesting. The 6128 was a great machine for development back then, but I believe it was mostly because the disk drive was amazing :)
Well the quote I posted above simply goes into detail about the CP/M version. ???
I think it would be nice to have a C compiler that runs on the CPC and can use the RAM expansions. There should be much more room for running optimisations.
However I've also spotted an LLVM backend for the Z80. I don't think it's completely finished, but appears to work fairly well. It would be interesting to see what sort of code a heavy duty modern C compiler can generate for the CPC. earl1k/llvm-z80 · GitHub (https://github.com/earl1k/llvm-z80)
Quote from: Munchausen on 11:32, 29 November 15
I think it would be nice to have a C compiler that runs on the CPC and can use the RAM expansions. There should be much more room for running optimisations.
Hitech C v3.09 for cp/m is actually fairly good. It supports ANSI-C, has reasonably complete libraries and the quality of code output is fairly high. The other native compilers I have seen are missing quite a lot and the code generation isn't too great. I think with Hitech C you may be able to target a generic z80 device but otherwise getting it to target something other than cp/m may be a problem. For that maybe the only reasonable alternative is to use something like mess-c that at least is being developed now for the cpc specifically.
In terms of optimizations, a native z80 compiler has no chance in comparison to the cross-compilers. Maybe you can fit all the data space you need on hard disks or floppies but compile time would make it unusable. But even without fancy optimizations you can still get reasonably good results, as hitech C shows, particularly if the library is written in assembly language. Asm libraries are more important than C code generation quality when it comes to program size and speed. With a native C compiler it's probably much more important to focus on small code generation and rely on the libraries to deliver performance.
Quote
However I've also spotted an LLVM backend for the Z80. I don't think it's completely finished, but appears to work fairly well. It would be interesting to see what sort of code a heavy duty modern C compiler can generate for the CPC. earl1k/llvm-z80 · GitHub (https://github.com/earl1k/llvm-z80)
I looked at that some time ago. It's in a very early stage and looks abandoned.
I don't think a front end generated by llvm is going to be much better than the front end in sdcc, eg. When I look at the code output from sdcc, it doesn't often do things in an unoptimal way. The problems are coming from how it does those things. I think the main problem right now is that the z80 is treated as an 8-bit processor and opportunities to do things in 16-bits are missed. Most of these problems can be fixed with peephole rules.
Have a look at a before and after here:
eilza.zip - Google Drive (https://drive.google.com/file/d/0B6XhJJ33xpOWLVlJY1REenlkV0k/view?usp=sharing)
"eliza_so2.opt" is the output generated by sdcc on its own.
"eliza_so3.opt" is the output corrected by additional peephole rules.
The resulting code quality is fairly high.
Because the z80 is treated as 8-bit sometimes code cannot be corrected.. there are times when sdcc actually reverses the endianness of numbers (eg loading a 16-bit quantity into "ED" rather than "DE") which makes it difficult to correct to 16-bit in an isolated manner because isolated changes need extra register moves to undo the reversed endiannes and that's not free.
Using only peephole rules like the above, sdcc's output was sped up 24% in the Drhystone2.1 benchmark. After the speed up, it beat Hitech C v7.50 (MSDOS cross-compiler with good reputation) by 17%. I wish I had access to IAR's compiler for comparison as that one is supposed to generate the best results.
This is an (old) synthetic benchmark that was meant to be representative of typical integer programs. Looking at the code output, the generated code wasn't bad but not as good as hand-assembly largely because of stack frame use. llvm is not going to solve that; that's up to the programmer to use statics instead of locals where it makes sense.
Quote from: AMSDOS on 10:24, 27 November 15
The integer they mention in their case means their language only supports Integer, more or less a step backwards from their earlier AMSOFT Hisoft Pascal 4T, which supports Floating Numbers, Integers, Char, but no Byte.
OTOH, very few programs need floating point :) If the implementation is only a 32-bit float, you probably can't do financial calculations with it either.
Quote
ANSI I understand is the implementation of standardizing C. K&R I presume means to prepare for the unexpected.
The first ANSI standard is C89 (or C90 if you prefer that name). This is the C most people are familiar with. Before this it was K&R C, referring to the original C and described in K&R's C book. Prototypes are not there, much of the standard library is not standard yet, and you have that weird function syntax with parameter types listed after the function and before the opening '{'. I find it quite frustrating to use and read but that's because I'm used to how nice everything is starting with C89.
Quote from: Alcoholics Anonymous on 23:14, 29 November 15
Hitech C v3.09 for cp/m is actually fairly good. It supports ANSI-C, has reasonably complete libraries and the quality of code output is fairly high. The other native compilers I have seen are missing quite a lot and the code generation isn't too great. I think with Hitech C you may be able to target a generic z80 device but otherwise getting it to target something other than cp/m may be a problem. For that maybe the only reasonable alternative is to use something like mess-c that at least is being developed now for the cpc specifically.
I noticed Phrozen C is a CPC implementation, though it's based on Small-C. Small-C itself operates under CP/M, though you're probably aware it can compile code for a number of operating systems. I guess if Hitech C produces assembly source, that is at least better than having some compiler produce some COM file.
Fair enough though I wouldn't have considered Small-C being K&R.
QuoteOTOH, very few programs need floating point
I seem to be using it a bit then in Random Number Generators & Calculating the Cosine & Sine for Drawing/Plotting a circle, do you have an integer based approach for those problems?
QuoteIf the implementation is only a 32-bit float, you probably can't do financial calculations with it either.
It's not something I've considered, even though I've got books on the topic.
QuoteThe first ANSI standard is C89 (or C90 if you prefer that name). This is the C most people are familiar with. Before this it was K&R C, referring to the original C and described in K&R's C book. Prototypes are not there, much of the standard library is not standard yet, and you have that weird function syntax with parameter types listed after the function and before the opening '{'. I find it quite frustrating to use and read but that's because I'm used to how nice everything is starting with C89.
So the original C was used to write Unix wasn't it? Or was it BCPL? I just would of thought that C would of been standardised for such a large scale project.
Quote from: AMSDOS on 07:53, 30 November 15
I seem to be using it a bit then in Random Number Generators & Calculating the Cosine & Sine for Drawing/Plotting a circle, do you have an integer based approach for those problems?
Yes, you can draw circles much faster using Bresneham integer methods and random numbers don't usually have much to do with floats when used in practice (eg. random 0..3 for direction, 10..20 for speed, 0..27 for colours etc). Most times when you use the random functions in BASIC/Pascal/Java etc you do things like x = (int)(Math.random() * 10), and for pure sine/cosine usage I find the most efficient implementation is X * sin(angle), as I've used it in assembler etc. (eg. 65536 * SIN(deg * 256 / 360)) in a table.
Quote from: Executioner on 09:26, 30 November 15
Yes, you can draw circles much faster using Bresneham integer methods and random numbers don't usually have much to do with floats when used in practice (eg. random 0..3 for direction, 10..20 for speed, 0..27 for colours etc). Most times when you use the random functions in BASIC/Pascal/Java etc you do things like x = (int)(Math.random() * 10), and for pure sine/cosine usage I find the most efficient implementation is X * sin(angle), as I've used it in assembler etc. (eg. 65536 * SIN(deg * 256 / 360)) in a table.
This looks like a Good page to look at:
Bresenham Line-Drawing Algorithm (http://www.cs.helsinki.fi/group/goa/mallinnus/lines/bresenh.html)
Though it didn't have anything about Circle Generation.
I came across some code from another forum which may help, though the original poster wasn't sure how good it was:
void filcircle(int x0,int y0,int R)
{int dx,dy,curx,cury;
for(curx=x0-R;curx<=(x0+R);curx++)
for(cury=y0-R;cury<=(y0+R);cury++)
{
dx=curx-x0;
dy=cury-y0;
if(dx*dx+dy*dy<=R*R) setpixel(curx,cury);
}
}
You can look at the Bresenha/Midpoint circle algorithm here: Midpoint circle algorithm - Wikipedia, the free encyclopedia (https://en.wikipedia.org/wiki/Midpoint_circle_algorithm)
And tables for trig is also what I would use.
@Alocoholics Anonymous those figures are interesting. It looks as though IAR is indeed hard to find. Is there an implementation of those peephole optimisations available somewhere? It would be interesting to see what you are using
Quote from: Munchausen on 11:32, 29 November 15
I think it would be nice to have a C compiler that runs on the CPC and can use the RAM expansions.
I think porting MESCC (http://www.floppysoftware.es/mescc.html) to the CPC should be very easy.
In fact, it's a CP/M native compiler, derived from Small-C, and has a nice bunch of libraries.
Then, it's posible to run it on the CPC under CP/M 2 or 3, as is.
I'm currently working in some MESCC enhancements:
- Now, you can declare and assign global variables, on the same line (as in standard C!).
- New peephole optimizer, with an easy system to modify / add / delete rules.
- New libraries: qsort, bsearch.
Those enhancements will be included in the next release of MESCC.
Quote from: AMSDOS on 07:53, 30 November 15
I noticed Phrozen C is a CPC implementation, though it's based on Small-C. Small-C itself operates under CP/M, though you're probably aware it can compile code for a number of operating systems. I guess if Hitech C produces assembly source, that is at least better than having some compiler produce some COM file.
Small-C itself doesn't implement FILEs or have a concept of file descriptors. The latter is not necessary but it's kind of expected in C because file descriptors are in the POSIX standard, which defines what makes Unix Unix. So it's easy to target another system because there's nearly nothing in it interfacing with an underlying system. Furthermore, both the small C compiler and the few asm language subroutines in the library all target an 8080 subset which means, for example, in the CPC's case you don't have to think about what is going on with the exx set or index registers when trying to make it compatible with the firmware. It makes for an easy compiler to re-target.
However I am not sure why people using small C are going all the way back to the original version by Ron Cain. Small C has a lineage and the next few versions make it ANSI-C compatible (as far as function declarations, etc), and add things like structs and floats. Phrozen C and it looks like Mess-C are both using the original Small C lacking these features. The most developed version of small C (afaik) is inside z88dk and is known as sccz80. This fills in almost all the missing C functionality with the notable exception of multi-dimensional arrays.
Hitech C for cp/m has got the file i/o goodies but it's all tied to cp/m BDOS. Not surprising since to implement FILE i/o without an underlying operating system to support it requires a lot more work (see fuzix or z88dk). So wedging anything else in there is going to require someone with the time to separate that portion out. Hitech C can in fact generate asm output and I think it can also target plain z80s without the extra cp/m goodies. The asm output expects an assembler with an understanding of areas/sections. The one supplied by Hitech is ZAS. I'm not familiar with cp/m in general so I don't know how sophisticated its native assemblers are. I did run into trouble with Hitech on cp/m when compiling large C programs (read > ~24k binaries) with the assembler running out of symbol space. But these programs were written on 16 or 32-bit machines in giant source files. Programs for Hitech C would be split up into multiple source files so that the compiler could deal with large programs in small portions.
Quote
(float) I seem to be using it a bit then in Random Number Generators & Calculating the Cosine & Sine for Drawing/Plotting a circle, do you have an integer based approach for those problems?
As mentioned, graphics primitives are usually implemented in fixed point. The Bresenham line drawing algorithm, eg, effectively uses fixed point by carrying a fraction that gets the slope added in each iteration that must exceed one before changing pixel coordinate.
There are fixed point implementations of sin, cos and other common functions. The trig functions are usually done by table look-up. Fixed point is just a fancy name for integer with an implied binary point so multiplication, division, addition and subtraction use the usual integer subroutines but multiply and divide might get special subroutines to preserve the max number of bits defined in the integer and fraction part of the fixed point number.
Quote
(32-bit floats and financial calculations)
It's not something I've considered, even though I've got books on the topic.
When you start doing time-value of money calculations that involve exponentiation and logarithms the error starts to be measured in cents and can creep into dollars if the float package is weak. But even before that you can't represent decimal fractions exactly in binary. So trying to enter 10 cents as 0.1 dollars you end up with a binary fraction that extends indefinitely. If you don't have enough mantissa bits, rounding can lead to errors in the cents even with simple math operations. I'm not an expert but at least before the arrival of modern float processors, I think all financial data was stored as integers (dollars plus cents) and they may have done computations in BCD.
Incidentally, in z88dk there are two float packages and both are 48-bit (40 bit mantissa). It happens to be the max size the z80 can keep in registers. The first is called genmath which I think comes from Jimi Hendrix's small C derivative but it's been changed somewhat. The second is called math48 and it's in the development portion of z88dk that we've interfaced to both sdcc and sccz80. You may be interested to know that math48 is (I believe) the float package used in Turbo Pascal. We've added things to it but I quite like it -- it's very easy to program in assembly language.
Before harward floating point was commonplace there was a program in the 80s called "paranoia.c" that would test the quality of the floating point implementation. It's hard to compile with most compilers on the z80 but I managed to compile it on the sdcc/z88dk combination using math48. It did identify some weaknesses which eventually I will address but for math48 (and TP's float implementation) it seems some transcendental functions are not as accurate as the 40-bit mantissa allows. Probably not enough terms in the series used.
Quote
So the original C was used to write Unix wasn't it? Or was it BCPL? I just would of thought that C would of been standardised for such a large scale project.
Well C was developed to implement Unix and the result at the end was called K&R C as K&R wrote a book to document it. That was the standard and described the one and only version of C at the time. But it continued to evolve and as it was ported to other platforms, non-portable functions were added by vendors to accommodate special features of the hardware. C was losing its portability so that's why an ANSI committee was put together to brand a de-facto ANSI-C. Most of it was probably implemented by most C vendors prior to publication of the standard but that first standard is known as C89 or C90. After that there's C95, C99, C11 but most of what people understand as C is C89/C90.
Small C was originally written in 1979/1980 so it's based on K&R C but is not fully compliant with K&R C. Finding a native ANSI-C implementation for the z80 is a taller order since the ANSI standard was not adopted until 1989 which puts this toward the twilight of the z80's existence. Hitech-C for cp/m is a fortunate find. For other examples you have to look at the commercial vendors who sold z80 C for embedded systems and those are Hitech (again), IAR, Avocet, SoftTools and a few others, and the current open source projects (sdcc, z88dk).
Quote from: AMSDOS on 07:53, 30 November 15
I seem to be using it a bit then in Random Number Generators & Calculating the Cosine & Sine for Drawing/Plotting a circle, do you have an integer based approach for those problems?
Have a look (from my XPCW graphic functions for the PCW):
/* Draw a circle in the current draw mode
--------------------------------------
*/
DrawCircle(x0, y0, radius)
int x0, y0, radius;
{
int x, xh;
int y, yh;
int decision;
x = radius;
y = 0;
decision = 1 - x;
while(x >= y) {
/* The PCW pixels are double in high */
xh = x >> 1; /* xh = x / 2 */
yh = y >> 1; /* yh = y / 2 */
/**
DrawPixel( x + x0, y + y0);
DrawPixel( y + x0, x + y0);
DrawPixel(-x + x0, y + y0);
DrawPixel(-y + x0, x + y0);
DrawPixel(-x + x0, -y + y0);
DrawPixel(-y + x0, -x + y0);
DrawPixel( x + x0, -y + y0);
DrawPixel( y + x0, -x + y0);
**/
DrawPixel( x + x0, yh + y0);
DrawPixel( y + x0, xh + y0);
DrawPixel(-x + x0, yh + y0);
DrawPixel(-y + x0, xh + y0);
DrawPixel(-x + x0, -yh + y0);
DrawPixel(-y + x0, -xh + y0);
DrawPixel( x + x0, -yh + y0);
DrawPixel( y + x0, -xh + y0);
y++;
if(decision <= 0) {
decision += 2 * y + 1;
}
else {
x--;
decision += 2 * (y - x) + 1;
}
}
}
Quote from: Munchausen on 11:36, 30 November 15
@Alocoholics Anonymous those figures are interesting. It looks as though IAR is indeed hard to find.
Hitech's z80 compilers are gone too. What happened with them is they were bought by Microchip who promptly discontinued Hitech compilers that did not target Microchip processors.
With IAR it looks like they've just dropped the z80 from their lineup and there doesn't seem to be a way to get hold of IAR C for the z80 anymore.
I think Zilog's own C compiler only targets later generations (the ez80 and z380, etc).
Quote
Is there an implementation of those peephole optimisations available somewhere? It would be interesting to see what you are using
Yes you can try it yourself:
http://z88dk.cvs.sourceforge.net/viewvc/z88dk/z88dk/libsrc/_DEVELOPMENT/sdcc_peeph.3 (http://z88dk.cvs.sourceforge.net/viewvc/z88dk/z88dk/libsrc/_DEVELOPMENT/sdcc_peeph.3)
There are about 400 new rules there. This is still a work in progress, keep in mind. It started with a little messing around before I knew how things worked and contains some experimentation in the middle. So there are many examples of how not to write peephole rules mixed in with the good.
I use it through z88dk but I think you can use it with sdcc directly like this:
sdcc -mz80 [-S --no-c-code-in-asm] --reserve-regs-iy --max-allocs-per-node200000 test.c --no-peep --peep-file sdcc_peeph.3
The options in square brackets are for generating an asm file only. "reserve-regs-iy" stops sdcc from using the iy register which gives the peephole rules more opportunites to improve the code. The rules were written with high max-allocs-per-node active and without that some rules may not be possible to apply.
Quote from: FloppySoftware on 20:20, 30 November 15
Have a look (from my XPCW graphic functions for the PCW):
/* Draw a circle in the current draw mode
--------------------------------------
*/
DrawCircle(x0, y0, radius)
int x0, y0, radius;
{
int x, xh;
int y, yh;
int decision;
x = radius;
y = 0;
decision = 1 - x;
while(x >= y) {
/* The PCW pixels are double in high */
xh = x >> 1; /* xh = x / 2 */
yh = y >> 1; /* yh = y / 2 */
/**
DrawPixel( x + x0, y + y0);
DrawPixel( y + x0, x + y0);
DrawPixel(-x + x0, y + y0);
DrawPixel(-y + x0, x + y0);
DrawPixel(-x + x0, -y + y0);
DrawPixel(-y + x0, -x + y0);
DrawPixel( x + x0, -y + y0);
DrawPixel( y + x0, -x + y0);
**/
DrawPixel( x + x0, yh + y0);
DrawPixel( y + x0, xh + y0);
DrawPixel(-x + x0, yh + y0);
DrawPixel(-y + x0, xh + y0);
DrawPixel(-x + x0, -yh + y0);
DrawPixel(-y + x0, -xh + y0);
DrawPixel( x + x0, -yh + y0);
DrawPixel( y + x0, -xh + y0);
y++;
if(decision <= 0) {
decision += 2 * y + 1;
}
else {
x--;
decision += 2 * (y - x) + 1;
}
}
}
Yes, this code looks similar to the one in the Midpoint Circle Algorithm article on Wikipedia that @Munchausen (http://www.cpcwiki.eu/forum/index.php?action=profile;u=792) posted, though I'll have a look at this code, at the moment I've written a BASIC & Pascal which I'll post in due course in another thread to stop hijacking this thread.
Quote from: Executioner on 09:26, 30 November 15
Yes, you can draw circles much faster using Bresneham integer methods and random numbers don't usually have much to do with floats when used in practice (eg. random 0..3 for direction, 10..20 for speed, 0..27 for colours etc). Most times when you use the random functions in BASIC/Pascal/Java etc you do things like x = (int)(Math.random() * 10), and for pure sine/cosine usage I find the most efficient implementation is X * sin(angle), as I've used it in assembler etc. (eg. 65536 * SIN(deg * 256 / 360)) in a table.
Regarding Random Numbers, I understand the logic behind producing those results, I was referring to producing a Random Number Generator.
I made a Random Number Generator (http://www.cpcwiki.eu/forum/programming/hisoft-pascal-4t/msg62983/#msg62983) a couple of years back in Hisoft Pascal using Integers, which lead to Skewed Results. Another attempt (http://www.cpcwiki.eu/forum/programming/hisoft-pascal-4t/msg62998/#msg62998) shortly after was a lot better and using a Real to store a result, though still somewhat frowned at for using 2 Divides. I managed to get that down to one Divide by Dividing Range with 32767 (MAXINT) to get my Real Result and then times Seed with that Result to get a value somewhere in the Range I specified. I've since found another Random Number Generator in Pascal, though it's also using Real for Returning a Random Result. So on one hand it's good I came up with something which produces values within a set range, though to write it had to work with Real Numbers. I should point out that I had to do that because while Hisoft Pascal has a RANDOM(num) function, it's nature is to return a Random Seed (between 0 and 32767), and that only happens when num=0, so a RANDOM(1) for instance doesn't return numbers between 0 & 1, only 1's and seems to be the trend with any number in that spot (except 0).