Searching \ for 'hitech optimizer munching inline assembler' 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/index.htm?key=hitech+optimizer
Search entire site for: 'hitech optimizer munching inline assembler'.

Truncated match.
PICList Thread
'hitech optimizer munching inline assembler'
1999\05\25@132426 by Bob Blick

face
flavicon
face
Hi Friends,
Has anyone come up with a decent workaround for using inline
assembly in HiTech C when the optimizer screws it up? Compiling the
assembler part to a separate module without optimizing is not really a
good option(that's the recommended thing to do, and it's stupid).

For instance, if I want to count loops until pin 4 of PORTC drops and have
it drop through on overflow, I'd do this:

aa1     decfsz  _count
       btfss   7,4     ;that's portc pin 4
       goto    aa2
       goto    aa1
aa2     more stuff here...

then the optimizer gets it's hands on it and does:
aa1     decfsz  _count
       btfsc   7,4     ;note btfss is now btfsc
       goto    aa1
       more stuff here...

Needless to say it no longer has the timeout working. There is no "keep
hands off" directive.

What I've been doing is adding a nop to make space and then loading the
hex code into MPLAB and patching the code back to my original. Hack!

Anyone?

Thanks,
Bob

1999\05\25@135058 by Andy Kunz

flavicon
face
>Has anyone come up with a decent workaround for using inline
>assembly in HiTech C when the optimizer screws it up? Compiling the
>assembler part to a separate module without optimizing is not really a
>good option(that's the recommended thing to do, and it's stupid).
<snip>
>then the optimizer gets it's hands on it and does:
>aa1     decfsz  _count
>        btfsc   7,4     ;note btfss is now btfsc
>        goto    aa1
>        more stuff here...

YOu need to use NOPs to keep the optimizer away.  Either that or, like they
say, you NEED to link them after separate compilation.

>Needless to say it no longer has the timeout working. There is no "keep
>hands off" directive.

I've asked for it!  A nice "#pragma NOOPT" like other compilers have.

>What I've been doing is adding a nop to make space and then loading the
>hex code into MPLAB and patching the code back to my original. Hack!

HACK is right!

Andy

==================================================================
  Montana Design Tech Support - http://www.montanadesign.com
==================================================================

1999\05\25@175129 by paulb

flavicon
face
Bob Blick wrote:

> aa1     decfsz  _count
>         btfss   7,4     ;that's portc pin 4
>         goto    aa2
>         goto    aa1
> aa2     more stuff here...

> then the optimizer gets it's hands on it and does:
> aa1     decfsz  _count
>         btfsc   7,4     ;note btfss is now btfsc
>         goto    aa1
>         more stuff here...

 Ooh!  That's a *bad* bug.  Particularly for the "supremacy of C"
argument! ;-)
--
 Cheers,
       Paul B.

1999\05\25@185452 by Dennis Plunkett

flavicon
face
At 10:24 25/05/99 -0700, you wrote:
{Quote hidden}

<<<<<FLAME SUIT ON>>>>>>
Humm,
I see what you are doing, I have used the Hitech products for quite some
time now and niggly little things like this have poped up, but Hitech is
not alone!
I have had a look at the code that you're  after and have to ask a question:-


typedef struct {
       unsigned        b7:1;
       unsigned        b6:1;
       unsigned        b5:1;
       unsigned        b4:1;
       unsigned        b3:1;
       unsigned        b2:1;
       unsigned        b1:1;
       unsigned        b0:1;
} SFR_BITS;                     /*bit structure field to bit address some things
*/

/************
****begin***/

static SFR_BITS PORTA_BITS      @ 0x08; /*the address of the register etc*/

#define PA7     PORTA_BITS.b7
#define PA6     PORTA_BITS.b6
#define PA5     PORTA_BITS.b5
#define PA4     PORTA_BITS.b4
#define PA3     PORTA_BITS.b3
#define PA2     PORTA_BITS.b2
#define PA1     PORTA_BITS.b1
#define PA0     PORTA_BITS.b0


       What code does something like
       {
        unsigned char uc_count = 0;

               while (count--)
               {
                       if (PA4)
                               break;
               }
               more stuff here...
       }
       produce?


       you could also look at

       {
               while (PA4)
               {
                       unsigend char uc_count = 0;
                       if (!--count)
                               break;
               }
               more stuff here...
       }

       or

       {
               for (;;)
               {
               unsigned char uc_count = 0;

                       if (!PA4 || !--count)
                               break;
               }
               more stuff here...
       }

       the other versions beome a little more conviluted

