It is currently Mon Oct 23, 2017 11:06 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 9 posts ] 
Author Message
PostPosted: Sat Aug 05, 2017 5:26 pm 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 984
Location: Pennsylvania, USA
I'm attempting to use .blank instead of .ifnblank, so I can use it in an || expression to test if one or another macro argument is present:

Code:
.macro my_macro source, dest, rega, regb

    .if (!.blank({rega}) || !.blank({regb}))

    ...


It doesn't seem to like this. I've attempted to use .blank in the past unsuccessfully; not sure what I'm doing wrong. So far I've been able to work around this by using .ifnblank which works right away for me. I can just repeat code and use .ifnblank twice to simulate the || expression but it'd be nicer if I could get this to work.


Last edited by GradualGames on Sun Aug 06, 2017 8:07 am, edited 1 time in total.

Top
 Profile  
 
PostPosted: Sat Aug 05, 2017 7:15 pm 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 984
Location: Pennsylvania, USA
ca65 appears to be okay with

Code:
    .if ((.blank(rega)) || (.blank(regb)))


but not if I use boolean not operators:

Code:
    .if (!(.blank(rega)) || !(.blank(regb)))


Top
 Profile  
 
PostPosted: Sat Aug 05, 2017 7:16 pm 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 984
Location: Pennsylvania, USA
But apparently if you use enough parentheses it's happy?

Code:
    .if ((!(.blank(rega))) || (!(.blank(regb))))


Top
 Profile  
 
PostPosted: Sat Aug 05, 2017 7:20 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10068
Location: Rio de Janeiro - Brazil
This also works, weirdly:
Code:
.if !(.blank({rega}) && .blank({regb}))


Top
 Profile  
 
PostPosted: Sat Aug 05, 2017 11:01 pm 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2963
Location: Tampere, Finland
The bug/feature seems not to be related to .blank, this also fails:
Code:
foo = 1
bar = 1
xyzzy = !foo || !bar
; Equivalent to: .not foo .or .not bar

This works, though:
Code:
foo = 1
bar = 1
xyzzy = !foo || (!bar)
; Equivalent to: .not foo .or (.not bar)

I think in the first case it might be thinking that only the ".not" is the argument to ".or", and then gets confused when it's not a proper expression. Surprising to see such a trivial expression fail.

EDIT: I've reported this in the cc65 issue tracker: https://github.com/cc65/cc65/issues/474

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


Top
 Profile  
 
PostPosted: Sun Aug 06, 2017 6:53 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2963
Location: Tampere, Finland
Looks like this extremely unintuitive behavior is by design (explained in the issue).

Can't help but wonder why ! was given the lowest possible precedence. (Compare to, e.g., C, where ! and ~ have equal precedence.)

The moral of the story, I guess, is to always use parenthesis with ! and .not. Otherwise you end up with such fun behavior like !foo && bar being equal to !(foo && bar)

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


Top
 Profile  
 
PostPosted: Sun Aug 06, 2017 8:03 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19122
Location: NE Indiana, USA (NTSC)
! in ca65 is even looser than not in Python, where not is just tighter than and and or. But either one is a huge jump from ! in C++, which is as tight as all the other prefix unary operators (such as - ++ * & (int) sizeof).


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

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10068
Location: Rio de Janeiro - Brazil
thefox wrote:
Looks like this extremely unintuitive behavior is by design

That seems somewhat common for ca65. Just one more weirdness we have to watch out for, then.


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

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2963
Location: Tampere, Finland
tokumaru wrote:
thefox wrote:
Looks like this extremely unintuitive behavior is by design

That seems somewhat common for ca65. Just one more weirdness we have to watch out for, then.

Yeah, I can tolerate many of the quirks (more so the ones where I know there's a good bit of implementation complexity), but there are quite a few quirks now that really annoy me, mainly the ones which just seem like bad design decisions. This is one of them. Another is the one where zeropage variables may get absolute addressing depending on whether they are scoped or not. Macro variables not being local to the macro by default is a third one. I'm sure there were a few others that I can't remember right now as well.

Makes forking all that more tempting...

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


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: lidnariq 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