Jump to content
Sign in to follow this  
edt

Bit/array Indexes On Expressions

Recommended Posts

The "reg.bit_index" and "array[index]" forms both require that the source is a symbol and not a derived expression. Consequently, lines of code like these cause problems:

my_bit = (my_reg + 1).5;
my_val = (my_bit ? arr1 : arr2)[2];

Bit indexes aren't standard C anyway, so I can't say anything about their specification, but I specifically tried the array-index-of-expression case in GCC and it worked as expected. I think this would be a fairly straightforward change to the grammar to support this syntax. Could it be done, or is there a reason it shouldn't be?

Share this post


Link to post
Share on other sites

Seems like a operator priority issue, its probably trying to evaluate the dot

operator before the brackets, which is most cases makes sense.

ie. blah = array.5 + (red.2 - green.4);

 

In that example the dots would have to be resolved before the brackets.

But your test/example is equally valid and should probably be supported,

it would require another presidence rule that checks for brackets before

a dot operator i'd expect.

 

Semi-related and of interesting note, the opposite side poses no issue.

ie. blah = array.x; or blah = array.(x+3);

As from common itteration loops.

Share this post


Link to post
Share on other sites
it would require another presidence rule that checks for brackets before

a dot operator i'd expect.

Parentheses should have the highest precedence, so I don't think it's anything to do with precedence. Although, I found that some cases work with struct member accesses and not with bit indexes (both use '.' operator), so maybe it's not with the grammar, either.

 

Semi-related and of interesting note, the opposite side poses no issue.

ie.  blah = array.x; or blah = array.(x+3);

As from common itteration loops.

Good to know. I always thought I'd already tried that with no luck.

Share this post


Link to post
Share on other sites

edt,

Semi-related and of interesting note, the opposite side poses no issue.

ie.  blah = array.x; or blah = array.(x+3);

As from common itteration loops.

Good to know. I always thought I'd already tried that with no luck.

Note:

blah = array.(x+3);

Will not compile!

 

Regards

Dave

Share this post


Link to post
Share on other sites
edt,
Semi-related and of interesting note, the opposite side poses no issue.

ie.  blah = array.x; or blah = array.(x+3);

As from common itteration loops.

Good to know. I always thought I'd already tried that with no luck.

Note:

blah = array.(x+3);

Will not compile!

Thanks, I was going to mention the same thing, but then I realized he might mean the second would compile *if the first* would (in other words, if x is a constant). I did verify that "blah = var.(2+3)" compiles. Of course, calling it "array" is strange because it doesn't make much sense to use the dot operator on an array, but I think that was just a misnomer.

Share this post


Link to post
Share on other sites

Join the conversation

You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

×
×
  • Create New...