Searching \ for '[PIC]: Stack overflow? Size of stack?' 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/devices.htm?key=pic
Search entire site for: 'Stack overflow? Size of stack?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Stack overflow? Size of stack?'
2001\05\25@094257 by Bob Barr

picon face
Olin Lathrop <spam_OUTolin_piclistTakeThisOuTspamEMBEDINC.COM> wrote:


>Subject: Re: [PIC]: Stack overflow?  Size of stack?
>Date: Fri, 25 May 2001 07:33:33 -0700
>
> > I *may* be having a problem with stack overflow (or underflow, for that
> > matter), but I can't seem to nail it down with 2000 lines of code.  Can
> > anyone suggest how this can be done?
>
>Both the simulator and emulator have facilities for trapping this.
>
>

In the MPLAB simulator, the stack overflow break is *disabled* by default.

To enable it, you need to go to:

Project > Edit Project > Devlopment Mode Change > Break Options

In that dialog, the "Stack Overflow Break Enable" box must be checked to
enable checks for stack under/overflow.

(Don't ask how long it took me to find this setting or how long I tried to
track down an underflow before I did. Why Microchip chose to default this
option to OFF, I'll never know.)

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body


2001\05\25@095552 by Drew Vassallo

picon face
>> > I *may* be having a problem with stack overflow (or underflow, for that
>> > matter), but I can't seem to nail it down with 2000 lines of code.  Can
>> > anyone suggest how this can be done?
>>
>>Both the simulator and emulator have facilities for trapping this.

I realize this, but I don't think I can fully simulate all the I/O and
interrupts for this system with the MPLAB simulator alone.  And I don't have
an ICE :(

I guess I was looking for a piece of software that could go through the code
and take all possible paths to find the maximum/minimum stack level.  This
doesn't seem like it would be that difficult a task, does it?  As I said, I
thought someone had done it already, but I can't remember who it was or what
it was called.

And since there are no registers or bits that indicate a stack overflow
while the program is running, I can't just add a LED or something to output
while running the system.  Microchip is funny in this respect; they
specifically state that stack overflow isn't indicated, yet I can't see
where it would be that tough for them to actually implement it.

--Andrew
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body


2001\05\25@130043 by Olin Lathrop

face picon face
> And since there are no registers or bits that indicate a stack overflow
> while the program is running, I can't just add a LED or something to
output
> while running the system.  Microchip is funny in this respect; they
> specifically state that stack overflow isn't indicated, yet I can't see
> where it would be that tough for them to actually implement it.

This wouldn't be much use once your units got to the field.  For development
they have chips with special bond out used in the ICE, which can trap on
stack underflow and overflow.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, .....olinKILLspamspam.....embedinc.com, http://www.embedinc.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspam_OUTspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body


2001\05\25@144614 by Drew Vassallo

picon face
> > while running the system.  Microchip is funny in this respect; they
> > specifically state that stack overflow isn't indicated, yet I can't see
> > where it would be that tough for them to actually implement it.
>
>This wouldn't be much use once your units got to the field.  For
>development
>they have chips with special bond out used in the ICE, which can trap on
>stack underflow and overflow.

I guess I don't see your point.  If you're waiting until your product gets
put into general use to determine whether or not your code overflows the
stack, then you're doing something wrong.  A nice handy flag bit would help,
as they've got tons of free bits in existing SFR registers already.  Maybe
the chip costs more this way, I don't know, but it might be worth it.  Maybe
they just want to sell their ICEs.

I'm strictly speaking in terms of development.  And yes, for *proper*
development or commercial products, an ICE would be quite handy, but for the
poor-man's debugging process, a flag bit stored in a RAM location would be
more than helpful, which I'm just saying could be done probably in a simple
way by Microchip.  The MPLAB simulator detects it, but the chip doesn't...
that's funny, especially when it can be incredibly difficult to simulate a
complex system.

Regardless of all this, I'm still in need of a more efficient method to
determine all this, rather than manually paging through 2000 lines of code.
Any other suggestions are welcome.

--Andrew
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body


2001\05\25@151553 by Douglas Wood

picon face
Other processors don't have stack over(under)run indicators, why should the
PIC?

Douglas Wood
Software Engineer
@spam@dbwoodKILLspamspamkc.rr.com

Home of the EPICIS Development System for the PIC and SX
http://epicis.piclist.com

{Original Message removed}

2001\05\25@155938 by Drew Vassallo

picon face
>Other processors don't have stack over(under)run indicators, why should the
>PIC?

Because they want to be better than "other processors?"  I don't know.

Why are your products different than others in your market?  Odd question.

--Andrew
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email KILLspamlistservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body


2001\05\25@161007 by Douglas Wood

picon face
But that was my point: PICs aren't different than other processors regarding
the stack.

Douglas Wood
Software Engineer
RemoveMEdbwoodTakeThisOuTspamkc.rr.com

Home of the EPICIS Development System for the PIC and SX
http://epicis.piclist.com

{Original Message removed}

2001\05\25@165723 by Drew Vassallo

picon face
>But that was my point: PICs aren't different than other processors
>regarding
>the stack.

Ummm... someone's missing something here, and it's not me.  Why are you
restating your point?  I understand it.  My point is that they SHOULD be
different than other processors regarding the stack, in order to perhaps be
BETTER than those others.  If people looked at every problem or lack of
product feature and said, "Well, they're ALL like that, I guess I'm out of
luck." then nothing would ever get improved upon.

As I said, why are your products different than others in your market?  If
they're the same, why should I buy yours?  What do you offer that may be an
improvement over similar, if not cheaper, products?  Do you not agree that
maybe an extra bit in an FSR for stack overflow would be helpful to some?

Microchip's ICE goes for $1525.00, plus the cost ($450) for each processor
module you'd like to interface to.  Not a cost I'd spend on a piece of hobby
equipment for one feature (or lack of) which seemingly might be able to be
implemented directly on the chip in a single flag bit.  I need a better
solution than this.

That's my point.

--Andrew
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistservspamBeGonespammitvma.mit.edu with SET PICList DIGEST in the body


2001\05\25@180720 by Olin Lathrop

face picon face
> >This wouldn't be much use once your units got to the field.  For
> >development
> >they have chips with special bond out used in the ICE, which can trap on
> >stack underflow and overflow.
>
> I guess I don't see your point.  If you're waiting until your product gets
> put into general use to determine whether or not your code overflows the
> stack, then you're doing something wrong.

No, it's the other way around.  You debug with the chips that have the extra
stack checking hardware, but then ship product without it.

> I'm strictly speaking in terms of development.  And yes, for *proper*
> development or commercial products, an ICE would be quite handy, but for
the
> poor-man's debugging process, a flag bit stored in a RAM location would be
> more than helpful, which I'm just saying could be done probably in a
simple
> way by Microchip.

Nothing is "simple" when you try to burden millions of chips with it and
it's only needed during development.  There is no reason for Microchip to do
this.  Those that develop the applications that end up buying the millions
of chips will have no problem buying an ICE.  Those that won't spend the
money on an ICE are irrelevant to the bottom line.

> The MPLAB simulator detects it, but the chip doesn't...
> that's funny, especially when it can be incredibly difficult to simulate a
> complex system.

The simulator is all software, so there is no burden on the high volume
production products.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, TakeThisOuTolinEraseMEspamspam_OUTembedinc.com, http://www.embedinc.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body


2001\05\25@184123 by Olin Lathrop

face picon face
> Microchip's ICE goes for $1525.00, plus the cost ($450) for each processor
> module you'd like to interface to.  Not a cost I'd spend on a piece of
hobby
> equipment for one feature (or lack of) which seemingly might be able to be
> implemented directly on the chip in a single flag bit.  I need a better
> solution than this.

I think you still don't get it.  Microchip does not, nor should not, care
what you or anyone else that buys ten processors wants.  Anyone who can't
justify the ICE for PIC development is obviously never going to cause them
any meaningful sales.

Think of it another way.  How many more PICs will they sell if they
implement such a feature?  You're already using PICs, so probably none to
you.  They still have the best environment for hobbiest out there so they
will sell the same number to the same hobbiests.  Either way that number is
so small to be irrelevant.  Now think of how many PICs they might NOT sell
if they had to charge a little more for each one.  Price is extremely
important when the volumes are in the millions.  Just 1 cent more costs the
buyer $10,000.  That's how much engineering the customer can afford to save
a penny.  If Motorola, TI, Intel, etc, has a processor that can do the job
for a penny less that's what will get used.  Keeping the per unit cost down
is Microchip's true competitive pressure.  The development tools only need
to be non-prohibitive for serious customers (who by the way get a discount
on them anyway).  Microchip correctly realizes that good support is more
important than a few hundred dollars on development tools cost, although the
Microchip tools are priced quite reasonably.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, olinEraseMEspam.....embedinc.com, http://www.embedinc.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspammitvma.mit.edu with SET PICList DIGEST in the body


2001\05\25@184530 by David Cary

flavicon
face
Dear Drew Vassallo,

Drew Vassallo <RemoveMEsnurpleEraseMEspamEraseMEHOTMAIL.COM> on 2001-05-25 08:55:52 AM wracked his brain
trying to remember
>I guess I was looking for a piece of software that could go through the code
>and take all possible paths to find the maximum/minimum stack level.  This
>doesn't seem like it would be that difficult a task, does it?  As I said, I
>thought someone had done it already, but I can't remember who it was or what
>it was called.

That sounds like a cool idea. The trap-on-overflow can be fooled if you CALL
some error-handling routine only under unusual conditions that didn't come up
during testing. But a program that did exhaustive searching through every
possible path in the source code would catch it.

I wish I had something like that.

Once you had software that did that, it doesn't sound too difficult to make it
actually count the (maximum) number of instructions executed when running any
particular subroutine. (It would be cool if I could *guarantee* that, with
interrupts turned off, my main loop cycle occurred at *least* once every 50 ms).

Looks like a feature to ask for in SDCC.

I haven't seen anything like this for any assembly language, but I've seen a
couple of utilities that parse C code (or other HLL) and generate a call tree
(automatically finding the maximum stack level).

 Jinsight
 http://www.research.ibm.com/jinsight/docs/refman/calltree.htm

 QProfiler
 http://sourceforge.net/projects/qprofiler/

 FTNCHEK
 http://www.dsm.fordham.edu/~ftnchek/html/calltree.html

 Function Call Tree
 http://home.apu.edu/~jcox/projects/fct/
(apparently a class project -- is there any working code ?)

 SAL Programming tools and utilities
 http://sal.kachinatech.com/F/2/index.shtml

Any good ones I missed ?

--
David Cary

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservspam_OUTspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body


2001\05\25@191858 by Drew Vassallo

picon face
>Nothing is "simple" when you try to burden millions of chips with it and
>it's only needed during development.  There is no reason for Microchip to
>do
>this.

But brownout detection and watchdog are necessary, apparently.  Why not have
a stack overflow reset as a safety measure?  It seems like a valid concept,
especially when you consider that you *COULD* debug with it and still ship
product with it.  If it somehow slips through your testing, it would still
be available in the field as a safety feature.

>Those that develop the applications that end up buying the millions
>of chips will have no problem buying an ICE.  Those that won't spend the
>money on an ICE are irrelevant to the bottom line.

On this we agree.  Money rules; invention and innovation do not :(

--Andrew

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservTakeThisOuTspamspammitvma.mit.edu with SET PICList DIGEST in the body


2001\05\25@192106 by Drew Vassallo

picon face
>That sounds like a cool idea. The trap-on-overflow can be fooled if you
>CALL
>some error-handling routine only under unusual conditions that didn't come
>up
>during testing. But a program that did exhaustive searching through every
>possible path in the source code would catch it.

Thanks Dave, you finally added some helpful input to the thread.
Unfortunately, my code is in ASM.

--Andrew
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspamspamspamBeGonemitvma.mit.edu with SET PICList DIGEST in the body


2001\05\25@194603 by Douglas Wood

picon face
The PIC is what it is. Why not use it as it is. While the PIC may not be the
best processor design around, if you don't like what it has to offer, then
look at other processors. Sure, I am not crazy about the way the SUBLW and
SUBWF work, and yes Microchip "could" have added a bunch of really cool bits
to help out, but they didn't design it that way. But I and others manage to
use the PIC just as it is. And as Olin stated in another message, companies
don't create microprocessors so that "some" can use them; they create them
to make money. No one is twisting our arm (or anyone else's) to use the PIC.
Go out and create a new version of the PIC using a FPLD; I'd like to see
that anyway. Come up with a better design.

Douglas Wood
Software Engineer
RemoveMEdbwoodKILLspamspamkc.rr.com

Home of the EPICIS Development System for the PIC and SX
http://epicis.piclist.com

{Original Message removed}

2001\05\25@195212 by Eric Smith

flavicon
face
> Sure, I am not crazy about the way the SUBLW and SUBWF work,

You may have a legitimate complaint about SUBWF.  But SUBLW does exactly
the right thing:  W := constant - W.

If you want W := W - constant, you can use ADDLW -constant.  If they had
made SUBLW do W := W - constant, it just would have been a waste of opcode
space.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservSTOPspamspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body


2001\05\25@195631 by Douglas Wood

picon face
Yes, but that only works for signed (two complement) numbers. ;-)

Douglas Wood
Software Engineer
spamBeGonedbwoodSTOPspamspamEraseMEkc.rr.com

Home of the EPICIS Development System for the PIC and SX
http://epicis.piclist.com

{Original Message removed}

2001\05\25@200911 by Andrew Warren

flavicon
face
Eric Smith <KILLspamPICLISTspamBeGonespammitvma.mit.edu> wrote:

> You may have a legitimate complaint about SUBWF.  But SUBLW does
> exactly the right thing:  W := constant - W.

   Eric:

   It DOES the right thing, but it has the wrong name.

   SUBWF, which existed before the SUBLW instruction was introduced,
   means "Subtract W from File".  By that convention, SUBLW SHOULD
   mean "Subtract Literal from W".  Instead, it (astonishingly)
   means "Subtract W from Literal".

   -Andrew


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

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email @spam@listserv@spam@spamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body


2001\05\25@204941 by Paul Hutchinson

flavicon
face
>But brownout detection and watchdog are necessary, apparently.  Why not
have
>a stack overflow reset as a safety measure?  It seems like a valid concept,
>especially when you consider that you *COULD* debug with it and still ship
>product with it.  If it somehow slips through your testing, it would still
>be available in the field as a safety feature.

I think if your stack overflows, the watchdog timer will give you a reset.

I feel that brownout and watchdog are big selling features of the PIC. The
presence of a watchdog in the 68HC11 was certainly a big selling feature
because a lot of older 68XX systems had to use external brownout and
watchdog circuits/chips.

Paul

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistservspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body


2001\05\25@232321 by michael brown

flavicon
face
I have been following this thread for a while, and I can no longer resist.
<RANT ON>
Processors are designed by engineers and not programmers.  Now that hardware
engineers have to be programmers, maybe just maybe, you all can see the
insufferable misery that hardware engineers have been inflicting upon
software engineers all these years.  Every processor I have ever used or
seen has been filled with foolish (flame me if you like) implementations and
restrictions from a programmers perspective.  All this in the interest of
saving a few logic gates.  I have had to deal with processors on mainframes
that tell me I am at the end of my data, on the last valid reference (not at
the next reference which would have been easier to deal with
programmatically).  Yet, the processor goes ahead and increments the pointer
right on past the end of the data.  Unless you have ever used tally
operations on the GE/Honeywell/Bull mainframes you won't understand what I
mean.  But trust me, being a programmer, it was just plain wrong period.
The SUBLW instruction is another good example.  It would have been nice (and
much more useful) had it actually been a "subtract literal from W"
instruction but it's not.  It is a "subtract W from literal" instruction,
regardless of the confusing mnemonic that was chosen.  Perhaps someone can
explain to me why the mnemonic is inconsistent with the way the instruction
works.  It's going take some strong arguments to convince me that it's
better or cheaper or more efficient this way instead of having the mnemonic
be SUBWL.  Perhaps someone can explain to me the necessity of CLRF and CLRW
feeling obligated to set the Z flag.  Yet MOVWF doesn't affect it at all.
So after doing a MOVWF I have to do another wasteful instruction to find out
if I just moved a zero or not.  Also, how many times has anyone used the "oh
so important" DC flag.

Moving back to the thread topic.  Most CISC processors do feel the need to
report a stack fault in some fashion.  It is only (so far as I have ever
seen) these RISC microcontrollers that don't.  A stack overflow can happen
inadvertently, but I'd have to say that a stack underflow is probably due to
careless or so called "clever" programming.
<RANT OFF>

Just having some fun   ;o)

michael brown

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservspam_OUTspammitvma.mit.edu with SET PICList DIGEST in the body


2001\05\25@233834 by Drew Vassallo

picon face
><RANT ON>
 Also, how many times has anyone used the "oh
>so important" DC flag.

I enjoyed your rant, but this is where I disagree.  The DC bit is used VERY
often in BCD conversion, as well as other math functions.

overflow can happen
>inadvertently, but I'd have to say that a stack underflow is probably due
>to
>careless or so called "clever" programming.
><RANT OFF>

This is true.  And I do have some "clever" programming in my code.  This is
why I fear an underflow, but I don't really expect it.  It's maybe a 2%
possibility.  However, it *is* possible, and I'd like to verify 100% that it
will not occur.

--Andrew

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistserv.....spamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body


2001\05\26@004713 by Sean H. Breheny

face picon face
Hi Michael,

You make a lot of good points but the fact is that the PIC already HAS an
instruction to subtract a literal from W: ADDLW. Just use ADDLW with the
two's complement of the literal you want to subtract. Most assemblers will
even handle it for you if you put a negative sign in front of the literal.
I use it all the time.

I don't know why Mchip called SUBLW by that name rather than SUBWL. I think
Andy Warren has something about that on his Fast Forward Engineering Answer
Page, and IIRC, it was a silly decision just to make it similar to the
other mnemonics (which end in LW).

Sean

At 10:16 PM 5/25/01 -0500, you wrote:
>The SUBLW instruction is another good example.  It would have been nice (and
>much more useful) had it actually been a "subtract literal from W"
>instruction but it's not.  It is a "subtract W from literal" instruction,
>regardless of the confusing mnemonic that was chosen.  Perhaps someone can
>explain to me why the mnemonic is inconsistent with the way the instruction
>works.  It's going take some strong arguments to convince me that it's
>better or cheaper or more efficient this way instead of having the mnemonic
>be SUBWL.  Perhaps someone can explain to me the necessity of CLRF and CLRW

--
http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclist-unsubscribe-requestKILLspamspamspammitvma.mit.edu


2001\05\26@004741 by Jeff DeMaagd

flavicon
face
----- Original Message -----
From: michael brown <.....n5qmgspamRemoveMEAMSAT.ORG>

>Also, how many times has anyone used the "oh so important" DC flag.<

I think I'll need the DC flag soon.  And I'm a beginner to PICs.  I want to
display a decimal (base 10) number and isn't that needed do do decimal
operations?

Jeff

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestspamspamBeGonemitvma.mit.edu


2001\05\26@015556 by michael brown

flavicon
face
----- Original Message -----
From: "Jeff DeMaagd" <spamBeGonejeff@spam@spamspam_OUTDEMAAGD.COM>
To: <TakeThisOuTPICLISTspamspamMITVMA.MIT.EDU>
Sent: Friday, May 25, 2001 11:14 PM
Subject: Re: [PIC]: Stack overflow? Size of stack?


> ----- Original Message -----
> From: michael brown <n5qmgEraseMEspamAMSAT.ORG>
>
> >Also, how many times has anyone used the "oh so important" DC flag.<
>
> I think I'll need the DC flag soon.  And I'm a beginner to PICs.  I want
to
> display a decimal (base 10) number and isn't that needed do do decimal
> operations?

It is used to show that a carry occured out of bit 3 (zero relative).  Much
like the C flag shows a carry out of bit 7.  For example: if you add one to
b'00001111' (decimal 15) then a DC occurs (the DC flag is set).  If you add
a one to b'00001001' (decimal 9) a DC does not occur (the DC flag is not
set).  It is not a way to see if decimal carry has occured.  It is a digit
carry.  A digit being a 4 bit BCD value.

>
> Jeff
>
> --
> http://www.piclist.com hint: To leave the PICList
> RemoveMEpiclist-unsubscribe-requestEraseMEspamspam_OUTmitvma.mit.edu
>
>

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-requestRemoveMEspamEraseMEmitvma.mit.edu


2001\05\26@020440 by michael brown

flavicon
face
> Hi Michael,
>
> You make a lot of good points but the fact is that the PIC already HAS an
> instruction to subtract a literal from W: ADDLW. Just use ADDLW with the
> two's complement of the literal you want to subtract. Most assemblers will
> even handle it for you if you put a negative sign in front of the literal.
> I use it all the time.

Yes, but that only works for literal numbers below 128.  It assumes that I
am doing signed math.  How would I subtract 129 from W?   ;-)

>
> I don't know why Mchip called SUBLW by that name rather than SUBWL. I
think
> Andy Warren has something about that on his Fast Forward Engineering
Answer
> Page, and IIRC, it was a silly decision just to make it similar to the
> other mnemonics (which end in LW).
>
> Sean
>
> At 10:16 PM 5/25/01 -0500, you wrote:
> >The SUBLW instruction is another good example.  It would have been nice
(and
> >much more useful) had it actually been a "subtract literal from W"
> >instruction but it's not.  It is a "subtract W from literal" instruction,
> >regardless of the confusing mnemonic that was chosen.  Perhaps someone
can
> >explain to me why the mnemonic is inconsistent with the way the
instruction
> >works.  It's going take some strong arguments to convince me that it's
> >better or cheaper or more efficient this way instead of having the
mnemonic
> >be SUBWL.  Perhaps someone can explain to me the necessity of CLRF and
CLRW
>
> --
> http://www.piclist.com hint: To leave the PICList
> EraseMEpiclist-unsubscribe-requestspam@spam@mitvma.mit.edu
>
>

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-requestspam_OUTspam.....mitvma.mit.edu


2001\05\26@085622 by Bob Ammerman

picon face
----- Original Message -----
From: "michael brown" <spamBeGonen5qmgEraseMEspamAMSAT.ORG>
To: <PICLISTspamBeGonespamMITVMA.MIT.EDU>
Sent: Saturday, May 26, 2001 1:46 AM
Subject: Re: [PIC]: Stack overflow? Size of stack?


> > Hi Michael,
> >
> > You make a lot of good points but the fact is that the PIC already HAS
an
> > instruction to subtract a literal from W: ADDLW. Just use ADDLW with the
> > two's complement of the literal you want to subtract. Most assemblers
will
> > even handle it for you if you put a negative sign in front of the
literal.
> > I use it all the time.
>
> Yes, but that only works for literal numbers below 128.  It assumes that I
> am doing signed math.  How would I subtract 129 from W?   ;-)

