SDCC question

[FloppySoftware]

That's right. But Z80 is clearly defined, and it's easy to know the exact function of every command down to the bit.
That's what I miss for C. I would love to do more with Small-C on Z80 computers, but it's very hard to get complete docs. So if something doesn't work, I don't even know if I don't know how to use the compiler or if the program has an error.

Have you tried MESCC (my Small-C version)?
It runs on CP/M, has some nice libraries and it's licensed under the GNU license.
FloppySoftware: MESCC / Mike's Enhanced Small C Compiler

[ervin]

@ronaldo - thanks once again.
That's a lot of very useful information.


I can see merit in both techniques... for me there is no danger in using the ASM approach, as my tables will indeed only contain consecutive  byte values (with perhaps the odd 16-bit word value).

Nonetheless, the pros/cons of each method are very interesting, and certainly something to keep in mind.

[ervin]

Wow, SDCC can be really frustrating at times!


I've spent over 4 hours(!) trying to figure out how to have an array of a struct, where the struct contains an array of a struct.
It's making my brain melt!

Anyway, I finally got it working.
I was getting "duplicate initializer" errors, and "needs curly braces" errors.
Much Googling ensued.

It makes sense now, but it hasn't been intuitive at all (and still feels like there are unnecessary extra curly braces, but compilation fails without them all).

I've got this:

Code Select Expand


typedef struct obj3d{
    i8 x;
    u8 z;
    u8 colour;
    u8 active;
} sObj3d;

const struct section{
    sObj3d obs[8];
} sSection[2]={
    {
        {
            {-8,8,3,0},
            {-8,40,3,0},
            {-8,72,3,0},
            {-8,104,3,0},
            {0,0,0,0},
            {0,0,0,0},
            {0,0,0,0},
            {0,20,0,0}
        }
    },
    {
        {
            {8,8,4,0},
            {8,40,4,0},
            {8,72,4,0},
            {8,104,4,0},
            {0,0,0,0},
            {0,0,0,0},
            {0,0,0,0},
            {0,20,0,0}
        }
    }
};


And in main.c I can access an element with something like this:

Code Select Expand


u8 myZ;
myZ=sSection[0].obs[0].z;


Finally, I have a working database structure!
In use, the benefits are obvious, as I don't need to calculate array offsets to get to a particular element, but it was very difficult getting here!

At last I can start designing the section layouts for my runner game, and make it all run from easily accessible data tables.
No doubt I'll run into more errors soon, but for now I'm pretty happy.

[AMSDOS]

True Z80 is clearly defined. But then so is C. Small-c is different to c in many ways. SDCC is a C compiler, z88dk is a small-c compiler.

Not sure how you come to that reasoning regarding Small-C, it's limited in the sense it's a scaled down version of C, does it differ so much from the Circa 1970 language used to build Unix? I haven't used SDCC to comment on it, though I was under the impression (and correct me if I'm wrong) SDCC is a further adaption of Small-C, in the same manner Small-C was adapted Jim Hendrix?

[arnoldemu]

Not sure how you come to that reasoning regarding Small-C, it's limited in the sense it's a scaled down version of C, does it differ so much from the Circa 1970 language used to build Unix? I haven't used SDCC to comment on it, though I was under the impression (and correct me if I'm wrong) SDCC is a further adaption of Small-C, in the same manner Small-C was adapted Jim Hendrix?

Modern c differs from the original C in the way the functions are defined.

In very early c you did this:

main() int argc; char *argv

in modern c it's:

main(int argc, char *argv)

Yes small-c is a cut down implementation of C, specifically so to make it easier to implement and smaller in terms of compiler size I believe.
I don't know if there is a small-c definition, I think it started as a language in Dr.Dobbs journal?

Both are fine, there are some syntax differences but generally minor (small-c may be lacking "switch"??).

[FloppySoftware]

Modern c differs from the original C in the way the functions are defined.

In very early c you did this:

main() int argc; char *argv

in modern c it's:

main(int argc, char *argv)

