| | ChristopherJam
Registered: Aug 2004
Posts: 1409 |
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....
|
| | Krill
Registered: Apr 2002
Posts: 2980 |
Quoting SlammerNow 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. |
| | 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. |
| | Krill
Registered: Apr 2002
Posts: 2980 |
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. |
| | Krill
Registered: Apr 2002
Posts: 2980 |
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
} |
| | Slammer
Registered: Feb 2004
Posts: 416 |
I see. You use normal align directives, when you want to control page boundaries. How about placement of graphics, that sometimes have to be in certain places. Do you have to work all graphics positions into the memory map?
Also, Something smart could be required of a linker. If you have libraries like: --- Lib1 ---
.byte 23
--- Lib2 ---
.align $100
.byte 0,1,2,3,3,4,..., $ff
--- Lib3 ---
.byte 23
--- Lib4 ---
.align $100
.byte 0,1,2,3,3,4,..., $ff
--- Lib5 ---
.byte 23
--- Lib6 ---
.align $100
.byte 0,1,2,3,3,4,..., $ff I would prefer it first places lib2,Lib4,lib6 and then Lib1, Lib3 and Lib5 to avoid wasting alot of alignment bytes. |
| | soci
Registered: Sep 2003
Posts: 480 |
The user needs to be smart to create two segments, one for aligned stuff, the other for non-aligned. And then feed them accordingly. |
| | Krill
Registered: Apr 2002
Posts: 2980 |
You are free to make the segments as finely granular as you please. You can also specify graphics positions in your source files, without them showing up in the link file, but that would somehow defeat the purpose.
I don't quite see why the linker should shuffle around segments based on some "smartness" (it would sooner or later fail, as most programs trying to be smart do). You specify the order and can shuffle segments around easily with a bit of the old cut'n'paste. |
| | White Flame
Registered: Sep 2002
Posts: 136 |
ca65, even for single asm file projects. I've got an easily reusable makefile & config to get simple things up fast. |
| | Krill
Registered: Apr 2002
Posts: 2980 |
Quoting Slammerinstead of assuming people are gonna use the script language in a bad way Quoting Oswaldnothing wrong with kickass itself, its brilliant imho. as told what raises eyebrows is when people overuse it :) Reading these forums, it appears to me that many people overuse it. But that's just my personal opinion. Many people prefer KickAss for its main selling point, the built-in scripting, which is cool.
I cringe a little, though, already when people try to incbin a file, but want to skip the first few bytes, then keep a run of bytes, then skip a few more bytes, then keep the rest of the file. This is what the zoo of tools in the *NIX userland was made for. But then many people stick to Windows, and then i do see a point in wanting to do everything with one tool. I wonder how many KickAss users are Windows users, actually.
And Wisdom, assuming that you meant me: The "you" in the hammer/nail post was a generic you. I didn't intend to offend you or anyone personally, and there is no need to post your life story to defend your choice. And i'm certainly not a child any more. |
| | Slammer
Registered: Feb 2004
Posts: 416 |
Edit: response to krill/socis earlier post.. I just got disturbed while writing :-)
Im just trying ot figure out it works plus the pros and cons. That includes figuring out how much is done by the linker and how much the user should do. I guess Soci gave the answer to the library question.
I see both pros and cons. When I heard linker I thought of my experience with linkers on PCs where everything is done for you without a big setup. I guess thats not posible on the c64 which is pretty memory sensitive. But I see some good things and understand why you like the feature. |
| Previous - 1 | ... | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | ... | 22 - Next | |