Believe it or not "ADDLW low(-129)" will give you the correct result.

Let's look at an example:

   W = 150 = B'10010110'
   ADDLW low(-129) = ADDLW B'01111111'

Result is B'10101' == 21

Amazing, huh?

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-request@spam@spamspamBeGonemitvma.mit.edu


2001\05\26@093650 by David W. Gulley

flavicon
face
michael brown wrote:
> Yes, but that only works for literal numbers below 128.  It
> assumes that I am doing signed math.  How would I subtract
> 129 from W?   ;-)

for your specific case:
W - 129 = W + (256 - 129) = W + 127

In general I use:
ADDLW    256-N       ;where N is the value to be subtracted

So what about the carry?
 It behaves just as if you had done a subtract (SUBWF)!
 The Carry flag is set for no borrow, clear for borrow.

David W. Gulley
Destiny Designs

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-request@spam@spamEraseMEmitvma.mit.edu


2001\05\26@095604 by Roman Black

flavicon
face
Drew Vassallo wrote:

> This is true.  And I do have some "clever" programming in my code.  This is
> why I fear an underflow, but I don't really expect it.  It's maybe a 2%
> possibility.  However, it *is* possible, and I'd like to verify 100% that it
> will not occur.


Just a long shot, but would it be possible to just
increment a register just before any call and dec it
just before any return?? That might give you a stack
count you could check in software. How badly do you
want to find out??
:o)
-Roman

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestRemoveMEspammitvma.mit.edu


