Searching \ for '[PIC]: Hi-Tech C Compile confusion' 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=c
Search entire site for: 'Hi-Tech C Compile confusion'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Hi-Tech C Compile confusion'
2001\03\14@180901 by Sam Linder

flavicon
face
Given the following code snippets, would someone be nice enough to explain
why method-1 gets a fixup overflow error, but method-2 does not. I
understand why method-1 generates an error, but do not understand how
method-2 fixes it when both "movwf  (_dlyctr ^0x80)" and "movwf  _dlyctr"
compile to 00B4. (Setting bank select bits in the STATUS register to bank-1
or not makes no difference)

bank1 unsigned char dlyctr;  (compiler places "dlyctr" at 0xB4)

method-1
#asm
       movlw       0x03
       movwf       _dlyctr
       decfsz      _dlyctr,f
#endasm

method-2
#asm
       movlw       0x03
       movwf       (_dlyctr ^0x80)
       decfsz      (_dlyctr^0x80),f
#endasm


Sam....
"May the roof over your head
never leak until it rains gold."

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\03\14@183120 by Andrew Warren

flavicon
face
Sam Linder <spam_OUTPICLISTTakeThisOuTspamMITVMA.MIT.EDU> wrote:

> I understand why method-1 generates an error, but do not
> understand how method-2 fixes it when both "movwf  (_dlyctr ^0x80)"
> and "movwf _dlyctr" compile to 00B4.
> ....
> bank1 unsigned char dlyctr;  (compiler places "dlyctr" at 0xB4)
>
> method-1
> #asm
>         movlw       0x03
>         movwf       _dlyctr
>         decfsz      _dlyctr,f
> #endasm
>
> method-2
> #asm
>         movlw       0x03
>         movwf       (_dlyctr ^0x80)
>         decfsz      (_dlyctr^0x80),f
> #endasm

Sam:

The first example compiles to "movwf 0xB4".  Since the "movwf"
instruction takes a 7-bit argument and 0xB4 requires 8 bits, this
causes an error.  The second example compiles to "movwf 0x44".  0x44
fits in 7 bits, so no error is generated.

Take a look at the Instruction Summary in the datasheet for whatever
PIC you're using; you'll see how the bits in the instruction are
assigned, and it'll all make sense.

-Andy


=== Andrew Warren --- .....aiwKILLspamspam@spam@cypress.com
=== IPD Systems Engineering, CYSD
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\03\14@184343 by Barry Gershenfeld

picon face
At 03:08 PM 3/14/01 -0800, you wrote:
{Quote hidden}

Assuming you understand that (_dlyctr^0x80) should evaluate to 0x34,
then you probably looked at the compiled code and saw 0xB4, but
didn't realize that it's the movwf opcode that provided the "extra"
bit.  It's just a lookalike.

 movwf = 00 0000 1xxx xxxx
 0x34  =          011 1000
              ----------------
"0xB4" = 00 0000 1011 1000

Barry

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\03\14@185005 by Sam Linder

flavicon
face
Andy & Barry:
I understand what you're saying. I have looked at the movwf instruction in
the mid-range manual and I completely understand how the bits are used. But
it looks to me as if the compiler is mapping the byte to bank-0 by the
"^0x80" add-on and that ain't particularly desirable. Or am I missing
something?
       Sam....

{Original Message removed}

2001\03\14@185626 by Andrew Warren

flavicon
face
Sam Linder <PICLISTspamKILLspamMITVMA.MIT.EDU> wrote:

> I understand what you're saying. I have looked at the movwf
> instruction in the mid-range manual and I completely understand how
> the bits are used. But it looks to me as if the compiler is mapping
> the byte to bank-0 by the "^0x80" add-on and that ain't particularly
> desirable. Or am I missing something?

   Sam:

   The PIC DOES want all file-register accesses to be mapped as
   though the file register is in Bank 0.  What you're missing is
   that the high-order bits of the file-register address (the bits
   which determine whether the register is in Bank 0, 1, 2, or 3)
   must be set SEPARATELY, by adjusting the bank-select bits
   appropriately.

   -Andy


=== Andrew Warren --- .....aiwKILLspamspam.....cypress.com
=== IPD Systems Engineering, CYSD
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\03\14@192149 by Sam Linder

flavicon
face
Andy:
This is the complete listing of the affected routine:
#define wout 0
bank1 unsigned char dlyctr;  (compiler places "dlyctr" at 0xB4)

// DAL1WR
// Bit Write (generates write-1 or write-0 time slot)
// The bit to be sent is passed via Carry
#asm
       bcf         STATUS,RP0
       bcf         STATUS,RP1
dal1wr
       bcf         PORTA,wout
       movlw       0x03
       bsf         STATUS,RP0
       movwf       _dlyctr
dal1wr1
       decfsz      _dlyctr,f
       goto        dal1wr1
       bcf         STATUS,RP0
       btfsc       STATUS,C
       bsf         PORTA,wout
       movlw       0x14
       bsf         STATUS,RP0
       movwf       _dlyctr
dal1wr2
       decfsz      _dlyctr,f
       goto        dal1wr2
       bcf         STATUS,RP0
       bsf         PORTA,wout
       return
#endasm