Yes small-c is a cut down implementation of C, specifically so to make it easier to implement and smaller in terms of compiler size I believe.
I don't know if there is a small-c definition, I think it started as a language in Dr.Dobbs journal?

Both are fine, there are some syntax differences but generally minor (small-c may be lacking "switch"??).

No, an older function definition is like this:

Code Select Expand



int strlen(string)
char *string;
{
   ...
}


There are a lot of Small-C versions, all descendant from the Ron Cain's original.

The main problem with the Small-C versions around, is that they are only related between them in their ancestor, but they don't follow a linear evolution.

That caused that some versions have structures, even floats, while other lack switch, etc.

I'm absolutely sure that Small-C is the compiler most ported to any machine / environment / cpu: there are versions for CP/M, DOS, Unix / Linux, Mac, etc., each one with its own functionalities and peculiarities.

For example, my own Small-C versión (MESCC), lacks structures, but has switch, nexted #includes, #if, #asm, redirection, malloc, etc., and, of course, can compile itself.

My Unix-like shell for CP/M (SamaruX) was written in MESCC.

Well, I do nearly all my projects in MESCC, actually.

I like Small-C. 

[AMSDOS]

Modern c differs from the original C in the way the functions are defined.

In very early c you did this:

main() int argc; char *argv

in modern c it's:

main(int argc, char *argv)

That would suggest in the earlier versions of C, variables could not be passed between functions, only declared locally.

Yes small-c is a cut down implementation of C, specifically so to make it easier to implement and smaller in terms of compiler size I believe.

Wikipedia describes Small-C as a Subset of the C Programming Language, designed for the Low-Powered Microcomputers.

I don't know if there is a small-c definition, I think it started as a language in Dr.Dobbs journal?

Ron Cain wrote it for an Intel 8080 and was published in the May 1980 Dr. Dobbs Journal.

Both are fine, there are some syntax differences but generally minor (small-c may be lacking "switch"??).

The Wikipedia site mentions Z88DK as a Compiler derived from Small-C, so I'm getting my compilers muddled up.

[FloppySoftware]

This is part of the documentation from the Small-C compiler I bought from a PD library on 3" for my Amstrad PCW:

A SUMMARY OF THE SMALL C LANGUAGE (for Version 1.7 Oct. 1985)

Introduction
Small C is a subset of the standard C language.  It was written by Ron
Cain and originally published in Dr.Dobbs Journal of Computer Calisthenics and
Orthodontia,  No.45.   The version described has been modified to generate Z80
mnemonics instead of the original 8080 ones.  A number of bug fixes,  most  of
them  sent  in  by readers of DDJ, have also been incorporated.  Several extra
features have also been  added,  many  based  on  other  enhancements  of  the
original.  This version has been developed under CP/M 2.2.  Unlike the earlier
version  in Vol 15, no attempt has been made to keep the code 8080 compatible.
The libraries have been modified in various ways since the earlier release but
since most of them will only run in RAM, there has been no  particular  effort
to optimise their length by using shorter (but often slower) Z80 instructions.
The  compiler  inputs  a  program  written  in Small C from a file and
produces a version of the program in Z80 assembler  language  mnemonics  which
can  be  assembled and run on a Z80 system.  The original run time library has
been supplemented by some additional routines which use CP/M  I/O  facilities.
The  library  is divided into modules so that routines that are not needed for
particular applications can be omitted.

...

References.
Dr. Dobbs Journal of Computer Calisthenics and Orthodontia, Box E, Menlo Park,
      CA 94025
  No. 45  (May 1980)   "A Small C Compiler for the 8080's"  by Ron Cain
    A listing in C of the 8080 compiler + notes on implementation.
    This issue also contains other articles about C.
  No. 48  (Sept. 1980) "A Runtime Library for the Small  C  Compiler" 
   by  Ron Cain -   Run time library + useful notes.
   (See also Nos. 52, 57 and 62 for bug notes by P.L.Woods, K.Bailey,
     M.Gore & B.Roehl, J.E.Hendrix)
  Nos. 81 and 82 (July, Aug. 1983) "RED - A better Screen Editor" by E.K.Ream
    A screen editor written in Small C with a number of library
    routines.
     
  There is  a later version of Small C by J.E.Hendrix in DDJ Nos.74 and 75
   but this is copyright and so presumably not in the public domain.
 
