| |
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? |
|
... 10 posts hidden. Click here to view all posts....
|
| |
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 |
