| |
ChristopherJam
Registered: Aug 2004
Posts: 1382 |
Assembler preferences.
Two questions:
- what's everyone using these days?
- on large productions, do groups tend to enforce a single assembler for the entire project, or is the code base a bit heterogenous?
I'd like to keep this discussion purely focussed on assemblers; please leave code generators, loader toolchains etc for that other thread.
(as for me, I'm still using xa65 for most projects) |
|
... 204 posts hidden. Click here to view all posts....
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11149 |
the linker in ca65 toolchain - for bigger projects (not necessarily demo coding) being able to have proper libraries and link stuff to arbitrary locations in a memory layout defined in a linker config is unbeatable. |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
nothing wrong with kickass itself, its brilliant imho. as told what raises eyebrows is when people overuse it :) |
| |
Slammer
Registered: Feb 2004
Posts: 416 |
Linking and libraries is an interesting topic. Could you explain the benefits of the linker over for example preprocessor includes like in C/C++? I don't know the ca65 linker, are there any disadvantages? Im thinking, when are labels getting their values and is it limiting the memorymanagement in any way?
Edit: Before you take this the wrong way. I'm actually looking into these things right now and want your opinion |
| |
encore
Registered: Aug 2010
Posts: 64 |
for what it's worth: 64tass |
| |
Adam
Registered: Jul 2009
Posts: 321 |
Quoting Oswaldwhat raises eyebrows is when people overuse it :)
eh? |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
Quote: Quoting Oswaldwhat raises eyebrows is when people overuse it :)
eh?
read back maybe ? hint: krill's last post. |
| |
Adam
Registered: Jul 2009
Posts: 321 |
DASM |
| |
chatGPZ
Registered: Dec 2001
Posts: 11149 |
slammer: it has nothing to do with "includes" - includes are simply "copy pasted" into your source at compile time (in pretty much any language i know)(*). the libraries in the cc65 toolchain work the same as they do in "big" toolchains, like GCC/binutils. in a nutshell:
- the assembler outputs object files ("half compiled" binaries that may contain unresolved symbols and which are position independent)
- the linker reads object files and combines them into the final binary. it resolves unresolved symbols and puts the bits and pieces to their absolute memory location depending on the linker config file
- libraries are basically just a collection of object files, with the one important difference that if you link against a library, the linker will only include those object files that contains symbols that have been referenced before. (and those by themselves can reference other symbols, and pull in more object files as a consequence). this way only the object files that have actually been used will end up in the binary.
there is one backdraw with this approach, which is that the linker (the one in cc65 toolchain at least) can not change the length of instructions, which means in some situations you'll get absolute addressing when zeropage would have been enough. in those cases you'll have to explizitly state the addressing mode to get the optimal code. (or you dont care =P)
64tass contains some mechanism to do a similar thing from within the source iirc (include source files only if they are referenced. or perhaps functions/zones/noidea - i dont use this feature =))
(*)this is not completely true - modern compilers can also omit code from the same compilation unit if its unused, like from a c++ header or c source. this somewhat breaks/improves the traditional way of doing this. |
| |
Krill
Registered: Apr 2002
Posts: 2855 |
Quoting SlammerLinking and libraries is an interesting topic. Could you explain the benefits of the linker over for example preprocessor includes like in C/C++? I don't know the ca65 linker, are there any disadvantages? Im thinking, when are labels getting their values and is it limiting the memorymanagement in any way? The main benefit is that you can statically link object code and relocate it to different addresses without having to recompile it. Of course, the effect (build speed) is marginal for regular C-64 projects (demo parts), and there are basically only two or three kinds of library that people use at (sometimes) different addresses in the same project (i.e., a loader, a demo framework and maybe music/sound routines).
Object code can be linked dynamically as well, such that the code is relocated by a little object loader on the C-64 itself. There are just a few scenarios where this is useful, such as writing code for multi-process OSes (LUnix, GEOS). I have started a dynlinking feature for my loader years ago (to exchange it with later/better/other loaders with finished demos/games), but... nobody would really use it.
Object-internal labels have addresses relative to the object's base address, which get resolved to absolute addresses at link (relocate/load) time. External addresses are resolved and assigned by the linker as well.
Memory management isn't limited. In fact, being able to load the same code to different addresses gives you more possibilities, think of executable overlays in programs that would only have the currently-needed code in memory. |
| |
Krill
Registered: Apr 2002
Posts: 2855 |
Quoting Groepazincludes are simply "copy pasted" into your source at compile time (in pretty much any language i know)(*).
(*)this is not completely true - modern compilers can also omit code from the same compilation unit if its unused, like from a c++ header or c source. this somewhat breaks/improves the traditional way of doing this. Also think of C++ template classes, which usually are declared AND defined in headers, and would only emit the code for one class (of the same kind), no matter how often it is referenced by other compilation units. |
| Previous - 1 | ... | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | ... | 22 - Next |