2001\05\26@101052 by michael brown

flavicon
face
----- Original Message -----
From: "Bob Ammerman" <.....RAMMERMANSTOPspamspam@spam@PRODIGY.NET>
To: <PICLISTEraseMEspam@spam@MITVMA.MIT.EDU>
Sent: Saturday, May 26, 2001 7:54 AM
Subject: Re: [PIC]: Stack overflow? Size of stack?


{Quote hidden}

the
{Quote hidden}

So -129 = 127 that is amazing.  Is the carry flag handled properly, it looks
like it would be?  I can't believe this doesn't generate a warning,
since -129 cannot (really) be represented in 8 bits.  Now, I have seen
everything.  ;-D

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspam_OUTspam@spam@mitvma.mit.edu


2001\05\26@124806 by Douglas Wood

picon face
> > Perhaps someone can explain to me the necessity of CLRF and CLRW

On 12- and 14-bit cores the W register is not addresses (i.e., can not be
addresses as an SFR). On 16- and 16+-bit cores "CLRW" went away. (For a
complete reference to the PIC instruction set see my "PIC Microcontroller
Instruction Set Comparison Matrix" at epicis.piclist.com.

Douglas Wood
Software Engineer
spamBeGonedbwood@spam@spamkc.rr.com

Home of the EPICIS Development System for the PIC and SX
http://epicis.piclist.com

{Original Message removed}

2001\05\28@023326 by Kari Lehikko

flavicon
face
Andrew,

In case you didn't know, PIC18Cxxx has stack under/overflow bits and
resets. So, MicroChip has already improved its desing.

- Kari -

--
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\05\28@075017 by Drew Vassallo

picon face
>In case you didn't know, PIC18Cxxx has stack under/overflow bits and
>resets. So, MicroChip has already improved its desing.

I did not know that!  In fact, you're the first person to mention it, so I
assume nobody else did, either.

Thanks for that information, it gives me hope for future projects.

--Andrew
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.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\05\28@180823 by Douglas Wood

picon face
The 17Cxxx series also has a stack overflow bit.

Douglas Wood
Software Engineer
RemoveMEdbwoodEraseMEspamKILLspamkc.rr.com

Home of the EPICIS Development System for the PIC and SX
http://epicis.piclist.com

{Original Message removed}

2001\05\28@233622 by Bill Westfield

face picon face
> But that was my point: PICs aren't different than other processors
> regarding the stack

Um, yes they are.  Most processors implement their stack pointer in "user"
memory using a visible register as the stack pointer.  You can check whether
an overflow or underflow has occurred or is about to occur.  Some kind of
stack error trapping on a procesor with an opaque stack would be more
important than on the more generic processors...

BillW

--
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\05\29@050953 by Alan B. Pearce
face picon face
>Regardless of all this, I'm still in need of a more efficient method to
>determine all this, rather than manually paging through 2000 lines of code.
>Any other suggestions are welcome.

Is there any mileage in having a register that you use as an internal
counter of how deep in the stack you are, and setting an external pin and
halting if you get too deep. maybe have it as part of a conditional assembly
macro for debug.

produce code along the following lines (semi pseudo code)

label:    incf stackdepth,f
           if stackdepth > maxstack then
               bsf portX,stackpanic
               halt
           else
           {normal subroutine code}

endsub:    decf stackdepth,f
           return

end semi pseudo code

This would at least give you a reasonable confidence that your code was not
going over the stack limit. It would also be necessary to include the same
code inside any interrupt routine. If the stackpanic line was set up to
drive an LED that had a hardware blink (especially a 2 colour one going
red/green at a slow rate) then a quick glance at the PCB will give you a
rapid indication of why your machine suddenly went "belly up".

It may also be possible to make the code leap out to a set of dump code
especially in running an ICSP. If setting the stackdepth register to a large
value on the error, then as you return down the stack each routine could
dump a signature (e.g. PC) so you can see how you get to the error.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\05\29@081154 by Drew Vassallo

picon face
>Is there any mileage in having a register that you use as an internal
>counter of how deep in the stack you are, and setting an external pin and

Yes, someone already suggested this.  It turns out that a loose connection
was causing resets and spurious code execution with my new program, not a
stack issue.  But these suggestions and information about the overflow/reset
bits on the 17 and 18 series PICs are useful to the list, anyway.

--Andrew
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


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