"The Small C Handbook" J.E.Hendrix  This is mainly devoted to an update
   of Hendrix's development of Small C.  No support routines given, though
   they are given in the DDJ version.
C Users Group Vol 9. This contains Mike Bernson's Small C. This is an
   8080 version and uses a special assembler which is provided. The
   original was got going via BDS C.
SIG/M Vol 149  This includes C86 adapted by Glen Fisher
SIG/M Vol 224  This contains a floating point, Z80 version of Small C.
  There is also a Z80 assembler and linker. There are some formatted
  I/O facilities. The programming constructs are those in the original
  compiler. Modifications by J.R.Van Zandt.
"A book on C" by R.E.Berry and B.A.E.Meekings. (Macmillan 1984)
   This includes a listing of 'Rat.C' which is very similar to Ron Cain's
   version but has useful cross-referrence  listings  etc.  This  reference is
   also worth examining if you want to adapt the compiler to other CPU's. It's
   also quite a good introductory low priced text on C in general.

"The C Programming Language" by B.W.Kernighan and D.M.Ritchie (Prentice-Hall)
   The standard text on C.
"The  UNIX System" by S.R Bourne. (Addison-Wesley). A superb book on UNIX with
  a chapter on C  and an appendix which defines most of the important standard
  C functions.
The C/80 compiler from Software Toolworks is an 8080 code compiler which seems
to be based on Small C but is considerably enhanced.

        John  Hill  (Nov.1983/Mar.1984/Oct 1985)

[arnoldemu]

I wasn't saying small-c or c is better.

But they are different.

small-c doesn't have some constructs compared to c, and as said, it depends on the implementation of small-c.

SDCC is meant to be full c. z88dk is small-c with some extras.

I've used both and both are good.

[Alcoholics Anonymous]

I wasn't saying small-c or c is better.

But they are different.

small-c doesn't have some constructs compared to c, and as said, it depends on the implementation of small-c.

SDCC is meant to be full c. z88dk is small-c with some extras.

I've used both and both are good.

z88dk's small-c has evolved quite a bit.  Almost all the limitations of the original small-c are gone and things like float & longs are present as well as ansi-style functions.  If sdcc is 95% compliant, z88dk is probably 85% compliant in terms of the C89 language itself.  There are a few notable drawbacks (no function prototyping and no multi-dimensional arrays) but other than that it will consume most of the same C source.  The other main difference is in the libraries:  sdcc's are minimal and written in C whereas z88dk's are much more complete and written in assembly language.

If you would like to try it, z88dk is getting ready for another release soon (<1 month, 2 months? idk).  Quite a bit has changed.  There is now a second C library aiming for a subset of C11 compliance and made compatible with sdcc.  It's also directly supporting compilation with sdcc using this library.  It's a better sdcc for the z80 as it supplies a much more complete library written in asm, takes full advantage of sdcc's new fastcall and callee linkages and supplies more peephole rules to help reduce code size.  The crts automatically take care of bss and data initialization and can generate binaries destined for execution in RAM or ROM.  (A ROM binary needs to store initialized data with the rom image and copy that into ram at startup).  Some of these gotchas are mentioned specifically in this thread.  sdcc is being used purely to translate C to asm source and then that asm source is processed to be (more) standard zilog before being consumed by z88dk's backend assembler/linker.

Documentation is being prepared now and you can read little bit about it:
http://www.z88dk.org/wiki/doku.php?id=temp:front

The cpc target is not a completely smooth port.  z88dk's libraries take full advantage of the exx set and index registers which is a problem for the cpc's interrupt routine.  To make a cpc target, on interrupt, register state would have to be set to what is expected by the rom, the rom called and on return, register state restored. Likewise for firmware calls.  In the past cpc users have complained about stability but as it turned out, it came down to use of the exx set and incompatibility with the firmware, something that was not known to the z88dk devs as they (we) are not experts on the cpc.  If that's not done you can run with interrupts disabled as long as no firmware is called.

