| |
Compyx
Registered: Jan 2005
Posts: 631 |
64tass multiple inclusion guard
I have recently decided to use 64tass for my next projects. It has all of the features I was implementing in my own assembler, and quite a few more. Even wrote a VIM syntax highlighting script, so I'm sticking with it.
One thing I'm missing though, is the ability to use multiple inclusion guards, as in C:
#ifndef KERNAL_CALLS_H
#define KERNAL_CALLS_H
GETIN = $ffe4
...
#endif
Reading the manual, it clearly states that .ifdef and .ifndef will not be added, due to technical reasons.
I could get around this using the -D command line argument to initialize each inclusion guard to a false state and later update that label to a true state in the included file. But with a lot of header files, that's going to become messy quickly.
Any 64tass user out there who has tackled this? Or am I over-thinking this with a C coder mindset? |
|
| |
Oswald
Registered: Apr 2002
Posts: 5022 |
I always wondered why many of you guys need complicated stuff like that for simple c64 programming. so I vote for overthinking. |
| |
Angel of Death
Registered: Apr 2008
Posts: 210 |
I second Oswald's motion of overthinking and add to that with "don't be lazy and clean up your header files." :)
Also, 64tass was at first made to seamlessly work with the c64 turbo assembler 'written' files. Any functions more than those are an added bonus anyway. |
| |
soci
Registered: Sep 2003
Posts: 474 |
The trick is to create weak "guard" variable with one value, and then create a strong version of it later with some other value.
.weak
kernal_stuff := true ; default value as "weak".
.endweak
.if kernal_stuff
kernal_stuff := false ; create the "strong" version here
GETIN = $ffe4; definitions, whatever
.fi
The weak variable acts as a "default" value in case there's no stronger variant yet.
That's one way. The other is to not include stuff more than once per namespace. E.g. you include modules as separate files and all of them need kernal symbols, these will conflict of course globally.
Instead create a namespace for each module file, include the the kernal symbols in there. Now either you can access the modules through it's named namespace or you may export some of it's symbols and enclose the rest as anonymous.
Variant A:
Create the namespace in the main file for each module. Advantage is that you can choose a name externally (not in the module) and therefore the content will not conflict for sure.
module1.asm
.include "kernal.asm"
stuff nop
module2.asm
.include "kernal.asm"
stuff2 nop
main.asm
module1 .binclude "module1.asm" ; "block" include
module2 .binclude "module2.asm"
jsr module1.stuff ; access through namespace
jsr module2.stuff2
Variant B:
Export stuff from anonymous namespaces. These assignments also works for functions, macros and other stuff. Advantage is short access in main file and good isolation of private symbols. Disadvantage is that exported names might conflict with main file or other modules.
module1.asm
stuff = (+).stuff ; export symbol
+ .block ; anonymous, only accessible above
.include "kernal.asm"
stuff nop
.bend
module2.asm
stuff2 = (+).stuff2 ; export symbol
+ .block ; anonymous, only accessible above
.include "kernal.asm"
stuff2 nop
.bend
main.asm
.include "module1.asm" ; normal include
.include "module2.asm"
jsr stuff ; was exported in include
jsr stuff2
|
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Yeah, I think you fellas are right: it's a C64. I always got away with using a single source file in Turbo Assembler, self-modifying code, and interrupt handling which amazes me it even worked properly.
Thanks, my Makefile just became a two-line file ;) |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
@soci:
Wow, thanks a lot! I was thinking about weak using weak references for this. So what I'm trying to do is possible, although perhaps not the best way of going about it.
Might I ask the reasons behind not implementing .ifdef/.ifndef? You obviously have a decent symbol table implementation, since I can use nested scopes and local labels. |
| |
soci
Registered: Sep 2003
Posts: 474 |
All depends on the project. Demo part coding does not need much support structurally, agreed.
On the other hand projects like Funkpaint, Kobo64 or IDEDOS needs some help in organizing stuff from the assembler. |
| |
soci
Registered: Sep 2003
Posts: 474 |
@Compyx:
Yes, possible to do but not recommended.
As for .ifdef/.ifndef. There's no preprocessor as such, so it'd end up in a non-solvable situation for that construct in the top post. |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
What I'm working on right now needs some structure. I'm writing a couple of editors for non-standard graphic modes.
To avoid code duplication, I'm working on a 'library' which basically provides a widget collection and 'window manager' to handle input and event handling. And some editing primitives for zooming/editing. Sounds like a Qt port for C64, hence the need for organizing my code.
And all this for, hopefully, a single-file demo for X2016. |
| |
soci
Registered: Sep 2003
Posts: 474 |
Sounds like a lot of effort, unless the tool is planned to be released as well or it's for future projects. Writing a one off converter might be easier, but YMMV.
You may try to use ".proc/.pend" to try to limit the amount of "unused" code/data compiled in from the library as an alternative to the ".if/.fi" hell.
But beware that cyclic references between ".proc" blocks are not collected yet, so such .proc blocks will always be included. Will be fixed someday I hope... |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
I plan to release those tools, so the effort is worth it, I guess.
I could indeed use .proc stuff, which looks promising. But if that screws with the garbage collector, I'll avoid that, for now. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11127 |
its this kind of stuff where having a real linker, as in the cc65 toolchain, beats all other solutions by far :) |
| |
soci
Registered: Sep 2003
Posts: 474 |
Compyx:
The garbage collector can collect cycles and is separate from the ".proc" dependency handling. You can use ".proc"-s without causing any problems, I just noted that in special cases more will be compiled in than expected.
Groepaz:
How does a linker help? It links object files, therefore you need tons of source files for fine granularity (possibly one per function), or else lot of unnecessary stuff gets in. |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: its this kind of stuff where having a real linker, as in the cc65 toolchain, beats all other solutions by far :)
Yep, and it's perfect for demo coding also once you have a template project setup with a Makefile and a linkfile. (ot.. Sorry) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11127 |
Quote:how does a linker help? It links object files, therefore you need tons of source files for fine granularity (possibly one per function), or else lot of unnecessary stuff gets in.
sure you do - however i find that a lot less complicated and MUCH more "readable" than all those ugly hacks needed to achive the same in other assemblers. as soon as "library" is what you want to use doing it this way is superior and less hazzle.
for demo coding i still prefer acme (or 64tass) though :) |
| |
soci
Registered: Sep 2003
Posts: 474 |
Well it might be superior in some ways but outside of my use cases then. I just wrap my functions (or even data) with .proc blocks to avoid dead code and call it a day.
In practice I don't bother building an asm libraries or even a symbol collection for the KERNAL. I just cherry pick stuff from my older sources as needed. Usually there's not too much to share between projects anyway. |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Well, after getting my head around how .block and .binclude work together, I now have my code neatly organized into namespaces, as I would in Python code.
As for 'linking', the assembler takes care of that with .include or .binclude in my main.asm (or whatever), which simplifies my Makefile a lot.
I just had to adjust my approach a little, I've been writing way too much C, and not nearly enough good old assembly ;) |
