It is currently Mon Feb 18, 2019 10:05 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 23 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Thu Feb 07, 2019 12:42 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7210
Location: Canada
Amending koitsu's last reply:

cc65 is the C compiler (C to assembly, or C to object)
ca65 is the assembler (assembly to object)
ld65 is the linker (objects to output)
cl65 is the combo "compile and link" (or assemble and link, in this case)

Also, the current documentation is here: https://cc65.github.io/doc/

(The old documents from several years ago that were left up for archival purposes are still unfortunately higher in google results. You should use the new ones.)


Though to be honest I avoid using cl65 in general and prefer to do separate steps for assemble and link. It may seem like an unnecessary step for a single file, but you can get better feedback about what's going on this way.


Top
 Profile  
 
PostPosted: Thu Feb 07, 2019 12:51 am 
Offline

Joined: Mon Jul 18, 2011 10:04 pm
Posts: 45
Got it! there is a comma I was forgetting
cl65 -t none -C nes.ini -m map.txt -vm -o rom.nes -g -Wl --dbgfile,rom.dbg main.s header.s
Thanks, I was really not getting what the switches do...


Top
 Profile  
 
PostPosted: Thu Feb 07, 2019 12:51 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3864
Location: A world gone mad
rainwarrior wrote:
--dbgfile is available to cl65. I don't think -Wl should be used in this case.

Hmm, are you sure? I don't see --dbgfile {filename} mentioned in that document (for cl65, cc65, or ca65 for that matter). I see --debug-info for cl65, which is the same as -g, and doesn't take a filename argument.

This is why I think -Wl needs to be used, since ld65 is what supports --dbgfile per documentation and this check I did that shows it only appears in the documentation for ld65:

Code:
~/work $ git clone git@github.com:cc65/cc65.git
Cloning into 'cc65'...
remote: Enumerating objects: 102, done.
remote: Counting objects: 100% (102/102), done.
remote: Compressing objects: 100% (75/75), done.
remote: Total 59174 (delta 40), reused 43 (delta 27), pack-reused 59072
Receiving objects: 100% (59174/59174), 21.67 MiB | 3.29 MiB/s, done.
Resolving deltas: 100% (37081/37081), done.
~/work $ grep dbgfile cc65/doc/*.sgml
cc65/doc/ld65.sgml:  --dbgfile name        Generate debug information
cc65/doc/ld65.sgml:  <label id="option--dbgfile">
cc65/doc/ld65.sgml:  <tag><tt>--dbgfile name</tt></tag>

It's super easy for me to mix up ca65 vs. cc65 vs. cl65 vs. ld65 so it's very possible I got something wrong.


Top
 Profile  
 
PostPosted: Thu Feb 07, 2019 12:55 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7210
Location: Canada
No, I was wrong about that. Was reading from the wrong tab, I suppose? I'd edited it already before you replied... but you manged to get a quote in. :S

Would recommend that you stop using those outdated documentation links, though. The current stuff is here, and a lot has changed in the past several years since those were frozen:
https://cc65.github.io/doc/


Top
 Profile  
 
PostPosted: Thu Feb 07, 2019 1:00 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7210
Location: Canada
Though also in your multiple-lines example at the end, if you're doing that you should use ca65 and not cl65 for the assemble step. You get better and more direct options and output that way.

Also the -t none is a workaround for cl65 which for some reason defaults to C64 instead of none. You can omit that from a ca65/ld65 invocation and have a simpler command line. (Actually if you're using -C with the linker, -t is invalid anyway.)

That's part of my advice in general for not using cl65. It's kind of a weird black sheep in this toolset, and it probably seems like it's simplifying things by removing a step, but I think we just proved otherwise with that awful command line jockeying we just had to do.


Top
 Profile  
 
PostPosted: Thu Feb 07, 2019 1:04 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3864
Location: A world gone mad
halkun wrote:
Got it! there is a comma I was forgetting
cl65 -t none -C nes.ini -m map.txt -vm -o rom.nes -g -Wl --dbgfile,rom.dbg main.s header.s
Thanks, I was really not getting what the switches do...

Ah, yes! I wasn't sure if the comma was needed since there's a substantial difference between spawning conventions, argument-wise, when it comes to arguments given to one utility that are "passed on" to another. It all has to do with how argv[] gets parsed (by cl65) and what gets passed on to the spawned utility (ld65). The comma-delimited portions are internally handled by cl65 to ensure that they're "passed on properly" to ld65, rather than parsed natively by cl65 itself (hope that makes sense!). In short, there's a substantial difference between these 3 (from the perspective of ld65's argv parser):

Code:
/* probably what happened with cl65 ... -Wl --dbgfile rom.dbg ... */
argv[0] "ld65",
argv[1]: "--dbgfile",
argv[2]: "main.s"

