Hi! On Sat, Oct 09, 2010 at 10:51:22PM +0200, doynax wrote: > 1. Am I likely to get into trouble compiling the odd C function into > an existing project? Not sure what you mean with that. If you have an asm project and want to add C code, you will have to make sure that the C runtime is setup properly. This means that you will have to look at the C startup code and merge the important parts into the startup code of your program. > 2. My old code makes frequent use of a certain "single_page N" macro > which insures that the following N-byte array stays within a single > page. Is there any way I can handle this efficiently in CA65? As far > as I can see just aligning would waste up to 4*(N-1) bytes. That depends. You can use .assert statements if all you want is to get a warning or an error from the linker if the requirements aren't met. You can use segments to actively place these arrays. How does your current code avoid wasting space for alingment? > 3. Should I be using the preprocessor to implement non-trivial loops? > I can't see how to redefine labels imperatively so I tried using macro > recursion but ran into if-nesting limits. My suggestion is to avoid .define (if that is, what you call the "preprocessor") if you can. .define works on token level, and therefore ignores scoping. You can get all sorts of weird side effects when using it. Apart from that I'm not able to make any suggestions, without knowing a bit more about what you're trying to do. > 4. Am I abusing named scopes by trying to use them like C++ > namespaces? I seem to end up wanting to open scopes twice, both in the > code itself and in the .inc "header." scopes aren't namespaces and therefore you cannot open them twice. However, the snapshot (not 2.13) allows to introduce new symbols into a scope even when the scope is closed. So you can do something like .proc foo bar = $20 .endproc foo::baz = $10 Again here, without knowing the exact problem, it's difficult to suggest actions. My usual approach is to do it in a similar way as with C sources: * An include files defines an interface to a module. So it contains constantds, structures and has .global statements for the external identifiers, but no data or code definitions. * The implementation module includes above file and defines the necessary code and data. In this case the .global directives will turn into .export statements. * Other modules will just reference the stuff defined in the include file, so the .global directives will turn into .import statements. This has proved to work quite well, especially for bigger projects. > I apologize ahead of time if any of this has already been covered by > the manual or previous discussions in the mailing list. It's not covered in the manual because it's more a "how to make best use" discussion. ca65 allows several styles which is one of its strengths as I see it. There is no "best style", it all depends on the actual problem. Regards Uz -- Ullrich von Bassewitz uz@musoftware.de ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo@musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.Received on Sun Oct 10 14:54:35 2010
This archive was generated by hypermail 2.1.8 : 2010-10-10 14:54:38 CEST