cc65 competition?
in [Commodore]
|
Prev: CBM Repair Problem
Next: scanning manuals
From: Marc 'BlackJack' Rintsch on 13 Apr 2008 05:52 On Sat, 12 Apr 2008 17:52:34 -0700, Harry Potter wrote: > On Apr 12, 8:26 pm, Harry Potter <maspethro...(a)aol.com> wrote: >> I want to compile a simple Hello, World!" program with just one >> printf() function and see how it works. >> > > I just did that. The following is the listing of the main() function: > > main() > { > printf ("HELLO, WORLD!\n"); > getchar(); > > exit(0); > } > > This code produced a 10.9k executable. If I only include the *used* > library functions, as cc65 does, I could easily cut down the code > size. It would be unnecessary big with `printf()`, at least with cc65, because all the formatting code will be included. Try `puts()` for constant strings instead. And I don't consider 11 KiB that big. Remember that cc65 doesn't use the BASIC ROM, so there is some "base part" that makes short programs seem to look quite large compared to BASIC counter parts. Because the BASIC ROM isn't needed you have about 50 KiB free RAM for C programs on the C64. So part of your first feature, use of RAM from $a000-$cfff is already implemented in cc65. The RAM from $d000-$ffff is used by the graphics libraries that come with cc65 or can be accessed through the "memory driver" API. Ciao, Marc 'BlackJack' Rintsch
From: Harry Potter on 13 Apr 2008 06:56 On Apr 13, 5:52 am, Marc 'BlackJack' Rintsch <bj_...(a)gmx.net> wrote: > It would be unnecessary big with `printf()`, at least with cc65, because > all the formatting code will be included. Try `puts()` for constant > strings instead. > True, but if I exclude long and float support, I could probably decrease overhead by as much as .5k. > And I don't consider 11 KiB that big. Remember that cc65 doesn't use the > BASIC ROM, so there is some "base part" that makes short programs seem to > look quite large compared to BASIC counter parts. Because the BASIC ROM > isn't needed you have about 50 KiB free RAM for C programs on the C64. So > part of your first feature, use of RAM from $a000-$cfff is already > implemented in cc65. > 11k is manageable, but what if I'm creating a program for the Vic20, or for the C64 at $8000 or $C000? > The RAM from $d000-$ffff is used by the graphics libraries that come with > cc65 or can be accessed through the "memory driver" API. > True, but I'd like to access this data directly (i.e. declare it as "hidden" and have the compiler automatically access this data through a function cal whenever it is encountered). Functions wouldn't work well on a C64, but they would in Bank 1 on a C128.
From: BruceMcF on 13 Apr 2008 15:00 On Apr 13, 6:56 am, Harry Potter <maspethro...(a)aol.com> wrote: > 11k is manageable, but what if I'm creating a program for the Vic20, > or for the C64 at $8000 or $C000? If you are creating a program for the C64 at $C000-$CFFF, then assemble it. Rather than try to replace cc65, improve it. Then each feature on your list is added to what cc65 already provides. For example, an external function call interface for lc_65816, so libraries can be written with cc65 code for the stock C64 and SuperCPU code if the SuperCPU is available. Also, it would make sense to use "register" declarations for local variables that could benefit substantially from being in ZP locations, since the idea of a register declaration seems to be widely understood in the C world.
From: Harry Potter on 13 Apr 2008 15:44 On Apr 13, 3:00 pm, BruceMcF <agil...(a)netscape.net> wrote: > Rather than try to replace cc65, improve it. Then each feature on your > list is added to what cc65 already provides. > I understand. Thank you.
From: Bill Buckels on 13 Apr 2008 16:22
On Apr 12, 7:26 pm, Harry Potter <maspethro...(a)aol.com> wrote: > > How about the C64??? Harry what are you doing with overlays? OK and > > did you look at the memory map that I am using with Aztec C? > > Er, what *is* the C64 memory map used by Aztec C C64? Generally I create a an explicit hole with the linker and push the code and data past the graphics screen area, embed the graphics screen directly into that area, embed a bitmapped font and graphics cursors below that area etc. I also do the same on the Apple II. I use and provide (FREE) programs for both the Apple IIe and C64 Aztec C Cross-Compilers that embed title screens into memory holes and load fonts into these holes etc. Read the following articles: Adding Graphics and Fonts to a Compiled C64 Program http://landover.no-ip.com/forums/index.php?topic=2241.0 Adding Title Screen and Graphics Cursors to a Compiled Apple IIe ProDOS 8 Program http://landover.no-ip.com/forums/index.php?topic=2241.msg8981#msg8981 > > > I am creating holes where I want them and all that... I hardly think > > the program code itself is large. Perhaps my load address, base > > address, and what I am reserving for data is what you are reacting to. > > How do you like what I am doing with the graphics compression and > > such? > You had better read this one too... or the entire thread. KOALA Paint and Other Bitmapped Graphics in Aztec C64 http://landover.no-ip.com/forums/index.php?topic=2243.0 > Do you include *every* function in a library, or just the necessary > ones? cc65 seems to include justb the necessary ones, although some > fat (i.e. the initmainargs assembler function, which processes the > command line, shortened to pushing two NULLs on the stack) could still > be cut. > The linker for any C compiler that I have ever used and there have been many, explicitly links. You and I do not make that choice. Every function is not included. That would be like DLL hell that these Windows Mousemasters (myself included) have inflicted on us all in the name of GUI interfaces. All that a library is, is a bunch of object modules that are linked in one at a time. You mentioned in some other email that you wanted to use a list of object modules. Put those in a library. The command line used to be much shorter but even now we use link libraries. If you need a refresher on libraries and Aztec C go here: LIBRARY MANAGEMENT and Libutil in Aztec C http://landover.no-ip.com/forums/index.php?topic=2242.msg8982.0 > I want to compile a simple Hello, World!" program with just one > printf() function and see how it works. The guys that created these compilers were very smart men with lots of compiler design knowledge and understanding. They knew how a linker works obviously since they wrote the darned thing. They knew how an optimizer works. Etc. THEY set the standards that you and I follow today. Try this link Too. Compiler Design by Alan Holub etc. http://lua-users.org/wiki/CompilerWritingReferences I had a look at what BlackJack was saying about program size. All C compilers need start-up code and stack handling code and so forth... Now with Aztec C you have the option of tweaking any of this and redoing the libraries. Most of us don't think we're so darned clever that we could of course and prefer to tweak our own code. The beauty of the assembly pass is that you can optimize anything you wish. But choosing to use printf as the basis for a small functional program is not what I would call a good test either (like BJ said already)... I would need to rummage around alot in the compiler and tear apart some libraries and so forth to trim this down to a special purpose thing and I am not in the mood to do that right at the moment. What I am in the mood to do is to try to get permission for the public domain release of Aztec-C. This may backfire on me and I may be told to take down my website, but I am as ready as I'll ever be. Have Fun Now! Bill |