[CSDb] - User Forums - Assembler preferences.

You are not logged in - nap

CSDb User Forums

Forums > C64 Coding > Assembler preferences.

2016-02-09 06:03

ChristopherJam

Registered: Aug 2004
Posts: 1378

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....

2016-04-30 11:42

Adam

Registered: Jul 2009
Posts: 321

Quoting Oswald

what raises eyebrows is when people overuse it :)

eh?

2016-04-30 11:45

Oswald

Registered: Apr 2002
Posts: 5017

Quote: Quoting Oswald
what raises eyebrows is when people overuse it :)

eh?

read back maybe ? hint: krill's last post.

2016-04-30 11:46

Adam

Registered: Jul 2009
Posts: 321

DASM

2016-04-30 12:56

chatGPZ

Registered: Dec 2001
Posts: 11114

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.

2016-04-30 13:19

Krill

Registered: Apr 2002
Posts: 2839

Quoting Slammer

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?

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.

2016-04-30 13:23

Krill

Registered: Apr 2002
Posts: 2839

Quoting Groepaz

includes 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.

2016-04-30 13:33

Krill

Registered: Apr 2002
Posts: 2839

Quoting Slammer

Now I'am sure there are other equally cool benefits in the assembler you use, why dont you state these instead of assuming people are gonna use the script language in a bad way.

My weapon of choice is ca65 for bigger projects, for the reasons Groepaz mentioned, and 64tass for small projects (demos up to 1 K), for simplicity and speed.

That ca65 linker scheme is a powerful thing, but it is too much and too complicated for many projects. It comes in very handy, though, with drive code and bank-switched cartridge code, where its location in the executable isn't the location at run-time. It also forces you to have an abstract view of the different parts of your program, and enables you to better see what is used at what time, and how you can overlay code to have more memory at your disposal.

2016-04-30 13:37

Slammer

Registered: Feb 2004
Posts: 416

I see. How about memory coordination between the different libraries. Does one have to manually coordinate the memorylayout of the libraries(the config file perhaps) or does the linker solve this for you. Manual fixed config+'Linker selects which ones to use' might leave unused holes in the memory when the linker picks which ones to use. A smart linker that organizes the memory for you might lead to lack of control of the memory which sometimes is important.

So i guess the interesting part is what can go in an object file. Is the code position fixed (Perhaps fixed to a given position in page?), but outside symbols not or? If you have a link to a description of the object file format and an example of a config file, please post it - I guess that would explain alot.

2016-04-30 13:50

Krill

Registered: Apr 2002
Posts: 2839

http://www.cc65.org/doc/ld65-5.html

There is not much smartness going on, and doesn't need to. It's basically just putting objects to ascending memory locations. You can also add directives for alignment and fill values.

2016-04-30 14:05

Krill

Registered: Apr 2002
Posts: 2839

Sorry for wall, but here's a real-world example. The code for the DISKIO* segments comes in an object file when linking (loader.o), which must define these segments (they are matched by name). You are free to add code to any segment by simply setting the segment name anywhere you like in your code, multiple times.

MEMORY
{
    LOADERZP:      start =   $4c, size =   $44, type = rw; # must not overlap STATUS ($90)
    ZPRAM:         start =   $fa, size =   $06, type = rw;
    # the C STACK memory area must be defined in the applications's link file
    # when using the importldr function to dynamically link the loader
    STACK:         start = $0100, size =   $80, type = rw, define = yes;
    RAM:           start = $1000, size = $c000, type = rw; # Plus/4 has screen and colours at $0800-$1000
    RAM2:          start = $1000, size = $f000, type = rw;
}

SEGMENTS
{
    ZEROPAGE:       load = ZPRAM, type = zp;

    CODE:           load = RAM,   type = ro;
    RODATA:         load = RAM,   type = ro, optional = yes;
    DATA:           load = RAM,   type = rw, optional = yes;
    BSS:            load = RAM,   type = rw, optional = yes;

    BITMAP:         load = RAM2,  type = bss, start = $4000, optional = yes, define = yes; # overlay with DISKIO_INSTALL
    COLRAM:         load = RAM2,  type = bss, start = $7000, optional = yes, define = yes; # $1000 on Plus/4 (SPRITES segment not used)
    SPRITES:        load = RAM2,  type = bss, start = $7400, optional = yes, define = yes; # no SPRITESHI segment: the sprites are always in this bank

    VERIFYBUFFER:   load = RAM2,  type = bss, start = $8000, optional = yes, define = yes;

    BITMAPHI:       load = RAM2,  type = bss, start = $c000, optional = yes, define = yes; # also location of IEEE-488 KERNAL extensions with SFD-1001
    COLRAMHI:       load = RAM2,  type = bss, start = $f000, optional = yes, define = yes; # not used on Plus/4

    # these three segments must be defined in the application's link file
    DISKIO_ZP:      load = LOADERZP, type  = zp,    define = yes;
    DISKIO_INSTALL: load = RAM,      start = $4000, define = yes; # fire and forget
    DISKIO:         load = RAM,      start = $6500, define = yes; # must not exceed $7000 (COLRAM) in this program
    # this segment must be defined if the loader links dynamically to the application
    DISKIO_IMPORT:  load = RAM,      start = $8000, define = yes, optional = yes; # fire and forget - however, dynlink code is in the CODE segment, too
}

Previous - 1 | ... | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | ... | 22 - Next

Refresh

Subscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search for in
All times are CET.

Search CSDb

Advanced

Users Online

encore
zscs
Steel/SCS&TRC/G★P
Magic/Nah-Kolor
Guests online: 100

Top Demos

1 Next Level  (9.8)
2 Mojo  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Comaland 100%  (9.6)
6 No Bounds  (9.6)
7 Uncensored  (9.6)
8 Wonderland XIV  (9.6)
9 Memento Mori  (9.6)
10 Bromance  (9.5)

Top onefile Demos

1 It's More Fun to Com..  (9.7)
2 Party Elk 2  (9.7)
3 Cubic Dream  (9.6)
4 Copper Booze  (9.5)
5 TRSAC, Gabber & Pebe..  (9.5)
6 Rainbow Connection  (9.5)
7 Onscreen 5k  (9.5)
8 Wafer Demo  (9.5)
9 Dawnfall V1.1  (9.5)
10 Quadrants  (9.5)

Top Groups

1 Oxyron  (9.3)
2 Nostalgia  (9.3)
3 Booze Design  (9.3)
4 Censor Design  (9.3)
5 Crest  (9.3)

Top Swappers

1 Derbyshire Ram  (10)
2 Jerry  (9.8)
3 Violator  (9.8)
4 Acidchild  (9.7)
5 Starlight  (9.6)

Page generated in: 0.068 sec.