It is currently Sat Sep 21, 2019 3:50 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 11 posts ] 
Author Message
 Post subject: cc65 versions
PostPosted: Tue May 14, 2019 12:00 pm 
Offline
User avatar

Joined: Sat Sep 07, 2013 2:59 pm
Posts: 1904
Since I started programming for the NES, I have been using the cc65 compiler from http://www.cc65.org.

But now I encountered incorrect behavior in a certain case while the same C code looks different in the new cc65 version from https://cc65.github.io.

Since it's not just some simple library bug, but an actual severe issue (there's a situation where integer comparisons don't work properly), I think that it's time to switch to the new compiler and to change my code according to the new syntax.


However, I've got some questions about it:

The old compiler had a definite version number. But for the new one at GitHub, I only see a download link for the current snapshot.
So, does the new one also have major releases? Or is it always just the snapshot and the way my C code is turned into assembly code can change on a whim?

How is the integrity of the version ensured? What if I download the compiler at the time I want to ship my game, and in this one version a bug sneaked in that wasn't available at any time before?

Or how about speed and ROM size: It it ensured that the execution time of a program doesn't get worse with a new version?

_________________
Available now: My game "City Trouble".
Website: https://megacatstudios.com/products/city-trouble
Trailer: https://youtu.be/IYXpP59qSxA
Gameplay: https://youtu.be/Eee0yurkIW4
German Retro Gamer article: http://i67.tinypic.com/345o108.jpg


Top
 Profile  
 
 Post subject: Re: cc65 versions
PostPosted: Tue May 14, 2019 12:45 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7582
Location: Canada
Yes, this is an unfortunate problem with the project. The old website never gets updates and remains prominent in searches for it, so it's a continual point of confusion for people trying to find the latest version.

On top of this there is no archive of releases, and the only readily available build for years has been the Windows Snapshot which comes directly from the Git repository.


You can see the version number with: cc65 --version

This has a version number as well as a Git commit. Unfortunately with no release archive, the only way to get a specific build again is to pull that Git commit and build it. Somewhat fortunately, it's relatively easy to build with GCC (via MinGW/MSYS) or Visual Studio, or on other platforms with other forms of GCC. It's a command line app with no external library dependencies, so there's nothing else to set up besides your compiler.

Also somewhat fortunate, regressions seem pretty rare, in practice. Despite how informal the release process has been, the issues with version differences I've had over the years have been extremely minor. There is a lot of unit testing in the project, and its maintainers tend to be slow and careful about things.

The version number is changed infrequently, generally when some incompatible change is made. You can get a sense of it from commits to version.c, or the releases page, but I don't think there's good documentation on the project history, sadly.


As for what to do with your project, I would just suggest not to re-download the compiler at the time you want to ship your game. Download new versions only when you're starting a new project, or need a particular bugfix or feature that's been introduced, or otherwise when you know there is enough time to test and verify changes that might have occurred.

...and don't use CC65 as a global install. Keep a local copy for each project so that they each stay on the same version unless you have reason to change it.


Top
 Profile  
 
 Post subject: Re: cc65 versions
PostPosted: Tue May 14, 2019 1:25 pm 
Offline
User avatar

Joined: Sat Sep 07, 2013 2:59 pm
Posts: 1904
rainwarrior wrote:
Unfortunately with no release archive, the only way to get a specific build again is to pull that Git commit and build it.

It's not so much that I need a specific version. After all, the whole point of the change is to get the best and most up-to-date version.

But other projects usually have actual releases that are different from nightly-build on-the-fly bugfixes.
But this one here is basically always the source control "get latest version" equivalent: Whatever is included is included. And if some addition introduces a bug, it's readily available for download while other projects would keep it away from the new version until it is tested and validated.

I don't care for actual version numbers, I just care for the fact that the main download should really be the current stable version, separate from globally untested changes and the like.

rainwarrior wrote:
Despite how informal the release process has been, the issues with version differences I've had over the years have been extremely minor.

What kind of issues were they?
Just some syntax differences that the compiler complains about? Or did you also encounter situations where the compiler actually executes your code in an incorrect way?

rainwarrior wrote:
As for what to do with your project, I would just suggest not to re-download the compiler at the time you want to ship your game. Download new versions only when you're starting a new project, or need a particular bugfix or feature that's been introduced, or otherwise when you know there is enough time to test and verify changes that might have occurred.

Well, my project is going for two years now. When the game ships, I would want the best version of the compiler in case some stuff has become smaller and therefore faster, so that lags are minimized.
I assume I will periodically update the compiler and make a file compare of the source code. Then I'll decide a final point of no return when the game is almost finished and before it goes into the testing phase.

