Jump to content
Sign in to follow this  
davidb

Problems With Makeshort Macro

Recommended Posts

Hi,

 

BUG DESCRIPTION: There appears to be a minor problem with the MAKESHORT macro when used within parenthesis such as when used with 'if' or 'if-else'. This was discovered when tidying code.

 

The following simple example shows various ways of using the macro, all of which I believe should be valid C. Some compile OK and some fail. The only common factor appears to be that if, for any reason, MAKESHORT is used within parenthesis then at least the right hand one must be on a new line.

 

REPRODUCIBLE: 100%

IDE: V6.84

COMPILER: BoostC (Using aggressive optimisation)

TARGET: 16F887

OS: XP Pro SP2

 

while(1)
{
bit TRUE = 1;
ushort x;
uchar y;
uchar z;

if(TRUE)
{
	MAKESHORT(x, y, z);		// OK
}

if(TRUE) MAKESHORT(x, y, z);		// OK	

if(TRUE)
{
	MAKESHORT(x, y, z);		// OK
}
else
{
	x = 0;
}

if(TRUE) {MAKESHORT(x, y, z);}		// Fails

if(TRUE) MAKESHORT(x, y, z);		// Fails
else x = 0;

if(TRUE) {MAKESHORT(x, y, z);		// OK!	
}
else x = 0;	
}

 

This is not really a major problem but maybe an interesting one to add to the list.

 

Thanks

 

DavidB

Share this post


Link to post
Share on other sites
Hi,

 

BUG DESCRIPTION: There appears to be a minor problem with the MAKESHORT macro when used within parenthesis such as when used with 'if' or 'if-else'. This was discovered when tidying code.

 

The following simple example shows various ways of using the macro, all of which I believe should be valid C. Some compile OK and some fail. The only common factor appears to be that if, for any reason, MAKESHORT is used within parenthesis then at least the right hand one must be on a new line.

 

REPRODUCIBLE: 100%

IDE: V6.84

COMPILER: BoostC (Using aggressive optimisation)

TARGET: 16F887

OS: XP Pro SP2

 

while(1)
{
bit TRUE = 1;
ushort x;
uchar y;
uchar z;

if(TRUE)
{
	MAKESHORT(x, y, z);		// OK
}

if(TRUE) MAKESHORT(x, y, z);		// OK	

if(TRUE)
{
	MAKESHORT(x, y, z);		// OK
}
else
{
	x = 0;
}

if(TRUE) {MAKESHORT(x, y, z);}		// Fails

if(TRUE) MAKESHORT(x, y, z);		// Fails
else x = 0;

if(TRUE) {MAKESHORT(x, y, z);		// OK!	
}
else x = 0;	
}

 

This is not really a major problem but maybe an interesting one to add to the list.

 

Thanks

 

DavidB

 

This is because MAKESHORT uses asm statements which treat newlines and semicolons differently to C. An asm statement ends at the end of a line and a semicolon introduces an asm comment. So, MAKESHORT(...);} is seen as MAKESHORT(...) followed by a comment containing the } (and anything up to the end of the line as well)!

 

In addition, this probably doesn't do what you think it does:

 

	if(some_variable) MAKESHORT(x, y, z);		// OK

 

Only the first asm statement of MAKESHORT(...) will be controlled by the if!

 

This fails due to there being more than one asm statement in MAKESHORT(...)

 

	if(TRUE) MAKESHORT(x, y, z);		// Fails
else x = 0;

 

Put MAKESHORT(...) on a line of its own inside {} and you will be fine.

 

I don't see a way of 'fixing' MAKESHORT as you can't embed newlines in #define macros, so it would probably be a good idea to add a note to the manual for all the 'functions' that are implemented in macros with asm statements that they should appear on a line on their own and not be controlled by an if or else unless enclosed in {}s and that anything following them on the same line will be treated as an asm comment, throw an "error in built-in assembly" error, or do something totally unexpected if it happens to be valid inline assembly.

 

Orin.

Share this post


Link to post
Share on other sites

Orin,

 

I didn't bother spending time delving into the macro itself but I understand what you are saying and guessed thats what was causing the problem.

 

I really posted it to make other people aware that a problem exists if you try to take short cuts in writing the code. In this case the code fails to compile so at least it is highlighted, although the error messages are somewhat obscure. (if one thing really needs improving in the compiler it is the error reporting!)

 

In the case of the bit manipulation macro problems I posted previously, the code compiles but does not work and that can be really frustrating. Finding that some of these macros only work correctly with char types is annoying but not the end of the world. It is just that the manual didn't indicate that a problem might exist and time was wasted trying to understand why the program didn't work.

 

I think if macros are provided then all restrictions when using them should be made clear in the manual. The current issue of the manual seems to be lagging somewhat on the compiler version. Can I suggest Dave & Pavel that you publish an addendum and update it as new problems, restrictions, fixes etc are found until such time that you can find time to update the whole manual. It would also make life easier for newbies as well if there was just one place to look rather than having to search the forum for an obscure problem.

 

Having said all of that, I am very impressed with this value for money compiler as well as the support provided and just hope that it continues to improve. Well done!

 

Davidb

Share this post


Link to post
Share on other sites
I really posted it to make other people aware that a problem exists if you try to take short cuts in writing the code. In this case the code fails to compile so at least it is highlighted, although the error messages are somewhat obscure. (if one thing really needs improving in the compiler it is the error reporting!)

 

That's also why I posted the results of my 'research' into the problem.

 

In the case of the bit manipulation macro problems I posted previously, the code compiles but does not work and that can be really frustrating. Finding that some of these macros only work correctly with char types is annoying but not the end of the world. It is just that the manual didn't indicate that a problem might exist and time was wasted trying to understand why the program didn't work.

 

Unfortunately, in some cases, the MAKESHORT() code compiles without error, but won't work correctly - those controlled by an if without an intervening '{'.

 

I think if macros are provided then all restrictions when using them should be made clear in the manual. The current issue of the manual seems to be lagging somewhat on the compiler version. Can I suggest Dave & Pavel that you publish an addendum and update it as new problems, restrictions, fixes etc are found until such time that you can find time to update the whole manual. It would also make life easier for newbies as well if there was just one place to look rather than having to search the forum for an obscure problem.

 

Yes, these issues do need to be made clear in the manual.

 

Having said all of that, I am very impressed with this value for money compiler as well as the support provided and just hope that it continues to improve. Well done!

 

I agree!

 

As for the problems with macros containing asm statements. They could mostly be avoided by allowing '}' to terminate an asm statement as well as newline or another asm statement. Then the macros could be of the form:

 

#define MACRO { asm nop asm nop }

 

There would still be a problem with:

 

if ( ... ) MACRO(...);

else

 

but that's all I can think of at the moment.

 

 

Orin.

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...