Sign in

username:

password:



Not a member?

Search 68hc12



Search tips

Subscribe to 68hc12



68hc12 by Keywords

68HC1 | 812A4 | 9S12DP256 | Bootloader | CodeWarrior | D60A | Debugger | DP256 | ECT | EEPROM | EVB | Flash | HC1 | HCS12 | I2C | IAR | ICC1 | Interrupts | LCD | M68KIT912DP256 | MC9S12DP256 | MC9S12DP256B | Metrowerks | Motor | MSCAN | Multilink | PLL | Quadrature | SDI | SPI | Transceiver | XFC

Ads

Discussion Groups

See Also

DSPFPGAElectronics

Discussion Groups | 68HC12 | Instruction cycle time

Join our technical discussions about Freescale Microcontrollers: M68HC12. (Freescale Semiconductor is a Subsidiary of Motorola).

Instruction cycle time - bkohan_2000 - Mar 25 9:02:00 2003

Where can I find info on instruction cycle times for the HC12?

Thanks,

B.K.


______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )


Re: Instruction cycle time - Patrick Gempeler - Mar 25 9:39:00 2003

Hello,

you can find the needed cycle per instruction in the document 'cpu12rm.pdf'. This document is avaible in the net. The time per cycle is depend to the busspeed.

I hope this help you.

Patrick

----- Original Message -----
From: bkohan_2000
To:
Sent: Tuesday, March 25, 2003 3:02 PM
Subject: [68HC12] Instruction cycle time Where can I find info on instruction cycle times for the HC12?

Thanks,

B.K. Yahoo! Groups Sponsor
ADVERTISEMENT

--------------------------------------------------------
To unsubscribe from this group, send an email to: To learn more about Motorola Microcontrollers, please visit
http://www.motorola.com/mcu Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. [Non-text portions of this message have been removed]



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

Re: Re: Instruction cycle time - Author Unknown - Mar 25 13:37:00 2003

Be careful, there are cycle count differences between the HC12 and the HCS12. These are covered in Engineering Bullitin EB376.

Regards
Dave Perreault
P&E > From: "Patrick Gempeler" <>
> Date: 2003/03/25 Tue AM 09:39:00 EST
> To: <>
> Subject: Re: [68HC12] Instruction cycle time
>
> Hello,
>
> you can find the needed cycle per instruction in the document 'cpu12rm.pdf'. This document is avaible in the net. The time per cycle is depend to the busspeed.
>
> I hope this help you.
>
> Patrick
>
> ----- Original Message -----
> From: bkohan_2000
> To:
> Sent: Tuesday, March 25, 2003 3:02 PM
> Subject: [68HC12] Instruction cycle time > Where can I find info on instruction cycle times for the HC12?
>
> Thanks,
>
> B.K. > Yahoo! Groups Sponsor
> ADVERTISEMENT >
>
> --------------------------------------------------------
> To unsubscribe from this group, send an email to: > To learn more about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu >



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

Re: Instruction cycle time - Gordon Doughman - Mar 25 15:38:00 2003


Also, be sure to add 1 additional cycle for instructions that access misaligned word data (capital 'W' in the access detail) in Flash or EEPROM (typically constant
data). Note that this doesn't include instruction fetches, code is always fetched on aligned word boundaries. The internal RAM is designed to access misaligned word
data in a single cycle.

wrote:

> Be careful, there are cycle count differences between the HC12 and the HCS12. These are covered in Engineering Bullitin EB376.
>
> Regards
> Dave Perreault
> P&E
>
> >
> > From: "Patrick Gempeler" <>
> > Date: 2003/03/25 Tue AM 09:39:00 EST
> > To: <>
> > Subject: Re: [68HC12] Instruction cycle time
> >
> > Hello,
> >
> > you can find the needed cycle per instruction in the document 'cpu12rm.pdf'. This document is avaible in the net. The time per cycle is depend to the busspeed.
> >
> > I hope this help you.
> >
> > Patrick
> >
> > ----- Original Message -----
> > From: bkohan_2000
> > To:
> > Sent: Tuesday, March 25, 2003 3:02 PM
> > Subject: [68HC12] Instruction cycle time
> >
> >
> > Where can I find info on instruction cycle times for the HC12?
> >
> > Thanks,
> >
> > B.K.
> >
> >
> > Yahoo! Groups Sponsor
> > ADVERTISEMENT
> >
> >
> >
> >
> > --------------------------------------------------------
> > To unsubscribe from this group, send an email to:
> >
> >
> > To learn more about Motorola Microcontrollers, please visit
> > http://www.motorola.com/mcu
> >
> >
> >
> >
> >
> > --------------------------------------------------------
> To unsubscribe from this group, send an email to: > To learn more about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu >

--
===============================================================
Gordon Doughman Ph: 937-438-6811
Motorola Semiconductor Fax: 937-434-7457
Field Applications Engineer Pager: 800-759-8352 Pin: 1304089
Suite 175
3131 Newmark Drive
Miamisburg, OH 45342

Check out my HC12 book at:
http://www.rtcbooks.com/programming.php



______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

Metrowerks Disassembly Obfuscation - Help! - Paul Johnson - Mar 25 19:43:00 2003

Hi Metrowerks gurus,

I've disassembled a module in my program where I think there may be a
problem. I have include the relevant section below, which has a
construction that I cannot understand. Can someone explain it to me? The
problems are described inline, starting with ***.

143: char * parseLong(char * str,long * data)
parseLong:
00000243 3B PSHD
145: str = skipWhitespace(str);
00000244 EC84 LDD 4,SP
00000246 0734 BSR *+54 ;abs = 027C

*** I have to assume that there is a call of skipWhitespace at 027C, but
wait until you see what's actually there (below)

146: if ((*str == ',') || !(*str)) {
00000248 2704 BEQ *+6 ;abs = 024E
0000024A E600 LDAB 0,X
0000024C 2610 BNE *+18 ;abs = 025E
147: *data = 0;
0000024E EE80 LDX 0,SP
00000250 C7 CLRB
00000251 87 CLRA
00000252 6C02 STD 2,X
00000254 6C00 STD 0,X
148: if (*str) str++;
00000256 EE84 LDX 4,SP
00000258 E600 LDAB 0,X
0000025A 271C BEQ *+30 ;abs = 0278
0000025C 2017 BRA *+25 ;abs = 0275
151: *data = str8tolong(str);
0000025E B754 TFR X,D
00000260 160000 JSR str8tolong
00000263 160000 JSR ILSEXT
00000266 ED80 LDY 0,SP
00000268 6C42 STD 2,Y
0000026A 6E40 STX 0,Y
152: str+=8;
0000026C EC84 LDD 4,SP
0000026E C30008 ADDD #8
153: str = skipWhitespace(str);
00000271 0709 BSR *+11 ;abs = 027C
154: if (*str == ',') str++;
00000273 2603 BNE *+5 ;abs = 0278
00000275 08 INX
00000276 6E84 STX 4,SP
155: return(str);
00000278 EC84 LDD 4,SP
157: }
0000027A 30 PULX
0000027B 3D RTS

