I'm using CC65 2.17.
I may have found a bug and just want to confirms if other people may have ended up on it. I can define without issue the pragma at the top of a file for code-name, data-name, rodata-name but cannot for bss-name.
The only way I was to make it work is if I do a push/pop around the group of variables that I want to put in that segment but reading the documentation, it should work like other xxxx-name pragma.
Did anybody had this issue before? Before reporting it as a bug, I just want to make sure if I may have missed something but this pragma is so obvious that it should work like the other ones.
Thanks in advance for any information on the subject.
CC65: Cannot define #pragma bss-name for scope of file
Moderator: Moderators
Re: CC65: Cannot define #pragma bss-name for scope of file
This is what I used
#pragma bss-name(push, "ZEROPAGE" )
all variables below that ended up in the zeropage segment.
#pragma bss-name(push, "ZEROPAGE" )
all variables below that ended up in the zeropage segment.
nesdoug.com -- blog/tutorial on programming for the NES
Re: CC65: Cannot define #pragma bss-name for scope of file
This is how I'm doing it a the moment but from the documentation, you shouldn't need to do that. What you should be able to do, like all other xxxx-name pragma is at the top of the file, you just write:
and it will be applied to the complete file. It works for code, data, rodata without issue. You can use push but what it means is from the point where you "push" that segment, you start a scope where all variable will be in that segment then you "pop" to go back to the original BSS. It may have worked by writing push at the top but it was never pop back. Still, you shouldn't have had to do that, which mean there may be a bug in cc65 after all since you had to do it that way.
Code: Select all
#pragma bss-name ("my-custom-bss")
Re: CC65: Cannot define #pragma bss-name for scope of file
Just chiming in to say that I've run into this also. I had no idea if it was a bug vs whether I was just misreading the docs and "doing it wrong".
My games: http://www.bitethechili.com
Re: CC65: Cannot define #pragma bss-name for scope of file
I don't think you misread the documentation. It says it word for word:
So we found a bug then. I guess I will see if I can open an issue on the subject, if it not already exist. At the least the workaround for now is to write push to do it and maybe ignoring pop is not an issue (but I'm doing pop anyway, just in case). Still, it is unclear what happens if you don't since the only doc on the subject that I found is:
Since it says that it "understand the push and pop parameters" and example is without push, it should work like all other xxxx-name pragma.7.2 #pragma bss-name ([push,] <name>)
This pragma changes the name used for the BSS segment (the BSS segment is used to store uninitialized data). The argument is a string enclosed in double quotes.
Note: The default linker configuration file does only map the standard segments. If you use other segments, you have to create a new linker configuration file.
Beware: The startup code will zero only the default BSS segment. If you use another BSS segment, you have to do that yourself, otherwise uninitialized variables do not have the value zero.
The #pragma understands the push and pop parameters as explained above.
Example:
#pragma bss-name ("MyBSS")
So we found a bug then. I guess I will see if I can open an issue on the subject, if it not already exist. At the least the workaround for now is to write push to do it and maybe ignoring pop is not an issue (but I'm doing pop anyway, just in case). Still, it is unclear what happens if you don't since the only doc on the subject that I found is:
The "value may later be restored" which seems to means it's not necessary but doesn't mention what is the scope of the push/pop mechanism. My educated guess would be file scope since you have to set it on every file but it's not mentioned.7. #pragmas
The compiler understands some pragmas that may be used to change code generation and other stuff. Some of these pragmas understand a special form: If the first parameter is push, the old value is saved onto a stack before changing it. The value may later be restored by using the pop parameter with the #pragma.
- rainwarrior
- Posts: 8734
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: CC65: Cannot define #pragma bss-name for scope of file
The scope is called a "translation unit".
You could think of it as a single file, but it's more than that because you can #include other files, so the "translation unit" is really the whole expanded thing with all the text from #include. (...and if you use a #pramga in an included file, it will still be in effect after the #include line.)
You could think of it as a single file, but it's more than that because you can #include other files, so the "translation unit" is really the whole expanded thing with all the text from #include. (...and if you use a #pramga in an included file, it will still be in effect after the #include line.)
Re: CC65: Cannot define #pragma bss-name for scope of file
Translation unit, got it.
I usually avoid putting pragma in include unless there is no other way since it could have impact based on where it is included.
So if the pragma is active for the translation unit and at the end was never pop back, I guess there is no issue and the value from the stack is just discarded.
I checked the issues on github and there seems to be none with that problem (there was one in 2017 regarding bss-name but it's not the same problem). I looked at the code and I'm not familiar enough to find the cause unless I would debug it but one thing that got me concerned is that when the segment is updated, there is one special case for BSS-NAME only, which could have some side effect (and could be related) but unless I debug it, it's just a very wild guess.
I usually avoid putting pragma in include unless there is no other way since it could have impact based on where it is included.
So if the pragma is active for the translation unit and at the end was never pop back, I guess there is no issue and the value from the stack is just discarded.
I checked the issues on github and there seems to be none with that problem (there was one in 2017 regarding bss-name but it's not the same problem). I looked at the code and I'm not familiar enough to find the cause unless I would debug it but one thing that got me concerned is that when the segment is updated, there is one special case for BSS-NAME only, which could have some side effect (and could be related) but unless I debug it, it's just a very wild guess.