It is currently Fri Dec 15, 2017 5:23 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 7 posts ] 
Author Message
PostPosted: Sun Aug 06, 2017 9:14 am 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 1013
Location: Pennsylvania, USA
EDIT: PLEASE NOTE: This thread is somewhat redundant, and turned out to be the same issue I brought up here 5 years ago. I had a .scope ... .endscope in my macro, and this introduced the problem in places where it hadn't previously existed.

I have a macro which contains the following code:

Code:

    ins arg+1



Where ins is a 6502 instruction passed in as an argument to the macro, and arg is a symbol in zp or ram.

I noticed it is always generating absolute addressing for symbols in zp with this expression. Yet the documentation says:

"If this is not the case, and the expression contains a symbol, explicitly declared as zero page symbol (by one of the .importzp or .exportzp instructions), then the whole expression is assumed to be byte sized."

I would assume that "contains a symbol" means that the +1 shouldn't make it fail to generate a zp instruction.

To work around this, I can declare lo and hi byte for all word zp variables so I don't need the + 1. Then I successfully get zp instructions generated where I expect. But it doesn't seem like this ought to be necessary given what the documentation says.

Interestingly contrasting the performance between the two, I'm not seeing a huge savings ensuring zp instructions in these cases. I'm guessing because these macros are typically used in higher-level situations than the most performance intensive parts of my game.


Last edited by GradualGames on Tue Aug 08, 2017 8:09 am, edited 2 times in total.

Top
 Profile  
 
PostPosted: Sun Aug 06, 2017 10:01 am 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 1013
Location: Pennsylvania, USA
Perhaps this is my ticket?

http://cc65.github.io/doc/ca65.html#ss10.1

...Wow, now I'm really confused. Using this code, I'm now getting a ton of "address size unknown" errors for symbols for which I've explicitly imported them using .globalzp. What gives?


Top
 Profile  
 
PostPosted: Sun Aug 06, 2017 10:18 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2983
Location: Tampere, Finland
It's probably this annoying feature in one form or another: viewtopic.php?p=96987#p96987

Maybe you have another scope in there somewhere?

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi


Top
 Profile  
 
PostPosted: Sun Aug 06, 2017 10:23 am 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 1013
Location: Pennsylvania, USA
thefox wrote:
It's probably this annoying feature in one form or another: viewtopic.php?p=96987#p96987

Maybe you have another scope in there somewhere?


Fascinating. I just made an interesting discovery. If, inside my macro, I re-declare all my zp variables with .globalzp I don't get the .addrsize warnings.

Code:
.globalzp w0,w1,w2,w3,w4,w5,w6,w7,w8,w9,w10,w11,w12,w13,w14,w15,w16,w17,w18,w19


Now the strangest part is, if I do .include "zp.inc" at the same spot, it doesn't work. I have a .ifdef .endif in my zp.inc, but apparently ca65 won't error out if you use .globalzp more than once for the same symbol.... *edit* oddly, once I added more symbols it DOES error out for some, for some reason...man what a rabbit hole! Haha


Top
 Profile  
 
PostPosted: Sun Aug 06, 2017 10:33 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2983
Location: Tampere, Finland
GradualGames wrote:
Now the strangest part is, if I do .include "zp.inc" at the same spot, it doesn't work. I have a .ifdef .endif in my zp.inc, but apparently ca65 won't error out if you use .globalzp more than once for the same symbol.... *edit* oddly, once I added more symbols it DOES error out for some, for some reason...man what a rabbit hole! Haha

I think multiple .globalzp of the same symbol is allowed. I guess if you do it inside the macro (you probably have the macro invocation in a scope?) for the later references in the macro it knows you're referring to the .globalzp'd variable. Otherwise it returns the size as unknown because it can't know whether you're going to define a variable with the same name later in the scope.

If you have .ifdef/.endif in the macro and you have already included the file elsewhere in the compilation unit, it wouldn't be surprising that the definitions doesn't take effect. It'd be really brittle solution to rely that the header hasn't been included anywhere else before.

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi


Top
 Profile  
 
PostPosted: Sun Aug 06, 2017 11:40 am 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 1013
Location: Pennsylvania, USA
thefox wrote:
GradualGames wrote:
Now the strangest part is, if I do .include "zp.inc" at the same spot, it doesn't work. I have a .ifdef .endif in my zp.inc, but apparently ca65 won't error out if you use .globalzp more than once for the same symbol.... *edit* oddly, once I added more symbols it DOES error out for some, for some reason...man what a rabbit hole! Haha

I think multiple .globalzp of the same symbol is allowed. I guess if you do it inside the macro (you probably have the macro invocation in a scope?) for the later references in the macro it knows you're referring to the .globalzp'd variable. Otherwise it returns the size as unknown because it can't know whether you're going to define a variable with the same name later in the scope.

If you have .ifdef/.endif in the macro and you have already included the file elsewhere in the compilation unit, it wouldn't be surprising that the definitions doesn't take effect. It'd be really brittle solution to rely that the header hasn't been included anywhere else before.


I wound up stuffing the .globalzp for all my zp scratch space in a macro, and use the macro both in my zp.inc include for normal usage but also within these other macros I'm working with. It seems to be generating instructions for zp addressing as expected at least for my scratch space variables, which are under the most heavy use. I think I can live with this for now.


Top
 Profile  
 
PostPosted: Sun Aug 06, 2017 5:05 pm 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 1013
Location: Pennsylvania, USA
I was able to get rid of the repeated .globalzp hack by combining some other things I learned today. I used .local within my macros instead of .scope ... .endscope. Then, I found that I had a bunch of equates peppered in inner scopes in one of the core modules of my game (the map decoder, specifically). These equates were there basically just to access members of the map header using a struct, so I could pass them into macros without issue. Moved these equates to global scope, and now all the places I was inspecting for proper zp instruction generation appear to be working properly. Even in nested scopes in cases I've inspected, interestingly...

Total bytes saved from these macro efforts = 202. Not too shabby really.


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: Bing [Bot] 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