*** Here's the apparent call to skipWhitespace (which is at 0135), but the
disassembler says it's going to branch to 027d, which would start with the
opcode FF and be out of phase with everything else.

0000027C 07FF BSR skipWhitespace ;abs = 027D
0000027E 6C86 STD 6,SP
00000280 B745 TFR D,X
00000282 E600 LDAB 0,X
00000284 C12C CMPB #44
00000286 3D RTS

Can someone explain this to a tired, old programmer?

Thanks,

Paul Johnson


______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

RE: Metrowerks Disassembly Obfuscation - Help! - Erich Styger - Mar 26 10:19:00 2003

Hello Paul,
what you see is called 'common code': the compiler folds togehter pieces of
code
at to the end of the function.
You may use the option -Onf to switch this optimization off.

But some questions:
how did you generate the listing file? With the decoder (decoding the object
file)
or decoding the .abs file?
I ask because the output looks like generated from the .abs file (say
function starts
at 0000243, but the presence of relocation/fixup information)
0000027C 07FF BSR skipWhitespace ;abs = 027D
says that it is an object file?

What you see with the 0x07FF code pattern is the BSR instruction with the
offset -1 plus
a relocation/fixup which has to be resolved by the linker.
So if the listing below is from the .abs file, this is potentially a bug.
In case the linker cannot resolve the BSR call, the linker will issue an
error. Did you
see this?

Hope this help,
Erich

> -----Original Message-----
> From: Paul Johnson [mailto:]
> Sent: Mittwoch, 26. Marz 2003 01:44
> To:
> Subject: [68HC12] Metrowerks Disassembly Obfuscation - Help! > Hi Metrowerks gurus,
>
> I've disassembled a module in my program where I think there may be a
> problem. I have include the relevant section below, which has a
> construction that I cannot understand. Can someone explain it to me? The
> problems are described inline, starting with ***.
>
> 143: char * parseLong(char * str,long * data)
> parseLong:
> 00000243 3B PSHD
> 145: str = skipWhitespace(str);
> 00000244 EC84 LDD 4,SP
> 00000246 0734 BSR *+54 ;abs = 027C
>
> *** I have to assume that there is a call of skipWhitespace at 027C, but
> wait until you see what's actually there (below)
>
> 146: if ((*str == ',') || !(*str)) {
> 00000248 2704 BEQ *+6 ;abs = 024E
> 0000024A E600 LDAB 0,X
> 0000024C 2610 BNE *+18 ;abs = 025E
> 147: *data = 0;
> 0000024E EE80 LDX 0,SP
> 00000250 C7 CLRB
> 00000251 87 CLRA
> 00000252 6C02 STD 2,X
> 00000254 6C00 STD 0,X
> 148: if (*str) str++;
> 00000256 EE84 LDX 4,SP
> 00000258 E600 LDAB 0,X
> 0000025A 271C BEQ *+30 ;abs = 0278
> 0000025C 2017 BRA *+25 ;abs = 0275
> 151: *data = str8tolong(str);
> 0000025E B754 TFR X,D
> 00000260 160000 JSR str8tolong
> 00000263 160000 JSR ILSEXT
> 00000266 ED80 LDY 0,SP
> 00000268 6C42 STD 2,Y
> 0000026A 6E40 STX 0,Y
> 152: str+=8;
> 0000026C EC84 LDD 4,SP
> 0000026E C30008 ADDD #8
> 153: str = skipWhitespace(str);
> 00000271 0709 BSR *+11 ;abs = 027C
> 154: if (*str == ',') str++;
> 00000273 2603 BNE *+5 ;abs = 0278
> 00000275 08 INX
> 00000276 6E84 STX 4,SP
> 155: return(str);
> 00000278 EC84 LDD 4,SP
> 157: }
> 0000027A 30 PULX
> 0000027B 3D RTS
>
> *** Here's the apparent call to skipWhitespace (which is at 0135), but the
> disassembler says it's going to branch to 027d, which would start with the
> opcode FF and be out of phase with everything else.
>
> 0000027C 07FF BSR skipWhitespace ;abs = 027D
> 0000027E 6C86 STD 6,SP
> 00000280 B745 TFR D,X
> 00000282 E600 LDAB 0,X
> 00000284 C12C CMPB #44
> 00000286 3D RTS
>
> Can someone explain this to a tired, old programmer?
>
> Thanks,
>
> Paul Johnson >
> --------------------------------------------------------
> To unsubscribe from this group, send an email to: > To learn more about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu






(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

Banked code on 812A4 solved - Dick Webb - Mar 26 11:44:00 2003

Back in mid-February I posted a note to the group requesting help on getting
banked code to work for my project using an 812A4 and the IAR compiler.

Thanks to Stephen Trier and Bob Gardner for their helpful replies.

Also thanks to the IAR support team.

What finally worked for me was the concept of address translation. What I
had been overlooking was the fact that the value of PPAGE determines not
only addresses A21..A16, but also A15 and A14. So when addressing the code
window 0x8000..0xBFFF with a PPAGE value of 0x00 the actual physical address
is 0x0000..0x3FFF. Once I finally comprehended that, and once I got some
instruction from IAR as to how to do the address translation in the link
file, and once I also got instruction from IAR as to what output format
would both support address translation and generate output in a format my
programmer could use to burn the PROMs, then I was good to go.

Once again thanks to those who responded to my original question.

Dick Webb
Wheatstone Corporation



______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

RE: Metrowerks Disassembly Obfuscation - Help! - Paul Johnson - Mar 27 9:52:00 2003

Hi Erich,

I could follow the common code optimization, and that makes sense -- it was
the BSR -1 that really confused me. I generated this code by right-clicking
in in the editor window (in CodeWarrior) and selecting "Disassemble". I did
not see any errors related to this, so I assume it was displaying
incorrectly but linking correctly.

The actual problem that had me on my hands and knees pouring through the
assembly code was a much more subtle bug. Every function in the chain that
had the failure worked correctly individually, but failed when used in
context. I looked for interrupts that might be stepping on data, overflow
of input buffers and all sorts of things. The answer was much simpler, but
harder to detect.

I have a routine -- unsigned long str8tolong(const char * str); -- which
expects str to be pointing at an 8 character hexadecimal value and returns
an unsigned long. I use it for parsing highly formatted input data. I have
several similar routines in one file - strfun.c - that was written, tested
and added to a library a long time ago. It turns out that str8tolong was
the only one that did NOT have a prototype in the header file. I have
apparently never yet used this particular function from that module.

As a result, the compiler resorted to implicit parameter declaration, and
the return value was assumed (properly) to be of type integer. Since it was
then assigned to a long, it was sign-extended to a long, and my troubles
began. This bug was darn hard to find.

I never noticed the implicit parameter declaration warning in the dozens of
meaningless warnings I get on every compile. Is there any way to promote a
particular warning to an actual error? Or is there any way to get a
particular type of warning to really stand out at compile time? This is a
nasty one, and should get more attention.

Thanks,

Paul Johnson

> -----Original Message-----
> From: Erich Styger [mailto:]
> Sent: Wednesday, March 26, 2003 7:19 AM
> To:
> Subject: RE: [68HC12] Metrowerks Disassembly Obfuscation - Help! > Hello Paul,
> what you see is called 'common code': the compiler folds togehter
> pieces of
> code
> at to the end of the function.
> You may use the option -Onf to switch this optimization off.
>
> But some questions:
> how did you generate the listing file? With the decoder (decoding
> the object
> file)
> or decoding the .abs file?
> I ask because the output looks like generated from the .abs file (say
> function starts
> at 0000243, but the presence of relocation/fixup information)
> 0000027C 07FF BSR skipWhitespace ;abs = 027D
> says that it is an object file?
>
> What you see with the 0x07FF code pattern is the BSR instruction with the
> offset -1 plus
> a relocation/fixup which has to be resolved by the linker.
> So if the listing below is from the .abs file, this is potentially a bug.
> In case the linker cannot resolve the BSR call, the linker will issue an
> error. Did you
> see this?
>
> Hope this help,
> Erich
>
> > -----Original Message-----
> > From: Paul Johnson [mailto:]
> > Sent: Mittwoch, 26. Marz 2003 01:44
> > To:
> > Subject: [68HC12] Metrowerks Disassembly Obfuscation - Help!
> >
> >
> > Hi Metrowerks gurus,
> >
> > I've disassembled a module in my program where I think there may be a
> > problem. I have include the relevant section below, which has a
> > construction that I cannot understand. Can someone explain it
> to me? The
> > problems are described inline, starting with ***.
> >
> > 143: char * parseLong(char * str,long * data)
> > parseLong:
> > 00000243 3B PSHD
> > 145: str = skipWhitespace(str);
> > 00000244 EC84 LDD 4,SP
> > 00000246 0734 BSR *+54 ;abs = 027C
> >
> > *** I have to assume that there is a call of skipWhitespace at 027C, but
> > wait until you see what's actually there (below)
> >
> > 146: if ((*str == ',') || !(*str)) {
> > 00000248 2704 BEQ *+6 ;abs = 024E
> > 0000024A E600 LDAB 0,X
> > 0000024C 2610 BNE *+18 ;abs = 025E
> > 147: *data = 0;
> > 0000024E EE80 LDX 0,SP
> > 00000250 C7 CLRB
> > 00000251 87 CLRA
> > 00000252 6C02 STD 2,X
> > 00000254 6C00 STD 0,X
> > 148: if (*str) str++;
> > 00000256 EE84 LDX 4,SP
> > 00000258 E600 LDAB 0,X
> > 0000025A 271C BEQ *+30 ;abs = 0278
> > 0000025C 2017 BRA *+25 ;abs = 0275
> > 151: *data = str8tolong(str);
> > 0000025E B754 TFR X,D
> > 00000260 160000 JSR str8tolong
> > 00000263 160000 JSR ILSEXT
> > 00000266 ED80 LDY 0,SP
> > 00000268 6C42 STD 2,Y
> > 0000026A 6E40 STX 0,Y
> > 152: str+=8;
> > 0000026C EC84 LDD 4,SP
> > 0000026E C30008 ADDD #8
> > 153: str = skipWhitespace(str);
> > 00000271 0709 BSR *+11 ;abs = 027C
> > 154: if (*str == ',') str++;
> > 00000273 2603 BNE *+5 ;abs = 0278
> > 00000275 08 INX
> > 00000276 6E84 STX 4,SP
> > 155: return(str);
> > 00000278 EC84 LDD 4,SP
> > 157: }
> > 0000027A 30 PULX
> > 0000027B 3D RTS
> >
> > *** Here's the apparent call to skipWhitespace (which is at
> 0135), but the
> > disassembler says it's going to branch to 027d, which would
> start with the
> > opcode FF and be out of phase with everything else.
> >
> > 0000027C 07FF BSR skipWhitespace ;abs = 027D
> > 0000027E 6C86 STD 6,SP
> > 00000280 B745 TFR D,X
> > 00000282 E600 LDAB 0,X
> > 00000284 C12C CMPB #44
> > 00000286 3D RTS
> >
> > Can someone explain this to a tired, old programmer?
> >
> > Thanks,
> >
> > Paul Johnson
> >
> >
> >
> > --------------------------------------------------------
> > To unsubscribe from this group, send an email to:
> >
> >
> > To learn more about Motorola Microcontrollers, please visit
> > http://www.motorola.com/mcu
> >
> >
> >
> >
> >
> --------------------------------------------------------
> To unsubscribe from this group, send an email to: > To learn more about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu






