| |
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? |
|
... 6 posts hidden. Click here to view all posts....
|
| |
soci
Registered: Sep 2003
Posts: 480 |
@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: 480 |
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: 11386 |
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: 480 |
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: 2014 |
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: 11386 |
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: 480 |
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 ;) |
| Previous - 1 | 2 - Next |
