Searching \ for 'MPLAB-C compiler quirk ?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/languages.htm?key=mplab
Search entire site for: 'MPLAB-C compiler quirk ?'.

Truncated match.
PICList Thread
'MPLAB-C compiler quirk ?'
1996\06\18@190306 by Kalle Pihlajasaari

flavicon
face
Hi C users,

Having just started to play around with MPLAB-C I have found that
it is a very conservative compiler in terms of making sure which
register bank it is working with and if you do not use interrupts in
one of the C8x or C6x parts then there are a lot of excess
BCF  03,5 instructions.  A minor pain that requires pruning from inside
tight loops.

A compiler option to set the page back to page 0 after visiting the
upper registers might be handy in such sitiations.  The adequate
optimiser would be able to remove extra ones if they appear in
pairs (with only 2 register pages though).

I have found something that I expect should generate useable code
but seems to have a bit of a bug, any comments.  I am including some
.LST file fragments that span all the side effects of the C code.

They are all the tail end of a do{stuff}while(condition); construct.

The 0034 address is the first instruction inside the 'do' in none
of the following variations was there any test to see if the
condition had been met.  The last one would have had a usefull
carry bit but it is not tested. It could not exit the 'do'.
All the others would have passed through the construct once.

=========
0045 0397    DECF   17                   bitCount--;
                                            } while(bitCount <> 0);
0046 2016    CALL   0016h             WaitABit();
=========
=========
0045 0397    DECF   17                   --bitCount;
                                            } while(bitCount <> 0);
0046 2016    CALL   0016h             WaitABit();
=========
0045 0397    DECF   17                       } while(--bitCount <> 0);
0046 2016    CALL   0016h             WaitABit();
=========
0045 0817    MOVF   17,W              } while(bitCount-- <> 0);
0046 0397    DECF   17
0047 3800    IORLW  00h
0048 2834    GOTO   0034h
0049 2016    CALL   0016h             WaitABit();
=========

What am I doing wrong.  I do not use c normaly but have been
pooreing over my pocket reference and have managed to find my
compiler errors without trouble.

VIVA Microchip.

Cheers
--
Kalle Pihlajasaari     spam_OUTkalleTakeThisOuTspamdata.co.za
Interface Products     Box 15775, Doornfontein, 2028, South Africa
+27 (11) 402-7750      Fax: +27 (11) 402-7751

1996\06\18@191342 by Clyde Smith-Stubbs

flavicon
face
Kalle Pihlajasaari <.....kalleKILLspamspam@spam@device.data.co.za> wrote:

> I have found something that I expect should generate useable code
> but seems to have a bit of a bug, any comments.  I am including some
> .LST file fragments that span all the side effects of the C code.

>              } while(bitCount <> 0);

If this is genuinely part of your C code, then the compiler should
have whinged. The "not equals" operator in C is != - using <> should
generate a syntax error.

Clyde

--
Clyde Smith-Stubbs       | HI-TECH Software,       | Voice: +61 7 3300 5011
clydespamKILLspamhitech.com.au      | P.O. Box 103, Alderley, | Fax:   +61 7 3300 5246
http://www.hitech.com.au | QLD, 4051, AUSTRALIA.   | BBS:   +61 7 3300 5235
----------------------------------------------------------------------------
For info on the World's best C cross compilers for embedded systems, point
your WWW browser at http://www.hitech.com.au, or email .....infoKILLspamspam.....hitech.com.au

1996\06\19@100014 by Dana Frank Raymond

flavicon
face
>A compiler option to set the page back to page 0 after visiting the
>upper registers might be handy in such sitiations.  The adequate

Well, you may try THIS if you need to squeeze more into code memory with MPC:

#pragma option j7;

Placed near the top of the source, it shuts off page selects entirely, and
generates "check page" warnings. Its quite easy to manually select pages
yourself.

This works with BC.245, and some earlier versions. I don't know if there are
any caveats with its use. ByteCraft probably doesn't support it as it seems
to have been added for testing. They told me about it when I needed to fit
more into a PIC16C84 and my code was producing 8% redundant page selects.

Use with caution, and only if absolutely required. Double check the produced
code.

Regards, Dana Frank Raymond
EraseMEdfrspam_OUTspamTakeThisOuTicom.ca

1996\06\19@120550 by fastfwd

face
flavicon
face
Kalle Pihlajasaari <PICLISTspamspam_OUTMITVMA.MIT.EDU> wrote:

> I have found something that I expect should generate useable code
> but seems to have a bit of a bug, any comments.  I am including some
> .LST file fragments that span all the side effects of the C code.
>
> The 0034 address is the first instruction inside the 'do' in none of
> the following variations was there any test to see if the condition
> had been met.
> ....
> =========
> 0045 0397    DECF   17                   bitCount--;
>                                              } while(bitCount <> 0);
> 0046 2016    CALL   0016h             WaitABit();

   Kalle:

   You've been using BASIC for too long... In C, the "not equal"
   sign is "!=", not "<>".

   -Andy

Andrew Warren - @spam@fastfwdKILLspamspamix.netcom.com
Fast Forward Engineering, Vista, California
http://www.geocities.com/SiliconValley/2499

1996\06\20@080238 by Walter Banks

picon face
{Quote hidden}

The j options in the MPC compiler are all unsupported options. There
is no garantee that they will always remain.  There are put into the
compiler for a number of reason's some for us to understand specific
issues about code generation and some in response to requests from
customers for a specific feature or option. I just checked the compiler
sources and j7 is still there. The internal name is NoBSR and it was put
into the compiler in response to Dana Raymonds request and it is used by
us to establish an absolute limit as to the amount of optimization that
can be done. (No BSR code generation but the rest of the generated code
is the same)

Walter

1996\06\20@101136 by Dana Frank Raymond

flavicon
face
>The j options in the MPC compiler are all unsupported options. There
>is no garantee that they will always remain.  There are put into the
>compiler for a number of reason's some for us to understand specific
>issues about code generation and some in response to requests from
>customers for a specific feature or option. I just checked the compiler
>sources and j7 is still there. The internal name is NoBSR and it was put
>into the compiler in response to Dana Raymonds request and it is used by
>us to establish an absolute limit as to the amount of optimization that
>can be done. (No BSR code generation but the rest of the generated code
>is the same)
>
>Walter

Hello Walter. Welcom to the PICLIST.

I didn't realize that you added that option on my request. It has come in
handy at times, as you can imagine. Yesterday I spent an hour trying to free
up a few paragraphs of code space to cram some diagnostics into a product
that just went into production. Unfortunately I couldn't use option j7.

I have to say Walter that MPC is a very good, professional grade product.
The problems can be overcome by someone willing to invest the learning time
(like myself). In my opinion It lacks only 2 things: Bugs needing repair;
and an optimization pass to remove redundant ram page selects from within
code blocks. That program I was working on filled a 16C84's code space (to
within 6 bytes) and yet MPC only gave 4 warnings when option j7 was used.

Thank you for your support over the years Walter.

Regards, Dana Frank Raymond
KILLspamdfrKILLspamspamicom.ca

More... (looser matching)
- Last day of these posts
- In 1996 , 1997 only
- Today
- New search...