(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

RE: Metrowerks Disassembly Obfuscation - Help! - Erich Styger - Mar 27 10:01:00 2003

Hi Paul,
go to the preference panel for the compiler, there is a 'Messages' button,
where you can map messages to errors, etc.

As the implicit parameter thing is a common programming error, there is even
a special compiler option -Wpd which flags this as an error.

additionally, if you do not want to set the message mapping using options,
you can do it using pragmas in your code (wherever you want, e.g. you
can do in a common header file, etc). Check out the #pragma MESSAGE in the
manual
for this.
Example:
/* treat C1412: Not a function call, */
/* address of a function, as error */
#pragma MESSAGE ERROR C1412
void f(void);
void main(void) {
f; /* () is missing, but still legal in C */
/* ERROR because of pragma MESSAGE */
}

Thanks,
Erich

> -----Original Message-----
> From: Paul Johnson [mailto:]
> Sent: Donnerstag, 27. Marz 2003 15:53
> To:
> Subject: RE: [68HC12] Metrowerks Disassembly Obfuscation - Help! > Hi Erich,
>
> I could follow the common code optimization, and that makes sense
> -- it was
> the BSR -1 that really confused me. I generated this code by
> right-clicking
> in in the editor window (in CodeWarrior) and selecting
> "Disassemble". I did
> not see any errors related to this, so I assume it was displaying
> incorrectly but linking correctly.
>
> The actual problem that had me on my hands and knees pouring through the
> assembly code was a much more subtle bug. Every function in the
> chain that
> had the failure worked correctly individually, but failed when used in
> context. I looked for interrupts that might be stepping on data, overflow
> of input buffers and all sorts of things. The answer was much
> simpler, but
> harder to detect.
>
> I have a routine -- unsigned long str8tolong(const char * str); -- which
> expects str to be pointing at an 8 character hexadecimal value and returns
> an unsigned long. I use it for parsing highly formatted input
> data. I have
> several similar routines in one file - strfun.c - that was written, tested
> and added to a library a long time ago. It turns out that str8tolong was
> the only one that did NOT have a prototype in the header file. I have
> apparently never yet used this particular function from that module.
>
> As a result, the compiler resorted to implicit parameter declaration, and
> the return value was assumed (properly) to be of type integer.
> Since it was
> then assigned to a long, it was sign-extended to a long, and my troubles
> began. This bug was darn hard to find.
>
> I never noticed the implicit parameter declaration warning in the
> dozens of
> meaningless warnings I get on every compile. Is there any way to
> promote a
> particular warning to an actual error? Or is there any way to get a
> particular type of warning to really stand out at compile time? This is a
> nasty one, and should get more attention.
>
> Thanks,
>
> Paul Johnson
>
> > -----Original Message-----
> > From: Erich Styger [mailto:]
> > Sent: Wednesday, March 26, 2003 7:19 AM
> > To:
> > Subject: RE: [68HC12] Metrowerks Disassembly Obfuscation - Help!
> >
> >
> > Hello Paul,
> > what you see is called 'common code': the compiler folds togehter
> > pieces of
> > code
> > at to the end of the function.
> > You may use the option -Onf to switch this optimization off.
> >
> > But some questions:
> > how did you generate the listing file? With the decoder (decoding
> > the object
> > file)
> > or decoding the .abs file?
> > I ask because the output looks like generated from the .abs file (say
> > function starts
> > at 0000243, but the presence of relocation/fixup information)
> > 0000027C 07FF BSR skipWhitespace ;abs = 027D
> > says that it is an object file?
> >
> > What you see with the 0x07FF code pattern is the BSR
> instruction with the
> > offset -1 plus
> > a relocation/fixup which has to be resolved by the linker.
> > So if the listing below is from the .abs file, this is
> potentially a bug.
> > In case the linker cannot resolve the BSR call, the linker will issue an
> > error. Did you
> > see this?
> >
> > Hope this help,
> > Erich
> >
> > > -----Original Message-----
> > > From: Paul Johnson [mailto:]
> > > Sent: Mittwoch, 26. Marz 2003 01:44
> > > To:
> > > Subject: [68HC12] Metrowerks Disassembly Obfuscation - Help!
> > >
> > >
> > > Hi Metrowerks gurus,
> > >
> > > I've disassembled a module in my program where I think there may be a
> > > problem. I have include the relevant section below, which has a
> > > construction that I cannot understand. Can someone explain it
> > to me? The
> > > problems are described inline, starting with ***.
> > >
> > > 143: char * parseLong(char * str,long * data)
> > > parseLong:
> > > 00000243 3B PSHD
> > > 145: str = skipWhitespace(str);
> > > 00000244 EC84 LDD 4,SP
> > > 00000246 0734 BSR *+54 ;abs = 027C
> > >
> > > *** I have to assume that there is a call of skipWhitespace
> at 027C, but
> > > wait until you see what's actually there (below)
> > >
> > > 146: if ((*str == ',') || !(*str)) {
> > > 00000248 2704 BEQ *+6 ;abs = 024E
> > > 0000024A E600 LDAB 0,X
> > > 0000024C 2610 BNE *+18 ;abs = 025E
> > > 147: *data = 0;
> > > 0000024E EE80 LDX 0,SP
> > > 00000250 C7 CLRB
> > > 00000251 87 CLRA
> > > 00000252 6C02 STD 2,X
> > > 00000254 6C00 STD 0,X
> > > 148: if (*str) str++;
> > > 00000256 EE84 LDX 4,SP
> > > 00000258 E600 LDAB 0,X
> > > 0000025A 271C BEQ *+30 ;abs = 0278
> > > 0000025C 2017 BRA *+25 ;abs = 0275
> > > 151: *data = str8tolong(str);
> > > 0000025E B754 TFR X,D
> > > 00000260 160000 JSR str8tolong
> > > 00000263 160000 JSR ILSEXT
> > > 00000266 ED80 LDY 0,SP
> > > 00000268 6C42 STD 2,Y
> > > 0000026A 6E40 STX 0,Y
> > > 152: str+=8;
> > > 0000026C EC84 LDD 4,SP
> > > 0000026E C30008 ADDD #8
> > > 153: str = skipWhitespace(str);
> > > 00000271 0709 BSR *+11 ;abs = 027C
> > > 154: if (*str == ',') str++;
> > > 00000273 2603 BNE *+5 ;abs = 0278
> > > 00000275 08 INX
> > > 00000276 6E84 STX 4,SP
> > > 155: return(str);
> > > 00000278 EC84 LDD 4,SP
> > > 157: }
> > > 0000027A 30 PULX
> > > 0000027B 3D RTS
> > >
> > > *** Here's the apparent call to skipWhitespace (which is at
> > 0135), but the
> > > disassembler says it's going to branch to 027d, which would
> > start with the
> > > opcode FF and be out of phase with everything else.
> > >
> > > 0000027C 07FF BSR skipWhitespace ;abs = 027D
> > > 0000027E 6C86 STD 6,SP
> > > 00000280 B745 TFR D,X
> > > 00000282 E600 LDAB 0,X
> > > 00000284 C12C CMPB #44
> > > 00000286 3D RTS
> > >
> > > Can someone explain this to a tired, old programmer?
> > >
> > > Thanks,
> > >
> > > Paul Johnson
> > >
> > >
> > >
> > > --------------------------------------------------------
> > > To unsubscribe from this group, send an email to:
> > >
> > >
> > > To learn more about Motorola Microcontrollers, please visit
> > > http://www.motorola.com/mcu
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> > --------------------------------------------------------
> > To unsubscribe from this group, send an email to:
> >
> >
> > To learn more about Motorola Microcontrollers, please visit
> > http://www.motorola.com/mcu
> >
> >
> --------------------------------------------------------
To unsubscribe from this group, send an email to: To learn more about Motorola Microcontrollers, please visit
http://www.motorola.com/mcu