rainwarrior wrote:
...and don't use CC65 as a global install. Keep a local copy for each project so that they each stay on the same version unless you have reason to change it.

Yeah, this is a necessity anyway: "City Trouble" doesn't compile with the new version without changes, thanks to those pragma stuff (and the fact that you cannot write something like LDA #-1 anymore, it has to be LDA #$FF).
But even if it compiled, I would want to be able to recompile my code and get exacly the same ROM as before, so I'll of course keep my old copy of cc65.

_________________
Available now: My game "City Trouble".
Website: https://megacatstudios.com/products/city-trouble
Trailer: https://youtu.be/IYXpP59qSxA
Gameplay: https://youtu.be/Eee0yurkIW4
German Retro Gamer article: http://i67.tinypic.com/345o108.jpg


Top
 Profile  
 
 Post subject: Re: cc65 versions
PostPosted: Tue May 14, 2019 2:02 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7582
Location: Canada
DRW wrote:
What kind of issues were they?

At one point, I think in 2014, strict GCC-style compiler flag ordering was briefly imposed, which broke my build scripts. This was reverted shortly after though.

The other thing was the addition of better range checking in ca65, which generated errors for signed numbers used as immediate values. None of the meaning or output of the code changed, though, and the new feature could be disabled by .feature force_range (added at the same time). A minor inconvenience, but the better range checking was definitely worth it, IMO. (Still wish it could do signed stuff properly, but that remains a wishlist feature.)

Otherwise I actually haven't run into any regressive changes. I've seen macros become more capable, but not retroactively invalidated. I've seen improvements to the code generated by the CC65 compiler, but I have yet to notice a case where the code became worse.

I can't say it doesn't happen, but it hasn't happened to me, yet.


As for the project's lack of a formal release procedure with stable and unstable releases (and a change log)... I don't like it, but nobody has volunteered to do this work. In practice, it's actually a surprisingly stable project despite this. I think its core maintainers do a good job of reviewing the code that goes in.


Top
 Profile  
 
 Post subject: Re: cc65 versions
PostPosted: Tue May 14, 2019 2:27 pm 
Offline
User avatar

Joined: Sat Sep 07, 2013 2:59 pm
Posts: 1904
Alright, thanks for the information.

I'll convert my current code tomorrow. Let's see whether it still works afterwards and how much I actually have to change. :D

_________________
Available now: My game "City Trouble".
Website: https://megacatstudios.com/products/city-trouble
Trailer: https://youtu.be/IYXpP59qSxA
Gameplay: https://youtu.be/Eee0yurkIW4
German Retro Gamer article: http://i67.tinypic.com/345o108.jpg


Top
 Profile  
 
 Post subject: Re: cc65 versions
PostPosted: Wed May 15, 2019 12:04 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 967
I have seen regressions, in each case I complained loudly and they were fixed. For new features and code generation improvements, they were mostly contributed by me in the last couple years. There have been new features for platforms I don't use, Atari/Commodore terminals and so on, but I don't remember any general compiler features other than my trampolines and computed gotos. Some optimizer improvements have been made, but my projects didn't hit those special cases; my projects did hit the inc/dec codepath I sent. The runtime lib code got some optimizations, which is always useful.

That is to say, it doesn't see much changes, good or bad, unless you do it. Like any git project you have to do basic checks when you update, but given the rate of change it's not going to be a huge time sink. They're quite responsive for pull reqs, so if you need some feature or better optimization, do send some code in.


Top
 Profile  
 
 Post subject: Re: cc65 versions
PostPosted: Wed May 15, 2019 2:54 pm 
Offline
User avatar

Joined: Sat Sep 07, 2013 2:59 pm
Posts: 1904
calima wrote:
They're quite responsive for pull reqs, so if you need some feature or better optimization, do send some code in.

Thanks for the offer.

When I converted my program to the new compiler, I indeed stumbled upon something that wasn't an issue in the old version:

When I have this code:
Code:
#pragma bss-name(push, "ZEROPAGE")
unsigned char Variable;
#pragma bss-name(pop)

then everything is fine:
Code:
.segment   "BSS"

.segment   "ZEROPAGE"
_Variable:
   .res   1,$00

However, when I omit the pop:
Code:
#pragma bss-name(push, "ZEROPAGE")
unsigned char Variable;

then the compiler fails to push the variable to the zeropage:
Code:
.segment   "BSS"

_Variable:
   .res   1,$00

I think this is incorrect behavior.

