| |
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 SlammerWhen 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. Hmm, what do you mean? I've spent some time tinkering with GNU ld link files, and ld doesn't automagically do things either. You do have a bit of scripting there, but IIRC not the Turing-complete sort. The cc65 suite does many things pretty much like the original *NIX way, only with 6502-ish targets. And ld65 comes with a few built-in targets as well, so you don't have to write your own link files for simple memory layouts. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting ChristopherJamon large productions, do groups tend to enforce a single assembler for the entire project, or is the code base a bit heterogenous? As others said already, there is no need to enforce The One Assembler. And why would there be? :) Given the plethora of assembler preferences, no demo coded by many coders would get finished. And already the choice of loader usually gives you the need to work with a second assembler, albeit only once to build the loader with your preferred options. |
| |
Slammer
Registered: Feb 2004
Posts: 416 |
Quoting KrillHmm, what do you mean? I've spent some time tinkering with GNU ld link files, and ld doesn't automagically do things either. You do have a bit of scripting there, but IIRC not the Turing-complete sort. The cc65 suite does many things pretty much like the original *NIX way, only with 6502-ish targets. And ld65 comes with a few built-in targets as well, so you don't have to write your own link files for simple memory layouts.
Back in 1995-2000 when i coded C++ I never had to make any linker config files. A makefile was enough to glue it all together. Why did you need link-configuration? |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting SlammerWhy did you need link-configuration? E.g., for embedded systems firmware, i needed a special section for non-volatile RAM. Static variables assigned to this section ("PERSISTENT_VARIABLE(int user_flags)") would be periodically monitored and mirrored to an EEPROM by a background thread, to survive power-cycling without requiring any code other than using that PERSISTENT_VARIABLE() macro. The same firmware can be built as a regular x86-PC Linux command-line program, which needs this segment as well (but accesses a regular file rather than an EEPROM, in that background thread).
And well, in embedded systems you generally used to require your own special memory layout and link files. Not so much these days any more, with lower-end hardware already sporting an MMU and happily running Linux. |
| |
Slammer
Registered: Feb 2004
Posts: 416 |
Sorry for picking your brains, but I find this intersting. As I understand it the memory management of the linker seem to have 3 levels: File<-Memory<-Segment (I know the file level is not that explicit as its an argument for memory)
I completely buy that segments are good, but how much do you use the memory level. Wouldn't it be simpler and just as good to do: File<-segment Also, I get the destinction between bss and other segments. But do you use the difference between ro and rw, and wasn't it better placing it (only) at the memory level? |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
The Memory directive is used to emit bytes to different files. In Booze I have two memories. One from 200-1fff where init, decrucher, loader and music i located. This is emmitted to main.bin. The rest goes into code.bin. The final product is a concatenation of the two, smack on a load addy and cruch it. When it goes into the final disk linked with the rest I only feed it code.bin |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
What Jackasser said, and multiple memories/output files can also be used for the overlays i keep mentioning. You relocate/switch banks/load files to overlapping memory regions at different times. And sometimes you do have actual different distinctive memory, e.g., in cartridges and drive code.
The access directives may be somewhat more logical when applied to memories rather than segments, but they are more practical for segments. Think of things like linker errors/warnings when it detects a write attempt to a read-only segment. Though i have never encountered that with ld65. I might have just never done this, neither purposely nor by accident. :) |
| |
Peacemaker
Registered: Sep 2004
Posts: 275 |
Indeed, multiple memories/output files for be very useful to make some things easier.. Himen (e.g. $e000-$ff40) output file along with the "main" bin (e.g. $2000-$abcd) output file. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:Also, I get the destinction between bss and other segments. But do you use the difference between ro and rw, and wasn't it better placing it (only) at the memory level?
the file level is needed for overlays, think of stuff that gets loaded from disk (eg: demoparts). if you use this consequently through the entire demo, you can just link together everything without the need of header/include files that keep all the addresses/labels for common functions (loader/music/framework).
the ro/rw stuff is needed when you have ROM - like a cartridge image. (the linker can produce warnings or even errors when you try to write to memory that is in a readonly section, thus saving you a lot of WTF) |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
I also used it both in the EotB preview and in the c128 3d engine for emitting code to the upper memory block and then load it from disk |
| Previous - 1 | ... | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | ... | 22 - Next |