/* likely what would happen on *IX systems if doing cl65 ... -Wl "--dbgfile rom.dbg" ...
 * Note the quotes.  Probably would end up passing the entire string as a single argument to ld65 */
argv[0]: "ld65",
argv[1]: "--dbgfile rom.dbg",
argv[2]: "main.s"

/* probably what happened with cl65 ... -Wl --dbgfile,rom.dbg ..., which understandably works */
argv[0]: "ld65",
argv[1]: "--dbgfile",
argv[2]: "rom.dbg",
argv[3]: "main.s"

All of this (and more) is why I prefer just calling the compiler/assembler directly, and then the linker directly at the very end to link everything together, something rainwarrior advocates as well. cl65 does seem to be a "black sheep" of sorts; sticking to invocations of cc65/ca65/ld65 directly seems to be a better choice.


Top
 Profile  
 
PostPosted: Thu Feb 07, 2019 1:23 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3864
Location: A world gone mad
rainwarrior wrote:
Would recommend that you stop using those outdated documentation links, though. The current stuff is here, and a lot has changed in the past several years since those were frozen:
https://cc65.github.io/doc/

Yeah, I think I've been lectured about this more times than I can count. :-) The reason I get them wrong has to do with the bloody search results in Google or other SEs. Searching for "cc65 documentation" gets you these (order may vary per person, based on Google's weighting algorithms):

Code:
cc65 Documentation Overview
https://www.cc65.org/doc/

cc65 Users Guide: Usage
https://www.cc65.org/doc/cc65-2.html

GitHub - cc65/doc: the official cc65 documentation —
https://github.com/cc65/doc

cc65 Users Guide
https://cc65.github.io/doc/cc65.html

cc65 - a freeware C compiler for 6502 based systems
https://cc65.github.io/

ca65 Users Guide - cc65
https://cc65.github.io/doc/ca65.html

And this is just for cc65 -- but if you look very closely, the last result is actually for ca65 (the assembler), but says "cc65" in the title hence it comes back in the search results.

This same situation applies (though slightly varied) to ca65 and ld65. For cl65 and da65 (disassembler), the situation is much more clear: you only get 2 results: the http://www.cc65.org version and the cc65.github.io version.

github.io (a.k.a. "GitHub Pages") is the "web content" part of github.com, i.e. refers to content in your GitHub repository that you can change/manage with commits like normal, as long as its maintained either via static files or dynamically by GitHub via Jekyll. (I always forget this "sub-feature" of GitHub exists, as I prefer native Markdown documents so that I don't have "multiple websites" showing essentially the same stuff (github.com vs. github.io) -- just put all the content on github.com, which renders Markdown itself, and be done with it)

In short: I wish whoever maintains cc65.org/www.cc65.org would take the time to set up proper HTTP 3xx redirects from old document links to cc65.github.io and relieve half of this confusion. Users are almost certainly going to pick a website based on the software's name over something on GitHub. The actual project maintainers have obviously revamped documentation in a good way (ex. there is no more "cc65-2.html", they just put it all into one document and used anchors), but there's "old stuff lingering" that continues to take priority search-result-wise. :-(


Top
 Profile  
 
PostPosted: Thu Feb 07, 2019 2:04 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7210
Location: Canada
koitsu wrote:
I wish whoever maintains cc65.org/www.cc65.org would take the time to set up proper HTTP 3xx redirects from old document links to cc65.github.io and relieve half of this confusion

I raised the issue twice in the past, and then gave up. Feel free to give it a try yourself.

Otherwise all I can do is point out that you keep linking the old documents, and offer a link to the better ones.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 23 posts ]  Go to page Previous  1, 2

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group