First of all, I don't know why the code enforces the closing anyway. I mean, who cares if the code file ends without the last segment move being closed?

For example, in my game, I have a header file that gets included into every c file. And this file has, among other things, a #pragma bss-name(push, "ZEROPAGE").
This way, all my global variables are automatically declared as zeropage variables, unless I explicitly declare them as non-zeropage.

With the old cc65, this worked fine.
But now, with the new version of the compiler, I had to create a new file that has a #pragma bss-name(pop) and I have to remember that each time when I include the first header file, I also have to include the new header file at the end of the code.



But let's say that enforcing the explicit pop of segment pushes is a definitely necessary thing:

In this case, the compiler should at least warn when this doesn't happen. Silently ignoring the push is definitely not the right behavior.

In my case, the only way I even found out about this problem is because some of my zeropage variables were also declared as extern in a header file and had #pragma zpsym.
So, the compiler told me that the variable is exported as zeropage, but defined as global.

The compiler did not tell me: Segment push wasn't popped.
I only found out about this due to a connected, but ultimately logically unrelated error: Zeropage/global discrepancy between variable declaration and variable definition.

If all my zeropage variables had been static, I wouldn't have gotten an error and I would have wondered why the occupied space in the ROM is suddenly so much bigger. Because the compiler would have silently ignored my zeropage push that I didn't pop back and it had treated all variables as absolute.

Or imagine you push variables into the game's battery save RAM and forget to pop this. The variables will remain in the regular BSS RAM and you can wonder why your battery save doesn't work.



So, yeah, one way or the other should be done:

Either the compiler should warn if you don't pop back a push.

Or, and this is my preferred version:
The compiler should implicitly pop all pushes back himself when the translation unit has ended.
This way, you can declare that a certain file shall have all variables or all code in a specific segment, without having to write a redundant pop in the last line.



Another thing: As far as I see, the version #pragma bss-name("ZEROPAGE") (without the push) is ultimately useless. This one doesn't accept a pop ("Error: Segment name stack is empty"). But without the pop, it gets ignored anyway:
Code:
#pragma bss-name("ZEROPAGE")
unsigned char Variable;

produces
Code:
.segment   "BSS"

_Variable:
   .res   1,$00

So, it looks like the original intention was that you can leave out the pop if you want, otherwise they wouldn't have explicitly enabled a version without the push command. But it seems like this version would never work in the current build.

_________________
Available now: My game "City Trouble".
Website: https://megacatstudios.com/products/city-trouble
Trailer: https://youtu.be/IYXpP59qSxA
Gameplay: https://youtu.be/Eee0yurkIW4
German Retro Gamer article: http://i67.tinypic.com/345o108.jpg


Top
 Profile  
 
 Post subject: Re: cc65 versions
PostPosted: Wed May 15, 2019 8:48 pm 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 2312
Location: Fukuoka, Japan
This seems to be a bug with bss-base since it works fine with all other xxxx-base segment. I had the same issue recently and I had to resort to wrap with push/pop the variables I needed a different bbs segment.


Top
 Profile  
 
 Post subject: Re: cc65 versions
PostPosted: Thu May 16, 2019 12:17 am 
Offline
User avatar

Joined: Sat Sep 07, 2013 2:59 pm
Posts: 1904
Alright, I created a bug report for it:

https://github.com/cc65/cc65/issues/900

_________________
Available now: My game "City Trouble".
Website: https://megacatstudios.com/products/city-trouble
Trailer: https://youtu.be/IYXpP59qSxA
Gameplay: https://youtu.be/Eee0yurkIW4
German Retro Gamer article: http://i67.tinypic.com/345o108.jpg


Top
 Profile  
 
 Post subject: Re: cc65 versions
PostPosted: Thu May 16, 2019 1:33 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 967
Sorry, I think you misread my post. I meant "send some code to the cc65 project", not to me ;) Though I may be available for paid cc65 work, depending on my workload.


Top
 Profile  
 
 Post subject: Re: cc65 versions
PostPosted: Thu May 16, 2019 2:56 am 
Offline
User avatar

Joined: Sat Sep 07, 2013 2:59 pm
Posts: 1904
Yes, I know, but I wanted to make sure that this is actually a bug, that's why I put it here first for evaluation before opening a bug report.

_________________
Available now: My game "City Trouble".
Website: https://megacatstudios.com/products/city-trouble
Trailer: https://youtu.be/IYXpP59qSxA
Gameplay: https://youtu.be/Eee0yurkIW4
German Retro Gamer article: http://i67.tinypic.com/345o108.jpg


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 11 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 5 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