(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

Re: Metrowerks Disassembly Obfuscation - Help! - Mike Burgess - Mar 27 14:18:00 2003

Paul,
Usually compile warnings are not useless, you should try at all cost to
write code that
does not produce warnings. As was the case with your integer. Sooner or
later
what you thought was useless warnings will come back to haut you. Michael. ----- Original Message -----
From: "Paul Johnson" <>
To: <>
Sent: Thursday, March 27, 2003 9:52 AM
Subject: RE: [68HC12] Metrowerks Disassembly Obfuscation - Help! > Hi Erich,
>
> I could follow the common code optimization, and that makes sense -- it
was
> the BSR -1 that really confused me. I generated this code by
right-clicking
> in in the editor window (in CodeWarrior) and selecting "Disassemble". I
did
> not see any errors related to this, so I assume it was displaying
> incorrectly but linking correctly.
>
> The actual problem that had me on my hands and knees pouring through the
> assembly code was a much more subtle bug. Every function in the chain
that
> had the failure worked correctly individually, but failed when used in
> context. I looked for interrupts that might be stepping on data, overflow
> of input buffers and all sorts of things. The answer was much simpler,
but
> harder to detect.
>
> I have a routine -- unsigned long str8tolong(const char * str); -- which
> expects str to be pointing at an 8 character hexadecimal value and returns
> an unsigned long. I use it for parsing highly formatted input data. I
have
> several similar routines in one file - strfun.c - that was written, tested
> and added to a library a long time ago. It turns out that str8tolong was
> the only one that did NOT have a prototype in the header file. I have
> apparently never yet used this particular function from that module.
>
> As a result, the compiler resorted to implicit parameter declaration, and
> the return value was assumed (properly) to be of type integer. Since it
was
> then assigned to a long, it was sign-extended to a long, and my troubles
> began. This bug was darn hard to find.
>
> I never noticed the implicit parameter declaration warning in the dozens
of
> meaningless warnings I get on every compile. Is there any way to promote
a
> particular warning to an actual error? Or is there any way to get a
> particular type of warning to really stand out at compile time? This is a
> nasty one, and should get more attention.
>
> Thanks,
>
> Paul Johnson
>
> > -----Original Message-----
> > From: Erich Styger [mailto:]
> > Sent: Wednesday, March 26, 2003 7:19 AM
> > To:
> > Subject: RE: [68HC12] Metrowerks Disassembly Obfuscation - Help!
> >
> >
> > Hello Paul,
> > what you see is called 'common code': the compiler folds togehter
> > pieces of
> > code
> > at to the end of the function.
> > You may use the option -Onf to switch this optimization off.
> >
> > But some questions:
> > how did you generate the listing file? With the decoder (decoding
> > the object
> > file)
> > or decoding the .abs file?
> > I ask because the output looks like generated from the .abs file (say
> > function starts
> > at 0000243, but the presence of relocation/fixup information)
> > 0000027C 07FF BSR skipWhitespace ;abs = 027D
> > says that it is an object file?
> >
> > What you see with the 0x07FF code pattern is the BSR instruction with
the
> > offset -1 plus
> > a relocation/fixup which has to be resolved by the linker.
> > So if the listing below is from the .abs file, this is potentially a
bug.
> > In case the linker cannot resolve the BSR call, the linker will issue an
> > error. Did you
> > see this?
> >
> > Hope this help,
> > Erich
> >
> > > -----Original Message-----
> > > From: Paul Johnson [mailto:]
> > > Sent: Mittwoch, 26. Marz 2003 01:44
> > > To:
> > > Subject: [68HC12] Metrowerks Disassembly Obfuscation - Help!
> > >
> > >
> > > Hi Metrowerks gurus,
> > >
> > > I've disassembled a module in my program where I think there may be a
> > > problem. I have include the relevant section below, which has a
> > > construction that I cannot understand. Can someone explain it
> > to me? The
> > > problems are described inline, starting with ***.
> > >
> > > 143: char * parseLong(char * str,long * data)
> > > parseLong:
> > > 00000243 3B PSHD
> > > 145: str = skipWhitespace(str);
> > > 00000244 EC84 LDD 4,SP
> > > 00000246 0734 BSR *+54 ;abs = 027C
> > >
> > > *** I have to assume that there is a call of skipWhitespace at 027C,
but
> > > wait until you see what's actually there (below)
> > >
> > > 146: if ((*str == ',') || !(*str)) {
> > > 00000248 2704 BEQ *+6 ;abs = 024E
> > > 0000024A E600 LDAB 0,X
> > > 0000024C 2610 BNE *+18 ;abs = 025E
> > > 147: *data = 0;
> > > 0000024E EE80 LDX 0,SP
> > > 00000250 C7 CLRB
> > > 00000251 87 CLRA
> > > 00000252 6C02 STD 2,X
> > > 00000254 6C00 STD 0,X
> > > 148: if (*str) str++;
> > > 00000256 EE84 LDX 4,SP
> > > 00000258 E600 LDAB 0,X
> > > 0000025A 271C BEQ *+30 ;abs = 0278
> > > 0000025C 2017 BRA *+25 ;abs = 0275
> > > 151: *data = str8tolong(str);
> > > 0000025E B754 TFR X,D
> > > 00000260 160000 JSR str8tolong
> > > 00000263 160000 JSR ILSEXT
> > > 00000266 ED80 LDY 0,SP
> > > 00000268 6C42 STD 2,Y
> > > 0000026A 6E40 STX 0,Y
> > > 152: str+=8;
> > > 0000026C EC84 LDD 4,SP
> > > 0000026E C30008 ADDD #8
> > > 153: str = skipWhitespace(str);
> > > 00000271 0709 BSR *+11 ;abs = 027C
> > > 154: if (*str == ',') str++;
> > > 00000273 2603 BNE *+5 ;abs = 0278
> > > 00000275 08 INX
> > > 00000276 6E84 STX 4,SP
> > > 155: return(str);
> > > 00000278 EC84 LDD 4,SP
> > > 157: }
> > > 0000027A 30 PULX
> > > 0000027B 3D RTS
> > >
> > > *** Here's the apparent call to skipWhitespace (which is at
> > 0135), but the
> > > disassembler says it's going to branch to 027d, which would
> > start with the
> > > opcode FF and be out of phase with everything else.
> > >
> > > 0000027C 07FF BSR skipWhitespace ;abs = 027D
> > > 0000027E 6C86 STD 6,SP
> > > 00000280 B745 TFR D,X
> > > 00000282 E600 LDAB 0,X
> > > 00000284 C12C CMPB #44
> > > 00000286 3D RTS
> > >
> > > Can someone explain this to a tired, old programmer?
> > >
> > > Thanks,
> > >
> > > Paul Johnson
> > >
> > >
> > >
> > > --------------------------------------------------------
> > > To unsubscribe from this group, send an email to:
> > >
> > >
> > > To learn more about Motorola Microcontrollers, please visit
> > > http://www.motorola.com/mcu
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> > --------------------------------------------------------
> > To unsubscribe from this group, send an email to:
> >
> >
> > To learn more about Motorola Microcontrollers, please visit
> > http://www.motorola.com/mcu
> >
> >
> >
> >
> >
> --------------------------------------------------------
> To unsubscribe from this group, send an email to: > To learn more about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu




(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

RE: Metrowerks Disassembly Obfuscation - Help! - Karl Lunt - Mar 27 14:39:00 2003

Also, turn the warning level all the way up. This means enable every
warning that the compiler can produce. If your code still compiles without
warnings, you are more assured of having created very clean code.

(Naturally, there are some execptions to the above. For example, some
compilers might gen a warning over formatting issues on otherwise perfectly
good code; your mileage will vary.)

Karl > -----Original Message-----
> From: Mike Burgess [mailto:]
> Sent: Thursday, March 27, 2003 11:19 AM
> To:
> Subject: Re: [68HC12] Metrowerks Disassembly Obfuscation - Help! > Paul,
> Usually compile warnings are not useless, you should try at
> all cost to
> write code that
> does not produce warnings. As was the case with your
> integer. Sooner or
> later
> what you thought was useless warnings will come back to haut you. > Michael. > ----- Original Message -----
> From: "Paul Johnson" <>
> To: <>
> Sent: Thursday, March 27, 2003 9:52 AM
> Subject: RE: [68HC12] Metrowerks Disassembly Obfuscation - Help! > > Hi Erich,
> >
> > I could follow the common code optimization, and that makes
> sense -- it
> was
> > the BSR -1 that really confused me. I generated this code by
> right-clicking
> > in in the editor window (in CodeWarrior) and selecting
> "Disassemble". I
> did
> > not see any errors related to this, so I assume it was displaying
> > incorrectly but linking correctly.
> >
> > The actual problem that had me on my hands and knees
> pouring through the
> > assembly code was a much more subtle bug. Every function
> in the chain
> that
> > had the failure worked correctly individually, but failed
> when used in
> > context. I looked for interrupts that might be stepping on
> data, overflow
> > of input buffers and all sorts of things. The answer was
> much simpler,
> but
> > harder to detect.
> >
> > I have a routine -- unsigned long str8tolong(const char *
> str); -- which
> > expects str to be pointing at an 8 character hexadecimal
> value and returns
> > an unsigned long. I use it for parsing highly formatted
> input data. I
> have
> > several similar routines in one file - strfun.c - that was
> written, tested
> > and added to a library a long time ago. It turns out that
> str8tolong was
> > the only one that did NOT have a prototype in the header
> file. I have
> > apparently never yet used this particular function from that module.
> >
> > As a result, the compiler resorted to implicit parameter
> declaration, and
> > the return value was assumed (properly) to be of type
> integer. Since it
> was
> > then assigned to a long, it was sign-extended to a long,
> and my troubles
> > began. This bug was darn hard to find.
> >
> > I never noticed the implicit parameter declaration warning
> in the dozens
> of
> > meaningless warnings I get on every compile. Is there any
> way to promote
> a
> > particular warning to an actual error? Or is there any way to get a
> > particular type of warning to really stand out at compile
> time? This is a
> > nasty one, and should get more attention.
> >
> > Thanks,
> >
> > Paul Johnson
> >
> > > -----Original Message-----
> > > From: Erich Styger [mailto:]
> > > Sent: Wednesday, March 26, 2003 7:19 AM
> > > To:
> > > Subject: RE: [68HC12] Metrowerks Disassembly Obfuscation - Help!
> > >
> > >
> > > Hello Paul,
> > > what you see is called 'common code': the compiler folds togehter
> > > pieces of
> > > code
> > > at to the end of the function.
> > > You may use the option -Onf to switch this optimization off.
> > >
> > > But some questions:
> > > how did you generate the listing file? With the decoder (decoding
> > > the object
> > > file)
> > > or decoding the .abs file?
> > > I ask because the output looks like generated from the
> .abs file (say
> > > function starts
> > > at 0000243, but the presence of relocation/fixup information)
> > > 0000027C 07FF BSR skipWhitespace ;abs = 027D
> > > says that it is an object file?
> > >
> > > What you see with the 0x07FF code pattern is the BSR
> instruction with
> the
> > > offset -1 plus
> > > a relocation/fixup which has to be resolved by the linker.
> > > So if the listing below is from the .abs file, this is
> potentially a
> bug.
> > > In case the linker cannot resolve the BSR call, the
> linker will issue an
> > > error. Did you
> > > see this?
> > >
> > > Hope this help,
> > > Erich
> > >
> > > > -----Original Message-----
> > > > From: Paul Johnson [mailto:]
> > > > Sent: Mittwoch, 26. Marz 2003 01:44
> > > > To:
> > > > Subject: [68HC12] Metrowerks Disassembly Obfuscation - Help!
> > > >
> > > >
> > > > Hi Metrowerks gurus,
> > > >
> > > > I've disassembled a module in my program where I think
> there may be a
> > > > problem. I have include the relevant section below, which has a
> > > > construction that I cannot understand. Can someone explain it
> > > to me? The
> > > > problems are described inline, starting with ***.
> > > >
> > > > 143: char * parseLong(char * str,long * data)
> > > > parseLong:
> > > > 00000243 3B PSHD
> > > > 145: str = skipWhitespace(str);
> > > > 00000244 EC84 LDD 4,SP
> > > > 00000246 0734 BSR *+54 ;abs = 027C
> > > >
> > > > *** I have to assume that there is a call of
> skipWhitespace at 027C,
> but
> > > > wait until you see what's actually there (below)
> > > >
> > > > 146: if ((*str == ',') || !(*str)) {
> > > > 00000248 2704 BEQ *+6 ;abs = 024E
> > > > 0000024A E600 LDAB 0,X
> > > > 0000024C 2610 BNE *+18 ;abs = 025E
> > > > 147: *data = 0;
> > > > 0000024E EE80 LDX 0,SP
> > > > 00000250 C7 CLRB
> > > > 00000251 87 CLRA
> > > > 00000252 6C02 STD 2,X
> > > > 00000254 6C00 STD 0,X
> > > > 148: if (*str) str++;
> > > > 00000256 EE84 LDX 4,SP
> > > > 00000258 E600 LDAB 0,X
> > > > 0000025A 271C BEQ *+30 ;abs = 0278
> > > > 0000025C 2017 BRA *+25 ;abs = 0275
> > > > 151: *data = str8tolong(str);
> > > > 0000025E B754 TFR X,D
> > > > 00000260 160000 JSR str8tolong
> > > > 00000263 160000 JSR ILSEXT
> > > > 00000266 ED80 LDY 0,SP
> > > > 00000268 6C42 STD 2,Y
> > > > 0000026A 6E40 STX 0,Y
> > > > 152: str+=8;
> > > > 0000026C EC84 LDD 4,SP
> > > > 0000026E C30008 ADDD #8
> > > > 153: str = skipWhitespace(str);
> > > > 00000271 0709 BSR *+11 ;abs = 027C
> > > > 154: if (*str == ',') str++;
> > > > 00000273 2603 BNE *+5 ;abs = 0278
> > > > 00000275 08 INX
> > > > 00000276 6E84 STX 4,SP
> > > > 155: return(str);
> > > > 00000278 EC84 LDD 4,SP
> > > > 157: }
> > > > 0000027A 30 PULX
> > > > 0000027B 3D RTS
> > > >
> > > > *** Here's the apparent call to skipWhitespace (which is at
> > > 0135), but the
> > > > disassembler says it's going to branch to 027d, which would
> > > start with the
> > > > opcode FF and be out of phase with everything else.
> > > >
> > > > 0000027C 07FF BSR skipWhitespace ;abs = 027D
> > > > 0000027E 6C86 STD 6,SP
> > > > 00000280 B745 TFR D,X
> > > > 00000282 E600 LDAB 0,X
> > > > 00000284 C12C CMPB #44
> > > > 00000286 3D RTS
> > > >
> > > > Can someone explain this to a tired, old programmer?
> > > >
> > > > Thanks,
> > > >
> > > > Paul Johnson
> > > >
> > > >
> > > >
> > > > --------------------------------------------------------
> > > > To unsubscribe from this group, send an email to:
> > > >
> > > >
> > > > To learn more about Motorola Microcontrollers, please visit
> > > > http://www.motorola.com/mcu
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > --------------------------------------------------------
> > > To unsubscribe from this group, send an email to:
> > >
> > >
> > > To learn more about Motorola Microcontrollers, please visit
> > > http://www.motorola.com/mcu
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> > --------------------------------------------------------
> > To unsubscribe from this group, send an email to:
> >
> >
> > To learn more about Motorola Microcontrollers, please visit
> > http://www.motorola.com/mcu
> >
> >
>

