From: MagerValp (MagerValp_at_cling.gu.se)
Date: 2001-01-23 23:25:20
Figured you folks wouldn't mind if I posted the "translation" here.
------------------------------------------------------------------------
appeared in: GO64! - the magazine for Computerfreaks, output 9/2000
cc65: A c-Crosscompiler for the C64
Hello World,
Still before not all too-long time it was quite usual to use for large
programming projects " handknitted " development environments. These
environments had one in common however: As programming language
assembler was used.
Machine code vs. high-level language
An assembler solution is natural regarding memory efficiency and
remark rate the best, unfortunately shines this language however not
with special legibility. High-level languages however are well-known
for the fact that they are very well readable, which by compiling
(translation) produced machine code one says however after that he
sometimes everything else as optimal and in addition much register and
stack intensive are.
6502 - compiler-suitably?
Debt hieran is essentially the typical programming behavior under a
high-level language such as C or Pascal. If one regards such code more
exactly, then it shows up that he consists usually of function or
prozeduraufrufen, sometimes is even geschachtelt this calls. The
transfer of Aufruf-und return parameters as well as
ruecksprungadressen takes place here over the stack - with the C64 is
this well-known on PAGE 1, i.e. the range between $0100 and $01ff,
limits. A nesting of function or prozeduraufrufen can cause thus very
fast a stack overflow (stack OVERFLOW) and it is incumbent on the
programmer here appropriate attention with programming walten to
leave.
With 6502 it is added that this architecture has altogether three
usable registers, about which only one, the accumulator, is usable for
arithmetic operations. The index registers X and Y can be
conditionally likewise used for simple arithmetic (to count), their
actual purpose are situated, like the name already say, in the
indexation of memory accesses.
Against the programmer of a compiler these architecture-conditioned
restrictions make special demands, are the compiler for efficient code
to produce.
And it goes nevertheless
cc65 has already a longer history of the development behind itself.
Originally by John R. Dunning for the 8Bitter von Atari developed,
extended Ullrich of bass joke the cc65 of far to one almost ANSI-C
conformal compiler. In the course of these extensions the original
program was replaced to cc65 by completely new written sections and
around LIBRARIES for BCM MACHINES completed is freely available, under
the address http://www.cc65.org is to program complex and
documentation.
A complete development system covers more than only the
compiler/translator, drum consists the cc65-Paket also of compiler,
assembler and left one. As already addressed the compiler translates
the high-level language into assembler SOURCE, which is then changed
by the assembler in object files. These object files contain
additional information apart from assembler SOURCE like global
variables and not resolved (external) references e.g. LIBRARY calls.
Finally that combines left ones the individual object files into an
executable program. This occurs exclusively statically, i.e.
differently than with dynamic Linking (DLLs under Windows, shared
LIBRARIES under Unix) program and LIBRARY routines are merged into
(partial thick) luggages.
LIBRARIES
Experienced c-programmers know it: The compiler is only the half rent,
almost still more importantly is the library functions, without which
e.g. no display output would be possible.
Also cc65 offers appropriate libraries, it exists even C64-spezifi
routines, whatever enable the direct programming of VIC, SID and CIA
beside display in/output. Over pre-defined structures all registers
can be described and selected in comfortable way.
The code quality
Like initially mentioned is the 6502 a relative to ungrateful
architecture the figure of a typical compiler high-level language. I
was the strained on the quality of the produced code. I was very
surprised actually by density and scope of the Compilats - the
generated assembler SOURCE was from a quality, which assembler
programmers experienced before the eyes does not have to hide itself.
Also the size of the produced Executables is moderate - for a Compilat
-. Here one has naturally the almost unavoidable problem that library
routines are always more extensive due to their universality, than
they would have to be actual for the respective application purpose.
The impact is with small programs (e.g. the classical author " Hello
World! ") with approximately 30 to 50 per cent, with larger projects
the proportion of the LIBRARIES of the total volume sinks naturally.
Under which laeuft's?
cc65 is a CROSS compiler, i.e. Compilation and Linking take place on
another system than the C64/C128. Historically supported cc65 first
Linux and other Unix derivatives, it are however also to postage
portierungen on DOS/Windows and OS/2 at the disposal. On special
bitebite bites one operates at present, i.e. the support 65816. Hereby
it would be then finally possible to develop using a SCPU together
with appropriate memory development in native mode for 65816 directly
on a C64/128.
For this article the Linux version was tested. The cc65-Sourcen could
be translated behaviourless, however only to sufficient reading of the
provided README files. Here it would be desirable to adapt to the
status of the time and provide appropriate configure Skripten - or
nevertheless at least a " make all" option to make available.
Unfortunately the translation of each library must be activated
manually.
Universality is trumpf
cc65 supports the C64, but also C128 as well as the computers of the
C(1)16/Plus4-Serie over appropriate libraries not only, in addition
the CBM600/700 family and naturally also the PET. At not Commodores
the Atari-8Bitter as well as the Apple][ are supported - a genuine
multi-talent thus.
Also the cc65 supports the development of GEOS applications and makes
for this its own library available, the GEOSlib. Further exists with "
grc " utility for the handling of GEOS Headerfiles.
Restrictions
With view to target architectures some small modifications were made.
The data type INT corresponds to a 16bit-Wert, and those DATE types
FLOAT or DOUBLES are not implemented at all. It is correct the fact
that 6502-Systeme control natively no floating point representation,
which is figure of such functions in software however no problem and
well-known-measured also implemented in the BASIC interpreter.
Accordingly one can illustrate floating point arithmetic on a special
mathematics library. This would be a candidate for a later version of
cc65. real tragically is surely the lack of floating point abilities
however not, since most applications with Integerarithmetik can be
mastered.
Differently than e.g. with the GNU c-compiler GCC no code optimizing
is implemented in cc65. This must already take place with programming,
become appropriate notes in the cc65-Dokumentation given. This may
appear first somewhat amazing for c-programmers on other systems, is
not however in the " Small C"-area at all uncommon. (notes: a code
optimizing is naturally implemented, this paragraph developed due to a
misleading formulation of the documentation into the CC65. RB,
3,1,2001)
Result
With cc65 a matured tool is to the ambitionierten c-programmer for
program development for the C64/128 and further 6502-basierte of
systems at the disposal. The quality of the produced code is
presupposed, very good, appropriate attention with programming and one
may be rightfully on the 65816-Umsetzung strained. A documentation
would be desirable over creating own LIBRARIES.
------------------------------------------------------------------------
--
___ . . . . . + . . o
_|___|_ + . + . + . . Per Olofsson, konstnär
o-o . . . o + MagerValp_at_cling.gu.se
- + + . http://www.cling.gu.se/~cl3polof/
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo_at_musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2001-12-14 22:05:38 CET