As you can see, I have set the bank bits appropriately. However, the
compiler still gives me the following complaint:
Error[000] ag571wre.obj 120 : Fixup overflow in expression (loc 0x2212
(0x2208+10), size 1, value 0xB4)
Error[000] ag571wre.obj 120 : Fixup overflow in expression (loc 0x2214
(0x2208+12), size 1, value 0xB4)
Error[000] ag571wre.obj 120 : Fixup overflow in expression (loc 0x2222
(0x2208+26), size 1, value 0xB4)
Error[000] ag571wre.obj 120 : Fixup overflow in expression (loc 0x2224
(0x2208+28), size 1, value 0xB4)
Error[000] ag571wre.rlf 2464 : Fixup overflow in expression (loc 0x74
(0x74+0), size 1, value 0xB4)
Error[000] ag571wre.rlf 2470 : Fixup overflow in expression (loc 0x74
(0x74+0), size 1, value 0xB4)
Error[000] ag571wre.rlf 2488 : Fixup overflow in expression (loc 0x74
(0x74+0), size 1, value 0xB4)
Error[000] ag571wre.rlf 2494 : Fixup overflow in expression (loc 0x74
(0x74+0), size 1, value 0xB4)
Exit status = 1

As I said before, am I missing something or am I just fighting a
recalcitrant compiler?
(BTW, this routine, without the bank selecting added by me, is taken
directly from the book Serial PIC'n)
       Sam....

{Original Message removed}

2001\03\14@195147 by Andrew E. Kalman

flavicon
face
Re:

>As I said before, am I missing something or am I just fighting a
>recalcitrant compiler?

It may be worth your while to write the equivalent function directly
in C, and look at the compiler's assembly-language output. or, put
another way, write some C code that causes the compiler to uses
movwf, and then copy that style.

My success with PIC C when writing assembly routines (I do it only
rarely) is to mimic exactly what I see in the .LST outputs of the
compiler.

I believe you'll find that _all_ movwf instructions that are
compiler-generated apply a mask to the argument -- without the "exact
same thinking" the compiler won't be happy with your assembly-level
stuff.

Out of curiosity, why write this in assembly at all?
--

 ______________________________________
  Andrew E. Kalman, Ph.D.   EraseMEaekspam_OUTspamTakeThisOuTpumpkininc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\03\14@195742 by Barry Gershenfeld

picon face
>Andy & Barry:
>I understand what you're saying. I have looked at the movwf instruction in
>the mid-range manual and I completely understand how the bits are used. But
>it looks to me as if the compiler is mapping the byte to bank-0 by the
>"^0x80" add-on and that ain't particularly desirable. Or am I missing
>something?
>        Sam....

Well it *is* compiling it as though it were bank 0.  But that's
just the compiler.  When the PIC is actually running, that
instruction may hit one of the other banks, depending on
which bank bits in the status register have been previously
set.  That's a separate operation, and since it can appear
anywhere in the program, the compiler can't know which
bank bits are set at any given time.    Indeend,  you could
write a program where the same instruction hit a different
bank each time (but I wouldn't post the code here! :)

Barry

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\03\14@200958 by Andrew E. Kalman

flavicon
face
Sam.

I may have misread your problem slightly-- you have a link-time
problem first and foremost. Usually, fixup errors that occur when you
have obviously not exhausted the PIC's RAM are due to conflicting
definitions (bank-wise) of a variable, or because a variable's
address has an illegal high bit in it that's inconsistent with the
bank PIC C thinks it should be in.  That's the reason for the complex
mask that the assembler applies to file register arguments, and
that's where I would look to solve your problem.
--

 ______________________________________
  Andrew E. Kalman, Ph.D.   aekspamspam_OUTpumpkininc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\03\14@201429 by Andrew Warren

flavicon
face
Sam Linder <@spam@PICLISTKILLspamspamMITVMA.MIT.EDU> wrote:

> I have set the bank bits appropriately. However, the compiler still
> gives me the following complaint: Error[000] ag571wre.obj 120 :
> Fixup overflow in expression (loc 0x2212 (0x2208+10), size 1, value
> 0xB4) [etc...]

Sam:

The compiler can't analyze your embedded assembly code to see whether
you've set the bank bits appropriately in every path to every
instruction that accesses a Bank1 register, so setting the bank bits
won't keep the compiler from generating the error.

Besides... Strictly speaking, trying to put an 8-bit number in a 7-
bit opcode field is an error no matter WHAT you've done with the bank
bits.

I don't think the compiler is doing anything wrong.

-Andy


=== Andrew Warren --- KILLspamaiwKILLspamspamcypress.com
=== IPD Systems Engineering, CYSD
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\03\14@203120 by Sam Linder

flavicon
face
Andrew K, Barry G, Andrew W:
Thanks for all your input gentlemen. I think what I have here is an attempt
to mix apples and oranges. When I generate code strictly in C, the compiler
generates the appropriate assembly output (including setting bank bits and
adding "^0x80" as needed).

Trying to use ASM code based on a variable that was defined in C was my
basic error.

If I was writing this routine strictly in C, the issue would not have
arisen. If I was writing this routine strictly in assembly, I would never
have tried stuffing an 8-bit address in a 7-bit instruction. Lesson learned.

Again, thanks for all the advice.

       Sam....


{Original Message removed}

2001\03\14@214825 by Tony Nixon

flavicon
picon face
Sam Linder wrote:
> As you can see, I have set the bank bits appropriately. However, the
> compiler still gives me the following complaint:
> Error[000] ag571wre.obj 120 : Fixup overflow in expression (loc 0x2212
> (0x2208+10), size 1, value 0xB4)

0xB4 cannot fit into any DECFSZ, MOVWF instructions because according to
the assembler it's value is > 0x7F.

If the assembler truncates the value to 7 bits, then all works anyway
because the RP0 bit is set correctly. A warning may be given also.

If the assembler does not truncate invalid values, then errors may be
produced.

--
Best regards

Tony

mICro's
http://www.picnpoke.com
RemoveMEsalesTakeThisOuTspampicnpoke.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


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