[Alcoholics Anonymous]

I wasn't saying small-c or c is better.
But they are different.

sdcc is modern C compliant (it can do C89, C99 and some C11) but beyond that it is an optimizing compiler.  It's performing code analysis that small c is not doing and the result is almost always faster code.  It also comes with a peephole optimizer that can perform simple code analysis (it can determine if a memory location is volatile or if a register's value is dead or live, eg).

Small-C is much simpler in those two compartments.  It only makes local optimization decisions and the peephole optimizers that are typically supplied can't do any code analysis and are limited to text substitution.  That means substitutions necessarily have to be more conservative but it's not as limiting as you might think since, because the compiler only performs local code generation, you can know that registers are dead if enough of the surrounding asm text is captured in the peephole rules.

There are two great things about small-C :- one is it's possible to run on the original hw and the other is that it tends to generate small code.  If you treat the C code as glue and supply a large body of asm library routines, you can approach the speed of asm programs and still keep the binary size relatively small.  The small code generation comes from implementing many compiler actions with calls to primitives functions.  It does mean slower code however.

sdcc's optimizer still has a ways to go for the z80.  I think Philip wrote a thesis on it and implemented it in sdcc but his thesis was on 8-bit register allocation, which sdcc does very well with no question, but what I see is sdcc screwing up 16-bit code and sometimes opting for 8-bit code where 16-bit code would work better.  We try to correct some of that with peephole rules.  While sdcc can still improve further in the optimization area, it still does fairly well and is able to improve in the future, unlike small-C derived compilers.

Anyway from the experience I've had over the last 6 months, it looks like sccz80 (small-C derivative) will usually generate smaller code whereas sdcc will typically generate faster code if they have access to the same libraries.  On the z80 the best results are always had by using statics where reasonable and those are the sorts of programs I was testing with.  Things swing the other way if you write C code with lots of local variables and long parameter lists.

[AMSDOS]

z88dk's small-c has evolved quite a bit.  Almost all the limitations of the original small-c are gone and things like float & longs are present as well as ansi-style functions.  If sdcc is 95% compliant, z88dk is probably 85% compliant in terms of the C89 language itself.  There are a few notable drawbacks (no function prototyping and no multi-dimensional arrays) but other than that it will consume most of the same C source.  The other main difference is in the libraries:  sdcc's are minimal and written in C whereas z88dk's are much more complete and written in assembly language.

It's also possible to generate Z88DK code from CPC BASIC 3 files, so some degree of implementing code from Locomotive BASIC into Z88DK by just selecting the relevant output.

[ervin]

It's also possible to generate Z88DK code from CPC BASIC 3 files, so some degree of implementing code from Locomotive BASIC into Z88DK by just selecting the relevant output.

Oh, doesn't it produce ccz80 code?
(Or am I getting mixed up?)

[AMSDOS]

Oh, doesn't it produce ccz80 code?
(Or am I getting mixed up?)

Yes, you're actually correct.


But perhaps someone could write it for Z88DK. 

[Alcoholics Anonymous]

But perhaps someone could write it for Z88DK. 

lol it would certainly help to clear up the confusion.  sccz80, ccz80 it's pretty close

Stefano was doing some interesting things a while back:

http://www.z88dk.org/wiki/doku.php?id=advanced:cpmlink:programs

He found a way to export rel files from cpm and link those within z88dk.  What that means is you could use cpm compilers (basic, fortran, c) to generate a rel file and then use z88dk to compile for any z80 target.  On that page he compiled a basic program.  I think there was still some work to do on it.

[AMSDOS]

lol it would certainly help to clear up the confusion.  sccz80, ccz80 it's pretty close

Not to mention my Sprite Opcode Blues, and &CC/&88/&80 is more dilemma for me, when's the 0C compiler arriving?