--------------------------------------------------------
To unsubscribe from this group, send an email to: To learn more about Motorola Microcontrollers, please visit
http://www.motorola.com/mcu



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

RE: Metrowerks Disassembly Obfuscation - Help! - Steve Russell - Mar 27 17:23:00 2003

Hi Paul,

Let me add my voice to the chorus and explain why I compile with the
highest warning level available, and keep the warnings to zero.

As others have pointed out, it is easy to prevent a warning from being
printed, either by using a #pragma or by adding a cast or redundant assignment.

So suppressing the ones that you have determined you are not interested in
one by one is pretty easy.

The advantage is that when you add new code with that produces a warning,
you get told about it by the compiler, and you can easily fix it, because
the compiler is pretty good about pointing to exactly where the problem is.

Sometimes the problem is obvious and a quick edit will fix it.

Sometimes the problem is that you really don't understand some C feature,
and you have to study the manuals. In this case you learn something.

Sometimes its just the compiler being picky, and you can make it shut up
with a quick edit.

On the average all of these take much less time than loading the program
and debugging it, as you just reported.

Keeping the reports of warnings to zero as a matter of policy, saves your
time (and frustration)!

Steve At 06:52 AM 3/27/2003, you wrote:
>Hi Erich,
>
>I could follow the common code optimization, and that makes sense -- it was
>the BSR -1 that really confused me. I generated this code by right-clicking
>in in the editor window (in CodeWarrior) and selecting "Disassemble". I did
>not see any errors related to this, so I assume it was displaying
>incorrectly but linking correctly.
>
>The actual problem that had me on my hands and knees pouring through the
>assembly code was a much more subtle bug. Every function in the chain that
>had the failure worked correctly individually, but failed when used in
>context. I looked for interrupts that might be stepping on data, overflow
>of input buffers and all sorts of things. The answer was much simpler, but
>harder to detect.
>
>I have a routine -- unsigned long str8tolong(const char * str); -- which
>expects str to be pointing at an 8 character hexadecimal value and returns
>an unsigned long. I use it for parsing highly formatted input data. I have
>several similar routines in one file - strfun.c - that was written, tested
>and added to a library a long time ago. It turns out that str8tolong was
>the only one that did NOT have a prototype in the header file. I have
>apparently never yet used this particular function from that module.
>
>As a result, the compiler resorted to implicit parameter declaration, and
>the return value was assumed (properly) to be of type integer. Since it was
>then assigned to a long, it was sign-extended to a long, and my troubles
>began. This bug was darn hard to find.
>
>I never noticed the implicit parameter declaration warning in the dozens of
>meaningless warnings I get on every compile. Is there any way to promote a
>particular warning to an actual error? Or is there any way to get a
>particular type of warning to really stand out at compile time? This is a
>nasty one, and should get more attention.
>
>Thanks,
>
>Paul Johnson
>
> > -----Original Message-----
> > From: Erich Styger [mailto:]
> > Sent: Wednesday, March 26, 2003 7:19 AM
> > To:
> > Subject: RE: [68HC12] Metrowerks Disassembly Obfuscation - Help!
> >
> >
> > Hello Paul,
> > what you see is called 'common code': the compiler folds togehter
> > pieces of
> > code
> > at to the end of the function.
> > You may use the option -Onf to switch this optimization off.
> >
> > But some questions:
> > how did you generate the listing file? With the decoder (decoding
> > the object
> > file)
> > or decoding the .abs file?
> > I ask because the output looks like generated from the .abs file (say
> > function starts
> > at 0000243, but the presence of relocation/fixup information)
> > 0000027C 07FF BSR skipWhitespace ;abs = 027D
> > says that it is an object file?
> >
> > What you see with the 0x07FF code pattern is the BSR instruction with the
> > offset -1 plus
> > a relocation/fixup which has to be resolved by the linker.
> > So if the listing below is from the .abs file, this is potentially a bug.
> > In case the linker cannot resolve the BSR call, the linker will issue an
> > error. Did you
> > see this?
> >
> > Hope this help,
> > Erich
> >
> > > -----Original Message-----
> > > From: Paul Johnson [mailto:]
> > > Sent: Mittwoch, 26. Marz 2003 01:44
> > > To:
> > > Subject: [68HC12] Metrowerks Disassembly Obfuscation - Help!
> > >
> > >
> > > Hi Metrowerks gurus,
> > >
> > > I've disassembled a module in my program where I think there may be a
> > > problem. I have include the relevant section below, which has a
> > > construction that I cannot understand. Can someone explain it
> > to me? The
> > > problems are described inline, starting with ***.
> > >
> > > 143: char * parseLong(char * str,long * data)
> > > parseLong:
> > > 00000243 3B PSHD
> > > 145: str = skipWhitespace(str);
> > > 00000244 EC84 LDD 4,SP
> > > 00000246 0734 BSR *+54 ;abs = 027C
> > >
> > > *** I have to assume that there is a call of skipWhitespace at 027C, but
> > > wait until you see what's actually there (below)
> > >
> > > 146: if ((*str == ',') || !(*str)) {
> > > 00000248 2704 BEQ *+6 ;abs = 024E
> > > 0000024A E600 LDAB 0,X
> > > 0000024C 2610 BNE *+18 ;abs = 025E
> > > 147: *data = 0;
> > > 0000024E EE80 LDX 0,SP
> > > 00000250 C7 CLRB
> > > 00000251 87 CLRA
> > > 00000252 6C02 STD 2,X
> > > 00000254 6C00 STD 0,X
> > > 148: if (*str) str++;
> > > 00000256 EE84 LDX 4,SP
> > > 00000258 E600 LDAB 0,X
> > > 0000025A 271C BEQ *+30 ;abs = 0278
> > > 0000025C 2017 BRA *+25 ;abs = 0275
> > > 151: *data = str8tolong(str);
> > > 0000025E B754 TFR X,D
> > > 00000260 160000 JSR str8tolong
> > > 00000263 160000 JSR ILSEXT
> > > 00000266 ED80 LDY 0,SP
> > > 00000268 6C42 STD 2,Y
> > > 0000026A 6E40 STX 0,Y
> > > 152: str+=8;
> > > 0000026C EC84 LDD 4,SP
> > > 0000026E C30008 ADDD #8
> > > 153: str = skipWhitespace(str);
> > > 00000271 0709 BSR *+11 ;abs = 027C
> > > 154: if (*str == ',') str++;
> > > 00000273 2603 BNE *+5 ;abs = 0278
> > > 00000275 08 INX
> > > 00000276 6E84 STX 4,SP
> > > 155: return(str);
> > > 00000278 EC84 LDD 4,SP
> > > 157: }
> > > 0000027A 30 PULX
> > > 0000027B 3D RTS
> > >
> > > *** Here's the apparent call to skipWhitespace (which is at
> > 0135), but the
> > > disassembler says it's going to branch to 027d, which would
> > start with the
> > > opcode FF and be out of phase with everything else.
> > >
> > > 0000027C 07FF BSR skipWhitespace ;abs = 027D
> > > 0000027E 6C86 STD 6,SP
> > > 00000280 B745 TFR D,X
> > > 00000282 E600 LDAB 0,X
> > > 00000284 C12C CMPB #44
> > > 00000286 3D RTS
> > >
> > > Can someone explain this to a tired, old programmer?
> > >
> > > Thanks,
> > >
> > > Paul Johnson
> > >
> > >
> > >
> > > --------------------------------------------------------
> > > To unsubscribe from this group, send an email to:
> > >
> > >
> > > To learn more about Motorola Microcontrollers, please visit
> > > <http://www.motorola.com/mcu>http://www.motorola.com/mcu
> > >
> > >
> > > >http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> >
> >
> > --------------------------------------------------------
> > To unsubscribe from this group, send an email to:
> >
> >
> > To learn more about Motorola Microcontrollers, please visit
> > <http://www.motorola.com/mcu>http://www.motorola.com/mcu
> >
> >
> > >http://docs.yahoo.com/info/terms/
> >
> >Yahoo! Groups Sponsor
>ADVERTISEMENT
><http://rd.yahoo.com/M=246920.2960106.4328965.2848452/D=egroupweb/S=1706554205:HM/A=1508991/R=2/id=noscript/*http://www.gotomypc.com/u/tr/yh/cpm/grp/300_06F/g22lp?Target=mm/g22lp.tmpl>1938aca.jpg
>
>1938b24.jpg
>
>--------------------------------------------------------
>To unsubscribe from this group, send an email to: >To learn more about Motorola Microcontrollers, please visit
><http://www.motorola.com/mcu>http://www.motorola.com/mcu >>Yahoo! Terms of Service. *************************************************************************
Steve Russell mailto:
Senior Software Design Engineer http://www.nohau.com
Nohau Corporation phone: (408)866-1820
51 East Campbell Avenue fax: (408)378-7869
Campbell, CA 95008
*************************************************************************