Yes I understand that the "@" is not used by many compilers and I here the
"Portability" stuff, but we are dealing with embedded code here. I must say
that I do cringe when I see in-line assembly


<<<<<<FLAME SUIT OFF>>>>>>

Badly burnt
Dennis

1999\05\25@194311 by William Chops Westfield

face picon face
A compiler that runs it optimizer over inlined ASM code is BROKEN!!!!

(in a working compiler, this turns out to be one of the reasons not to
use inline ASM or (sometimes) inline C functions.  They tend to introduce
boundries that interfere with the optimizer producing optimal code.)

BillW

1999\05\26@015035 by Bob Blick

face
flavicon
face
The code these produce is not bad, just takes one more cycle and two more
words than the assembler example did. They do about the same sort of thing
as my original:

while((--count) && RC4);

which worked fine, I just wanted as tight a loop as possible for accuracy.
The extra cycle was what I chopped off with assembly, it used decfsz
whereas the C version generated a decf followed by a btfsX.

What has continually bothered me is the frustration I have each time I try
to use inline assembly and it hoses my code. Then I end up having to settle
for what the C equivalent generates or patching the hex code in MPLAB.

I was hoping someone here had figured out a better workaround. If I have to
put the assembler in a separate module with no optimization, I can do that,
but unless it's in a function, I have no idea how to do it in a way that
plants it in the middle of the program the way the inline assembly would
(and should) be.

Hey, Tjaart, does MPC keep hands off inline assembler?

Cheers,
Bob
{Quote hidden}

http://www.bobblick.com/

1999\05\26@031036 by Clyde Smith-Stubbs

flavicon
face
On Tue, May 25, 1999 at 10:24:06AM -0700, Bob Blick wrote:
> Has anyone come up with a decent workaround for using inline
> assembly in HiTech C when the optimizer screws it up? Compiling the

Why bother with a work-around? The problem here is that the optimizer
is broken, pure and simple, and needs to be fixed. It has changed the meaning
of your code, and that just won't do. If you find anything else like this,
please let us know!

In case you're interested, the problem was that the code that looked at
the btfss and saw that it could be optimized to a btfsc with one jump
removed (preserving the number of cycles is NOT an optimizer priority)
failed to look at the previous instruction, which is also a skip.

I've fixed it, and the fix will be in the next patch, due out as soon
as we've finished testing, but if you want the fix in the meantime,
email me PRIVATELY (or email spam_OUTsupportTakeThisOuTspamhtsoft.com).

> Needless to say it no longer has the timeout working. There is no "keep
> hands off" directive.

This is something that's needed - the optimizer already leaves nops alone
(figures if you put it there it must be for a reason) but a general directive
to leave alone an instruction would also be useful, and I'll get that
looked into.

Regards, Clyde

--
Clyde Smith-Stubbs               |            HI-TECH Software
Email: .....clydeKILLspamspam@spam@htsoft.com          |          Phone            Fax
WWW:   http://www.htsoft.com/    | USA: (408) 490 2885  (408) 490 2885
PGP:   finger clydespamKILLspamhtsoft.com   | AUS: +61 7 3355 8333 +61 7 3355 8334
---------------------------------------------------------------------------
HI-TECH C: compiling the real world.

1999\05\26@031653 by Clyde Smith-Stubbs

flavicon
face
On Tue, May 25, 1999 at 04:42:53PM -0700, William Chops Westfield wrote:
> A compiler that runs it optimizer over inlined ASM code is BROKEN!!!!

I used to think that, too. We've tried it both ways; some of our compilers
don't touch in-line assembler at all, but the PIC and some others do
look at it. There are some drawbacks either way, but in general we've
been happy with optimizing the user code. OF course, you have to do
it right! The issue that started this thread illustrated a bug, so
the optimizer *was* broken. I.e.

A compiler that runs its optimizer over inlined ASM code *and changes
the meaning* is BROKEN!!!!

What really puzzles me is why Bob posted this list asking for a work-around
instead of emailing us and asking for a *fix*! Quite often we find people
have worked-around bugs rather than telling us, I really don't know
why.

Regards, Clyde

--
Clyde Smith-Stubbs               |            HI-TECH Software
Email: .....clydeKILLspamspam.....htsoft.com          |          Phone            Fax
WWW:   http://www.htsoft.com/    | USA: (408) 490 2885  (408) 490 2885
PGP:   finger EraseMEclydespam_OUTspamTakeThisOuThtsoft.com   | AUS: +61 7 3355 8333 +61 7 3355 8334
---------------------------------------------------------------------------
HI-TECH C: compiling the real world.

1999\05\26@031659 by Michael Rigby-Jones

flavicon
face
Just been having a play with this....(compiled for 16F84, don't know what
you were using)

while(--count) if(RA4)break;

gives:

l3
       bcf     3,5
       btfsc   5,4
       goto    l4
l2
       decfsz  _count
       goto    l3
l4

which is very close apart from the bank switching (bcf 3,5).  This looks
like the age old problem of unnecessary bank switching, can the compiler not
be persuaded that the bcf isn't needed?

Regards

Mike Rigby-Jones


       Bob says....

{Quote hidden}

       <snip>

1999\05\26@083211 by Clyde Smith-Stubbs

flavicon
face
On Wed, May 26, 1999 at 08:15:31AM +0100, Michael Rigby-Jones wrote:

> which is very close apart from the bank switching (bcf 3,5).  This looks
> like the age old problem of unnecessary bank switching, can the compiler not
> be persuaded that the bcf isn't needed?

It's not that it's unnecessary, but that it should be moved outside
the loop. Just needs a bit more work in the optimizer. Then you
have to make sure it doesn't break anything else...

Regards, Clyde

--
Clyde Smith-Stubbs               |            HI-TECH Software
Email: clydespamspam_OUThtsoft.com          |          Phone            Fax
WWW:   http://www.htsoft.com/    | USA: (408) 490 2885  (408) 490 2885
PGP:   finger @spam@clydeKILLspamspamhtsoft.com   | AUS: +61 7 3355 8333 +61 7 3355 8334
---------------------------------------------------------------------------
HI-TECH C: compiling the real world.

1999\05\26@090720 by Bob Drzyzgula

flavicon
face
On Wed, May 26, 1999 at 05:14:57PM +1000, Clyde Smith-Stubbs wrote:
> On Tue, May 25, 1999 at 04:42:53PM -0700, William Chops Westfield wrote:
> > A compiler that runs it optimizer over inlined ASM code is BROKEN!!!!
>
> What really puzzles me is why Bob posted this list asking for a work-around
> instead of emailing us and asking for a *fix*! Quite often we find people
> have worked-around bugs rather than telling us, I really don't know
> why.

Undoubtedly this lapse was related to the mournful rarity
of companies that would immediately respond to such a
complaint. Nice to see an exception.

--Bob

--
============================================================
Bob Drzyzgula                             It's not a problem
KILLspambobKILLspamspamdrzyzgula.org                until something bad happens
============================================================

1999\05\26@100347 by Andy Kunz

flavicon
face
>
>Undoubtedly this lapse was related to the mournful rarity
>of companies that would immediately respond to such a
>complaint. Nice to see an exception.

And a public one at that.

Have you ever seen a public admission of "broke" from CCS.  Public
_anything_, come to think of it...

Andy

==================================================================
  Montana Design Tech Support - http://www.montanadesign.com
==================================================================

1999\05\26@101721 by Matt Bonner

flavicon
face
Bob Blick wrote:
>
> Hey, Tjaart, does MPC keep hands off inline assembler?
>
Here's the listing generated by MPC for an in-line assembly delay
function:

//-----------------------------------------------------------------------
                         /*
                            Clock frequency:         3.6864 MHz
                            Instruction clock:     921.6 kHz
                            Instruction duration:    1.0851 us
                            Instructions per ms:   614.4
                            Delay is in ms
                         */
                         void Delay(registerw delay)
0000                      {
                         #asm
0AF4 1283           BCF STATUS, RP0         ; 1
0AF5 00A1           MOVWF __WImage          ; 1

               DLMS2M1
                   RADIX DEC               ; Use decimal values
0AF6 30E6           MOVLW 230               ; 1
0AF7 0084           MOVWF FSR               ; 1

               DLMS2M2
0AF8 0000           NOP                     ; 1
0AF9 0B84           DECFSZ FSR              ; 1
0AFA 2AF8           goto  DLMS2M2           ; 2

0AFB 0BA1           DECFSZ __WImage         ; 1
0AFC 2AF6           goto DLMS2M1            ; 2
                         #endasm
0AFD 0008       RETURN               }

//-----------------------------------------------------------------------

As far as I can see, MPC didn't touch the assembly.  This might be
because of an option setting, though.

--Matt

1999\05\26@104216 by Tjaart van der Walt

flavicon
face
Matt Bonner wrote:
>
> Bob Blick wrote:
> >
> > Hey, Tjaart, does MPC keep hands off inline assembler?

As far as I know. I'll check tomorrow or so. We are moving
office, (dread, fear, damnation) so I will have to get to it later.

I've been using inline asy in MPC for (quite) a while without
problems. I have alsways assumed that a compiler wouldn't
(shouldn't) touch it.

Lazy bum that I am, I usually put it in a procedure, so I won't
have to worry about banking too much. There - I admitted it.

--
Friendly Regards          /"\
                         \ /
Tjaart van der Walt        X  ASCII RIBBON CAMPAIGN
RemoveMEtjaartTakeThisOuTspamwasp.co.za  / \ AGAINST HTML MAIL
|--------------------------------------------------|
|             Cellpoint Systems SA                 |
|             http://www.cellpt.com                |
|--------------------------------------------------|
|     http://www.wasp.co.za/~tjaart/index.html     |
|          WGS-84 : 26¡10.52'S 28¡06.19'E          |
|--------------------------------------------------|

1999\05\26@104436 by Tjaart van der Walt

flavicon
face
Andy Kunz wrote:
>
> >
> >Undoubtedly this lapse was related to the mournful rarity
> >of companies that would immediately respond to such a
> >complaint. Nice to see an exception.
>
> And a public one at that.
>
> Have you ever seen a public admission of "broke" from CCS.  Public
> _anything_, come to think of it...

Hehehe. After all the flack they took a while ago, I am
not surprised...

BTW has anybody else noticed a distinct drop in the number
of un/subscribe messages?

--
Friendly Regards          /"\
                         \ /
Tjaart van der Walt        X  ASCII RIBBON CAMPAIGN
spamBeGonetjaartspamBeGonespamwasp.co.za  / \ AGAINST HTML MAIL
|--------------------------------------------------|
|             Cellpoint Systems SA                 |
|             http://www.cellpt.com                |
|--------------------------------------------------|
|     http://www.wasp.co.za/~tjaart/index.html     |
|Voice: +27-(0)11-622-8686  Fax: +27-(0)11-622-8973|
|          WGS-84 : 26¡10.52'S 28¡06.19'E          |
|--------------------------------------------------|

1999\05\26@115643 by Bob Blick

face
flavicon
face
On Wed, 26 May 1999, Clyde Smith-Stubbs wrote:
> What really puzzles me is why Bob posted this list asking for a work-around
> instead of emailing us and asking for a *fix*! Quite often we find people
> have worked-around bugs rather than telling us, I really don't know
> why.

It turns out that the support person kept this from Clyde when I reported
it last year, sorry to drag you through the mud, and thanks for the
clarification and fast response.

Friendly regards,
Bob

1999\05\26@164852 by Clyde Smith-Stubbs

flavicon
face
On Wed, May 26, 1999 at 08:54:33AM -0700, Bob Blick wrote:
>
> It turns out that the support person kept this from Clyde when I reported
> it last year, sorry to drag you through the mud, and thanks for the
> clarification and fast response.

I checked on it, and I think what happened was the support guy didn't look
hard enough to see there was an actual bug, and Bob was too polite to
ask him to look again. Anyway, it's been interesting - all the
suggestions and comments from various people have been noted, and so far
the improvements have been:

1) optimizer doesn't break this code example any more;
2) code generator will use decfsz for equivalent C code
3) bank bit settings are optimized out of the loop
4) suggestion for "hands-off" flag is being looked at to implement.

Cheers, Clyde

--
Clyde Smith-Stubbs               |            HI-TECH Software
Email: TakeThisOuTclydeEraseMEspamspam_OUThtsoft.com          |          Phone            Fax
WWW:   http://www.htsoft.com/    | USA: (408) 490 2885  (408) 490 2885
PGP:   finger RemoveMEclydespamTakeThisOuThtsoft.com   | AUS: +61 7 3355 8333 +61 7 3355 8334
---------------------------------------------------------------------------
HI-TECH C: compiling the real world.

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