[Non-text portions of this message have been removed]



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

Re: Metrowerks Disassembly Obfuscation - Help! - Pat Fitzpatrick - Mar 27 18:30:00 2003

Hi list, I agree in principle, having been burned more than I ought to be by ignoring warnings. However, I don't know what to do about the following CodeWorrier warning:

Warning : C12056 : SP debug info incorrect because of optimization or inline assembler.

Anyhow, there's no inline assembler and the code seems to work just fine so I presume it's a result of some ooptimization or other. I get rid of it with a #pragma, but it's still a little worrying.

Can anyone explain what this message is really trying to tell me?? And if I ought to be concerned about it at all? And even how I might get rid of it by modifying the source code?

thanks,

Pat Steve Russell wrote:

> Hi Paul,
>
> Let me add my voice to the chorus and explain why I compile with the
> highest warning level available, and keep the warnings to zero.
>
> As others have pointed out, it is easy to prevent a warning from being
> printed, either by using a #pragma or by adding a cast or redundant assignment.
>
> So suppressing the ones that you have determined you are not interested in
> one by one is pretty easy.
>
> The advantage is that when you add new code with that produces a warning,
> you get told about it by the compiler, and you can easily fix it, because
> the compiler is pretty good about pointing to exactly where the problem is.
>
> Sometimes the problem is obvious and a quick edit will fix it.
>
> Sometimes the problem is that you really don't understand some C feature,
> and you have to study the manuals. In this case you learn something.
>
> Sometimes its just the compiler being picky, and you can make it shut up
> with a quick edit.
>
> On the average all of these take much less time than loading the program
> and debugging it, as you just reported.
>
> Keeping the reports of warnings to zero as a matter of policy, saves your
> time (and frustration)!
>
> Steve


______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

RE: Metrowerks Disassembly Obfuscation - Help! - Erich Styger - Mar 28 4:56:00 2003

Hello Pat,
about C12056: see the documentation provided on this one (see previous
post).
In your code it may be because of common code optimization (which could
result
in some pretty tricky stack operations).

Erich

> -----Original Message-----
> From: Pat Fitzpatrick [mailto:]
> Sent: Freitag, 28. Marz 2003 00:30
> To:
> Subject: Re: [68HC12] Metrowerks Disassembly Obfuscation - Help! > Hi list, > I agree in principle, having been burned more than I ought to be
> by ignoring warnings. However, I don't know what to do about the
> following CodeWorrier warning:
>
> Warning : C12056 : SP debug info incorrect because of
> optimization or inline assembler.
>
> Anyhow, there's no inline assembler and the code seems to work
> just fine so I presume it's a result of some ooptimization or
> other. I get rid of it with a #pragma, but it's still a little worrying.
>
> Can anyone explain what this message is really trying to tell
> me?? And if I ought to be concerned about it at all? And even how
> I might get rid of it by modifying the source code?
>
> thanks,
>
> Pat > Steve Russell wrote:
>
> > Hi Paul,
> >
> > Let me add my voice to the chorus and explain why I compile with the
> > highest warning level available, and keep the warnings to zero.
> >
> > As others have pointed out, it is easy to prevent a warning from being
> > printed, either by using a #pragma or by adding a cast or
> redundant assignment.
> >
> > So suppressing the ones that you have determined you are not
> interested in
> > one by one is pretty easy.
> >
> > The advantage is that when you add new code with that produces
> a warning,
> > you get told about it by the compiler, and you can easily fix
> it, because
> > the compiler is pretty good about pointing to exactly where the
> problem is.
> >
> > Sometimes the problem is obvious and a quick edit will fix it.
> >
> > Sometimes the problem is that you really don't understand some
> C feature,
> > and you have to study the manuals. In this case you learn something.
> >
> > Sometimes its just the compiler being picky, and you can make it shut up
> > with a quick edit.
> >
> > On the average all of these take much less time than loading the program
> > and debugging it, as you just reported.
> >
> > Keeping the reports of warnings to zero as a matter of policy,
> saves your
> > time (and frustration)!
> >
> > Steve >
> --------------------------------------------------------
> To unsubscribe from this group, send an email to: > To learn more about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu





(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )