Searching \ for '[PIC]: Challenge: 18F Clear RAM' 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=18F
Search entire site for: 'Challenge: 18F Clear RAM'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Challenge: 18F Clear RAM'
2002\08\19@141437 by Scott Dattalo

face
flavicon
face
All this talk about the 18F parts warrants a challenge. A useful snippet
every programmer should have is a Clear Ram one.

Challenge:

Write a program to clear the RAM in an 18f452 (or any 18X part with RAM
from 0x000 through 0xf7f). Minimize the # of CPU cycles and limit the
snippet to 12 instructions.

I've got 2 - a slow, but short routine, and a fast, but long one.

Scott

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


2002\08\19@142307 by Jennifer L. Gatza

flavicon
face
How about the simple example in the manual? (DS39026B, page 48)

> Challenge:
>
> Write a program to clear the RAM in an 18f452 (or any 18X
> part with RAM
> from 0x000 through 0xf7f). Minimize the # of CPU cycles and limit the
> snippet to 12 instructions.

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


2002\08\19@142930 by Scott Dattalo

face
flavicon
face
On Mon, 19 Aug 2002, Jennifer L. Gatza wrote:

> How about the simple example in the manual? (DS39026B, page 48)
>
> > Challenge:
> >
> > Write a program to clear the RAM in an 18f452 (or any 18X
> > part with RAM
> > from 0x000 through 0xf7f). Minimize the # of CPU cycles and limit the
> > snippet to 12 instructions.

Doesn't that one only clear 0x100 bytes?

Scott

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


2002\08\19@152533 by Bob Ammerman

picon face
Short:

clrf    FSR0L
clrf    FSR0H

(or LFSR 0,0)

loop:
clrf    POSTINC0
btfsc  FSR0H,3
bra    loop

Faster:

clrf    FSR0L
clrf    FSR0H

(or LFSR 0,0)

loop:
clrf    POSTINC0
clrf    POSTINC0
clrf    POSTINC0
clrf    POSTINC0
clrf    POSTINC0
clrf    POSTINC0
clrf    POSTINC0
clrf    POSTINC0
btfsc  FSR0H,3
bra    loop



{Original Message removed}

2002\08\19@153625 by Scott Dattalo

face
flavicon
face
On Mon, 19 Aug 2002, Bob Ammerman wrote:

> Short:
>
> clrf    FSR0L
> clrf    FSR0H
>
> (or LFSR 0,0)
>
> loop:
> clrf    POSTINC0
> btfsc  FSR0H,3
> bra    loop

I think you meant btfss instead of btfsc. If so, won't that just get 0x000
- 0x3ff? You can't change the 3 to a 4 or you'll wipe out the SFRs between
0xf80 - 0xfff (including POSTINC0 which will cause an infinite loop).

hint, suppose you use LFSR 0,0xf7f?

Scott

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


2002\08\19@154255 by Bob Ammerman

picon face
oops: i misread the range to clear. I read it as 0..0x7FF

it should have been 0..0xF7F

also the sense of the btf instructions was reversed below.

So, try this at 6 instructions:

lfsr        0,0
movlw   0xF8
loop:
clrf        POSTINC0
cmpseq FSR0H
goto      loop

and for a little faster at 9 instructions:

lfsr        0,0
movlw   0xF8
loop:
clrf        POSTINC0
clrf        POSTINC0
clrf        POSTINC0
clrf        POSTINC0
cmpseq FSR0H
goto      loop






er.... not quite. see corrections below:

{Original Message removed}

2002\08\19@154300 by Bob Ammerman

picon face
> I think you meant btfss instead of btfsc.

Yeah, I did.

> If so, won't that just get 0x000
> - 0x3ff? You can't change the 3 to a 4 or you'll wipe out the SFRs between
> 0xf80 - 0xfff (including POSTINC0 which will cause an infinite loop).

Yeah, you're right of course.

> hint, suppose you use LFSR 0,0xf7f?

Now that you say so... pretty obvious....

lfsr    0,0xf7f
loop:
clrf    POSTDEC0    ; 1 for slow, 8 of em for fast
clrf    POSTDEC0
clrf    POSTDEC0
clrf    POSTDEC0
clrf    POSTDEC0
clrf    POSTDEC0
clrf    POSTDEC0
clrf    POSTDEC0
btfss FSR0H,7
bra    loop


Duh...
Bob

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


2002\08\19@155054 by Bob Ammerman

picon face
Er....

My last response is STILL not right....

bit FSR0,7 is not implemented and always reads as zero.

So, the test condition at the end of the loop has to be:

TSTFSZ    FSR0H

Now, I think that is finally right.

Bob Ammerman
RAm Systems





{Original Message removed}

2002\08\19@160817 by Bob Ammerman

picon face
> Er....
>
> My last response is STILL not right....
>
> bit FSR0,7 is not implemented and always reads as zero.

Ok Scott, what is the answer?

Bob Ammerman
RAm Systems

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


2002\08\19@162316 by tcs

face picon face
My code:


;************************************ CLEARMEM.inc
*********************************
; This module clears all RAM in the 452 PIC.
;
; Author: Thomas C. Sefranek  10-30-2000 Modified: Bud Martin 1-2-2001
;
; REGISTERS:
;           FSR0H
;***************************************************************************
*********
;
Clear_Mem       LFSR    0, 0x000        ; Point to the start of RAM.
Clear_Loop      CLRF    POSTINC0        ; Erase this RAM location.
               BTFSS   FSR0H, 3        ; Have we done 8 block?
               GOTO    Clear_Loop      ; No, Go clear another location.

> {Original Message removed}

2002\08\19@175647 by Scott Dattalo

face
flavicon
face
On Mon, 19 Aug 2002, Bob Ammerman wrote:

> > Er....
> >
> > My last response is STILL not right....
> >
> > bit FSR0,7 is not implemented and always reads as zero.
>
> Ok Scott, what is the answer?

Well, I don't know about *the* answer, but here are a couple of ideas:

  lfsr  0,0xf7f
loop1
  clrf    postdec0
  tstfsz  fsr0h
   bra    loop1

loop2
  clrf    postdec0
  tstfsz  fsr0l
   bra    loop1

  clrf    postdec0


or a slow solution

  lfsr 0xf7f

loop
  clrf  postdec0
  movf  fsr0l,w
  iorwf fsr0h,w
  bnz   loop

  clrf  indf0

or


 lfsr  0xf7f

loop
 clrf   postdec0
 movf   fsr0h,w
 bnz    loop
 tstfsz fsr0l
  bra   loop

 clrf   indf0


Scott

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


2002\08\19@180333 by Brendan Moran

flavicon
face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I havent been following this thread.  That said, if you want to clear
*all* the RAM, wouldn't a quick/easy way of doing it be to tie one
pin to MCLR to force a processor reset, but at the same time, store
the current address of the PC to EEPROM before doing the reset, and
have a startup routine that reloads the PC to the value in the
EEPROM?

Just a thought...

- --Brendan

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>

iQA/AwUBPWFq4gVk8xtQuK+BEQKAUACeNirtv3mDdocKxhTCfzhH2P6Akj4AoJWV
v4MT/sVZuVDbVZiKO1ER3Hzk
=vcfu
-----END PGP SIGNATURE-----

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


2002\08\19@183326 by Andrew Warren

flavicon
face
Brendan Moran <RemoveMEPICLISTTakeThisOuTspammitvma.mit.edu> wrote:

> if you want to clear *all* the RAM, wouldn't a quick/easy way of
> doing it be to tie one pin to MCLR to force a processor reset, but
> at the same time, store the current address of the PC to EEPROM
> before doing the reset, and have a startup routine that reloads the
> PC to the value in the EEPROM?

   Wow.

   Where's the candle burning through the string, the spring-loaded
   trapdoor through which the ball drops, the sprinkling can that
   tips over and fills the boot with water, etc.?

   -Andy

   P.S.  By the way, a processor reset doesn't clear the data RAM.

=== Andrew Warren -- spamBeGoneaiwspamBeGonespamcypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation

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


2002\08\19@203459 by Brendan Moran

flavicon
face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> > if you want to clear *all* the RAM, wouldn't a quick/easy way of
> > doing it be to tie one pin to MCLR to force a processor reset,
> > but at the same time, store the current address of the PC to
> > EEPROM before doing the reset, and have a startup routine that
> > reloads the PC to the value in the EEPROM?
>
>     Wow.
>
>     Where's the candle burning through the string, the
> spring-loaded
>     trapdoor through which the ball drops, the sprinkling can that
>     tips over and fills the boot with water, etc.?

That will come in will come in the mk.2 version.

In the mean time, it seemed like a viable option to me at the time,
but it appears that Microchip decided not to give us that option for
whatever reason.  I would have expected that a line labled MCLR
would, in fact, be a memory clear, but it is not.

- --Brendan

>     -Andy
>
>     P.S.  By the way, a processor reset doesn't clear the data RAM.
>

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>

iQA/AwUBPWGA0wVk8xtQuK+BEQLLlwCg+cKDIdbz2a4z7D1zjjkI1j0UrgoAn2Gu
HJLu7ZekIBssSqPRV8XpFyyZ
=4HR/
-----END PGP SIGNATURE-----

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


2002\08\20@044505 by Alan B. Pearce

face picon face
>> if you want to clear *all* the RAM, wouldn't a quick/easy way of
>> doing it be to tie one pin to MCLR to force a processor reset, but
>> at the same time, store the current address of the PC to EEPROM
>> before doing the reset, and have a startup routine that reloads the
>> PC to the value in the EEPROM?
>
>    Wow.
>
>    Where's the candle burning through the string, the spring-loaded
>    trapdoor through which the ball drops, the sprinkling can that
>    tips over and fills the boot with water, etc.?
>
>    -Andy

I can see you have been looking at too many books by Heath Robinson :))


>    P.S.  By the way, a processor reset doesn't clear the data RAM.

I hadn't checked, but did wonder when I saw the post, if this really did
happen, seeing as it is not implemented in other processors, and besides
which, is there a brownout or watchdog timer, and if so would these cause
the ram to be cleared??? I would hope not.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\08\20@092015 by Bob Ammerman

picon face
Well great... and I figured you have a twelve instruction loop that would do
8 locations at a time.

Doing 4 at a time with 10 instructions:  execution time is roughly 2
instructions per memory byte.

   lfsr        0,0
   movlw    0x0F
loop:
   clrf    POSTINC0
   clrf    POSTINC0
   clrf    POSTINC0
   clrf    POSTINC0
   btfsc      FSR0L,7
   cpfseq    FSR0H
   bra    loop


By adding 4 more clrf's you'll have 14 instructions, but execution time will
drop to roughly 1.5 instructions per byte.

Bob Ammeramn
RAm Systems





{Original Message removed}

2002\08\20@094933 by Scott Dattalo

face
flavicon
face
On Tue, 20 Aug 2002, Bob Ammerman wrote:

> Well great... and I figured you have a twelve instruction loop that would do
> 8 locations at a time.

The 12-instruction thing was just to prevent someone from writing a
program of 4096 CLRF's and claiming that's the fastest way to clear
memory. Also, 12 is that mystical number that Dmitry always manages to
encounter.

{Quote hidden}

That'll do it! (Assuming that FSR0H:L rolls over from 0x000 to 0xfff).

Scott

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\08\20@124411 by Brendan Moran

flavicon
face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

{Quote hidden}

Now, see, if *I* were designing a processor, a reset (i.e. external
or reset instruction) would clear the entire contents of memory.  Any
of these other "resets" are, in fact, irrecoverable interrupts (i.e.
interrupts with a PC (and stack?)  clear), and should be handled as
such.

But, then I don't design processors, now do I?

- --Brendan

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>

iQA/AwUBPWJxsQVk8xtQuK+BEQJ25gCg9/kLwbjvYz2LQQOjwdD6kK+Nh08AoMQw
0A/rI00Wg5vozuQF+akEkKVv
=Ae2t
-----END PGP SIGNATURE-----

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\08\20@125052 by Brendan Moran

flavicon
face
> > Well great... and I figured you have a twelve instruction loop that
would do
> > 8 locations at a time.
>
> The 12-instruction thing was just to prevent someone from writing a
> program of 4096 CLRF's and claiming that's the fastest way to clear
> memory. Also, 12 is that mystical number that Dmitry always manages to
> encounter.

Don't you just wish that you had the post-increment indexed addressing mode
that's available on some larger processors ;)

--Brendan

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\08\20@132316 by Scott Dattalo

face
flavicon
face
On Tue, 20 Aug 2002, Brendan Moran wrote:

> > > Well great... and I figured you have a twelve instruction loop that
> would do
> > > 8 locations at a time.
> >
> > The 12-instruction thing was just to prevent someone from writing a
> > program of 4096 CLRF's and claiming that's the fastest way to clear
> > memory. Also, 12 is that mystical number that Dmitry always manages to
> > encounter.
>
> Don't you just wish that you had the post-increment indexed addressing mode
> that's available on some larger processors ;)

No, not particularly. But then again, we have no idea what you're rambling
about. The 18F parts *do* have a post-increment addressing. I hate to
Olinize(*), but I think you should spend some time reading about the
18fxxx parts instead of talking about them.

Scott

(*) Olinize - (verb) - the act of abruptly, sometimes even rudely,
pointing out the obvious. No offense to Olin, of course.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\08\20@135417 by Brendan Moran

flavicon
face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> No, not particularly. But then again, we have no idea what you're
> rambling about. The 18F parts *do* have a post-increment
> addressing. I hate to Olinize(*), but I think you should spend some
> time reading about the 18fxxx parts instead of talking about them.
>
> Scott
>
> (*) Olinize - (verb) - the act of abruptly, sometimes even rudely,
> pointing out the obvious. No offense to Olin, of course.

Oh... Yeah... Because I'm sure I want to read and manipulate a flash
memory table while I'M TRYING TO CLEAR THE RAM!

Perhaps I should have read more before making that comment.  However,
I wasn't wrong in noting that the PIC doesn't have what is necessary
for this operation.

I was refering to a special add-on to an addressing mode used by some
slightly more advanced processors.  It's a mode where you specify one
of the accumulators (yes, there are 5 (maybe 6) seperate registers
that are all useable as indexes on some processors, 2 of which are
8-bit, and the rest are 16) to act as an index, and then you can
specify an offset from that address, or do a pre/post
increment/decrement by any value up to 9 bits.(I think.  I haven't
looked at the specifics in 5 months)  Any time an instruction with a
pre/post increment/decrement is used, the specified index register is
incremented/decremented by the specified value, andstored back to
itself.

I'm sure that you can see the value of that kind of addressing when
attempting to handle larger blocks of data.  You know, having 1k of
RAM minimum?

- --Brendan
(*)Olinize - (verb) - (2) the act of instructing a person who has
asked a question to return to a previous level of educational
instruction.  Usually, but not limited to freshman physics. (no
offence to Olin, of course)

- ---
"Rejection out of hand of all but one's favoured alternative may cost
you
dearly in one way or another." -Russell McMahon

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>

iQA/AwUBPWKCMwVk8xtQuK+BEQJqFQCgrwhPwf1DSSfEnNpKEedj32sHWsgAoM8n
xYj0YyN0a/gNpVuGDkBoovNf
=/+aW
-----END PGP SIGNATURE-----

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\08\20@135604 by Jennifer Loiacono

flavicon
face
> > Don't you just wish that you had the post-increment indexed
> addressing mode
> > that's available on some larger processors ;)
>
> No, not particularly. But then again, we have no idea what
> you're rambling
> about. The 18F parts *do* have a post-increment addressing. I hate to
> Olinize(*), but I think you should spend some time reading about the
> 18fxxx parts instead of talking about them.

I took the original post about "some larger processors" to mean the 18F's.
:)

Jen

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\08\20@143456 by Bob Ammerman

picon face
The datasheet explicitly says that PRE and POST INC/DEC are applied to the
12-bit value in FSRxH:FSRxL, so  I am pretty certain this will work fine.

Bob Ammerman
RAm Systems

{Original Message removed}

2002\08\20@145535 by Olin Lathrop

face picon face
> Now, see, if *I* were designing a processor, a reset (i.e. external
> or reset instruction) would clear the entire contents of memory.

And you'd be spending a bunch of transistors that could be put to better use
in most applications, or left off completely to reduce die size and cost.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\08\20@150019 by Olin Lathrop

face picon face
> Don't you just wish that you had the post-increment indexed addressing
mode
> that's available on some larger processors ;)

Um, you do.  Try reading the manual.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\08\20@150024 by Brendan Moran

flavicon
face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> > Now, see, if *I* were designing a processor, a reset (i.e.
> > external or reset instruction) would clear the entire contents of
> > memory.
>
> And you'd be spending a bunch of transistors that could be put to
> better use in most applications, or left off completely to reduce
> die size and cost.

Hence the "But, then I don't design processors, now do I?"

- --Brendan
- ---
"Rejection out of hand of all but one's favoured alternative may cost
you dearly in one way or another." -Russell McMahon



-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>

iQA/AwUBPWKRkAVk8xtQuK+BEQJ6WACguVWk1KuGcAYtQ3glG250c5xZRyoAnjuA
OVVXXAavkiF5+9a2aegxTkHw
=OIcX
-----END PGP SIGNATURE-----

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\08\20@150032 by Brendan Moran

flavicon
face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Oh... Yeah... Because I'm sure I want to read and manipulate a
> flash memory table while I'M TRYING TO CLEAR THE RAM!
>
> Perhaps I should have read more before making that comment.
> However, I wasn't wrong in noting that the PIC doesn't have what is
> necessary for this operation.

Agh, cripes!  Missed the section on the file select register having
auto-inc, due to its being in the section on memory organization
rather than in the instruction set definitions.

Looks like I'll have to knock my respect for PICs up another notch ;)

- --Brendan
- ---
"Rejection out of hand of all but one's favoured alternative may cost
you dearly in one way or another." -Russell McMahon

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>

iQA/AwUBPWKRuQVk8xtQuK+BEQKxXgCgyvfFqLZyzz7QzEpPjKR8RzwXLusAoJaj
TSZBIybzeJKkZ5bx9Tdx8Q1c
=evlQ
-----END PGP SIGNATURE-----

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\08\20@165004 by Wouter van Ooijen

face picon face
> > Now, see, if *I* were designing a processor, a reset (i.e. external
> > or reset instruction) would clear the entire contents of memory.

Luckily you don't, for this would kill some interesting applications,
like the reset-pin interface (chip measures the time between reset, uses
it as data input from user or maybe for bootloading or the like) and the
watchdog-temperature sensor (measure watchdog timeout to determine die
temperature).

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\08\20@172809 by Brendan Moran

flavicon
face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> > > Now, see, if *I* were designing a processor, a reset (i.e.
> > > external or reset instruction) would clear the entire contents
> > > of memory.
>
> Luckily you don't, for this would kill some interesting
> applications, like the reset-pin interface (chip measures the time
> between reset, uses it as data input from user or maybe for
> bootloading or the like)

Ok, fair enough on that one.  I've never heard of it being used
before, but fair enough.

> and the
> watchdog-temperature sensor (measure watchdog timeout to determine
> die temperature).

I can't even see how that's related.  I said in that post that most
of the existing "resets" used by Microchip were, in fact, just
interrupts that cleared the PCL.  I've always though that the
watchdog reset, should be considered the interrupt that it is, if you
want to use it as a reset, add a GOTO H'00' and you've got yourself a
"reset".

Walter Banks has mentioned a post crash dump as a useful debudding
tool.  That's fair enough, except that that can be handled by an
interrupt.

Let me play devil's advocate for a moment.

<devil's advocate>
I'm not arguing about convention, here.  I'm sure you're right on
that count.  I did say that if *I* were designing a processor, that's
what I'd do.  I see 4 real classes of processor break.

1) interrupt--  Processor goes to an interrupt handling routine.
Returns to code it was at upon completion.
2) partial reset-- (what Microchip calls a reset) PCL is returned to
0.  Stack contents are invalidated, if not deleted
3) full reset-- Processor is returned to its power on state.  RAM is
cleared.  all non-fused config is reset
4) power cycle-- Power to processot is removed and restored

There was a thread earlier about processor design, with respect to
the PICList having a special PICList processor built for us, which I
think is a great idea.

Since this all goes back to my statement "if *I* were designing a
processor" I guess I'm going to have to clarify more.

If I were designing a processor, there would be the full reset
conditions that I mentioned, and on top of that, there would be
prioritized interrupts (probably about 4, 8 or 16 levels), the
highest of which would be initiated without a question of GIE.  I
would make several external pins mapable to interrupts (of various
priorities)/normal I/O.  There would be one full-reset pin.  One that
basically erased all volatile RAM on the processor.  You can't get
more of a clean start than that.
</devil's advocate>

Now, I hope you can see that there are other functional schemes that
could use a full RAM clear in the reset process.  I don't think
there'd be much loss there, but there might be very little gain.
I'll leave that analysis to the professional chip designers.

- --Brendan
- ---
"Rejection out of hand of all but one's favoured alternative may cost
you dearly in one way or another." -Russell McMahon

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>

iQA/AwUBPWK0FwVk8xtQuK+BEQJRswCdGZCg3JlPoWQ5CXmeEPvP+eu7QRsAn2vK
amrBLY6rCpxq9WnnYt0atZ8w
=qpEv
-----END PGP SIGNATURE-----

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\08\20@173648 by Brendan Moran

flavicon
face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> >     Wow.
> >
> >     Where's the candle burning through the string, the
> > spring-loaded
> >     trapdoor through which the ball drops, the sprinkling can
> > that
> >     tips over and fills the boot with water, etc.?
>
> That will come in will come in the mk.2 version.

Ok, here's the Mk.2:

Determine the time it takes for the processor to be garaunteed to
have all its volatile RAM fail.  Program a one-shot to that length of
time.  Attach an edge triggered one-shot to the processor's power
pins.  Then, have the processor trigger the one-shot, which will
force it to power down, and stay off until all its RAM is gone.

I admit it's a little short of trap doors, and before you sneer at
me, consider the possibilities a bit.  If it takes less time for this
than the large volume of instruction cycles to clear all the RAM,
then it should be worth it, right?

- --Brendan
- ---
"Rejection out of hand of all but one's favoured alternative may cost
you dearly in one way or another." -Russell McMahon


-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>

iQA/AwUBPWK2aAVk8xtQuK+BEQIO3gCfRNWZgN1eKn6AjD/dZruz2lllwI4AoJfs
7FANypv2IvEp8Hu88X/8RmjY
=jGHf
-----END PGP SIGNATURE-----

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\08\20@184150 by Andrew Warren

flavicon
face
Brendan Moran <PICLISTEraseMEspam.....mitvma.mit.edu> wrote:

> I'm not arguing about convention, here.

   Brendan:

   I admire your independent thinking; it's nice to see someone
   discarding the usual assumptions and starting over from
   more-or-less basic principles.

   It's useful to keep in mind, though, that when you see a design
   feature common to nearly all microcontrollers, it probably exists
   for reasons other than arbitrary "convention".

> I hope you can see that there are other functional schemes that
> could use a full RAM clear in the reset process.  I don't think
> there'd be much loss there, but there might be very little gain.
> I'll leave that analysis to the professional chip designers.

   As a professional chip designer, I agree that a full RAM clear
   IS generally needed on reset.  However, I don't think it should
   automatically be performed by the hardware.

   I mean, even the 18F's RAM can be cleared in fewer than 12
   software instructions.  Even if the micro cleared all RAM
   automatically on reset, that 12-instruction routine would
   probably be in most programs anyway, in order to clear RAM when
   necessary under other circumstances (e.g., WDT reset).

   -Andy

=== Andrew Warren -- EraseMEaiwspamcypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\08\20@184335 by Andrew Warren

flavicon
face
Brendan Moran <RemoveMEPICLISTEraseMEspamEraseMEmitvma.mit.edu> wrote:

> Determine the time it takes for the processor to be garaunteed to
> have all its volatile RAM fail.  Program a one-shot to that length
> of time.  Attach an edge triggered one-shot to the processor's
> power pins.  Then, have the processor trigger the one-shot, which
> will force it to power down, and stay off until all its RAM is
> gone.
>
> I admit it's a little short of trap doors, and before you sneer at
> me, consider the possibilities a bit.  If it takes less time for
> this than the large volume of instruction cycles to clear all the
> RAM, then it should be worth it, right?

   Well, no... Not necessarily.  Length of time from power
   application to all RAM clear is rarely a critical factor in most
   designs.



{Quote hidden}

=== Andrew Warren -- RemoveMEaiwspam_OUTspamKILLspamcypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\08\20@185632 by Andrew Warren

flavicon
face
   ---------------------------------------
   Whoops, accidentally hit SEND too soon.
   ---------------------------------------

Brendan Moran <RemoveMEPICLISTTakeThisOuTspamspammitvma.mit.edu> wrote:

> Determine the time it takes for the processor to be garaunteed to
> have all its volatile RAM fail.  Program a one-shot to that length
> of time.  Attach an edge triggered one-shot to the processor's
> power pins.  Then, have the processor trigger the one-shot, which
> will force it to power down, and stay off until all its RAM is
> gone.

   Brendan:

   The time for RAM to fail -- to "forget" its contents -- can be
   VERY long:  Many seconds at room temperature, and much longer at
   low temperatures.

   Also... RAM "failure" isn't the same as RAM "clear".  RAMs
   generally power-up in an arbitrary state, so even removing power
   for a year won't ensure that the RAM would be clear on power-up.

> I admit it's a little short of trap doors, and before you sneer at
> me, consider the possibilities a bit.

   No sneering here.  I hope you didn't take offense at my earlier
   comment; none was intended.

> If it takes less time for this than the large volume of instruction
> cycles to clear all the RAM, then it should be worth it, right?

   Well, no, not necessarily.  Length of time from power application
   to all RAM clear is rarely a critical factor in a circuit design.


   -Andy

=== Andrew Warren -- EraseMEaiwspamspamspamBeGonecypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\08\20@190102 by Tom Messenger

flavicon
face
At 03:47 PM 8/20/02 -0700, you wrote:
>Brendan Moran <RemoveMEPICLISTKILLspamspammitvma.mit.edu> wrote:
>
>> Determine the time it takes for the processor to be garaunteed to
>> have all its volatile RAM fail.

Fail? Do you mean here to have all ram go "clear"?

If so, you will find that you must wait forever. You have no guarantee that
the ram will be "clear" (zero, or whatever) at power up.

You don't know what ram will be at power up.  This is exactly why people
who care write routines to clear ram at the beginning of their programs. Or
set it to some other known state.

A colleague once demonstrated to me how easy it was to write a quick 10
step program and load it into an 1802 processor via a terminal program.
The target system had a solenoid and his program made it click on/off at
about a 1Hz rate.  Thinking to clear it from memory, he turned the power
off for a couple of seconds and back on. The solenoid began to click again.
The memory had not cleared.

A voltmeter revealed that the ram power had indeed dropped to below .5
volts but it did not forget.  We tested some more and found that the power
could be off for over 45 seconds before the program would not run at power
up, ie, it had scrambled at least one ram location needed for the program.

Tom M.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\08\20@190256 by Brendan Moran

flavicon
face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> > I'm not arguing about convention, here.
>
>     Brendan:
>
>     I admire your independent thinking; it's nice to see someone
>     discarding the usual assumptions and starting over from
>     more-or-less basic principles.

Thanks :)

>     It's useful to keep in mind, though, that when you see a design
>     feature common to nearly all microcontrollers, it probably
> exists
>     for reasons other than arbitrary "convention".

Respecting your professional opinion, I should point out that that is
not always the case.  Witness the convention across the
microcontroller board of using register or acumulator oriented
operations where a stack would be far more effective.  Now, of
course, the reason for that is that it's easier for programmers to
understand, but at the same time, your system takes a performance hit
for staying in the game that way.

> > I hope you can see that there are other functional schemes that
> > could use a full RAM clear in the reset process.  I don't think
> > there'd be much loss there, but there might be very little gain.
> > I'll leave that analysis to the professional chip designers.
>
>     As a professional chip designer, I agree that a full RAM clear
>     IS generally needed on reset.  However, I don't think it should
>     automatically be performed by the hardware.

Perhaps, then, a RAMCLR instruction which will dump all the RAM on
the processor?  Or all of it except for a protected zone?

>     I mean, even the 18F's RAM can be cleared in fewer than 12
>     software instructions.  Even if the micro cleared all RAM
>     automatically on reset, that 12-instruction routine would
>     probably be in most programs anyway, in order to clear RAM when
>     necessary under other circumstances (e.g., WDT reset).

Fair enough, though I haven't been able to figure out why a routine
like this would be implemented in the first place.  It sounds to me
like exactly the kind of coding practice that we are commonly advised
to avoid: why do you need to clear all the RAM, when you should be
assuming that it's all full of garbage anyways?

Well, now that I think about it, I can see some potential uses, like
a large data array that needs to be full of 0s, but in general, I
can't really see the need for something like that at all...

- --Brendan
- ---
"Rejection out of hand of all but one's favoured alternative may cost
you dearly in one way or another." -Russell McMahon

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>

iQA/AwUBPWLKaAVk8xtQuK+BEQJPJwCgrPreMONw2wLWfx6UobJ9/5VfGXAAoI2Q
aDcP3xn2vCV/5PNg3yWh6LP7
=KgA8
-----END PGP SIGNATURE-----

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\08\20@191953 by Brendan Moran

flavicon
face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>     No sneering here.  I hope you didn't take offense at my earlier
>     comment; none was intended.

You aren't the target of that jibe, it was a general comment about
the inability of the human race as a whole to accept ideas that
either they didn't come up with, or that they don't like--See my
tagline.  Some are better at handling things like that than others.

- --Brendan
- ---
"Rejection out of hand of all but one's favoured alternative may cost
you dearly in one way or another." -Russell McMahon

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>

iQA/AwUBPWLOdgVk8xtQuK+BEQKWSgCglQnqaY7BRInh5O11mibLSxRWM2sAoJPy
2vW/05jd6AeftUo6YQ0ToMYP
=VKew
-----END PGP SIGNATURE-----

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\08\20@192407 by Brendan Moran

flavicon
face
> >> Determine the time it takes for the processor to be garaunteed to
> >> have all its volatile RAM fail.
>
> Fail? Do you mean here to have all ram go "clear"?
>
> If so, you will find that you must wait forever. You have no guarantee
that
> the ram will be "clear" (zero, or whatever) at power up.

Well, I said if that time was shorter than the time for it to execute the
clear then it was worth it, but if not, it was not, it appears that the time
for the RAM to clear is longer than the time for the program to run, and
thus the suggestion has no merit.  I thought I had implied that that could
be the case in my post.

--B-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

At 03:47 PM 8/20/02 -0700, you wrote:
>Brendan Moran <PICLISTSTOPspamspamspam_OUTmitvma.mit.edu> wrote:
>
>> Determine the time it takes for the processor to be garaunteed to
>> have all its volatile RAM fail.

Fail? Do you mean here to have all ram go "clear"?

If so, you will find that you must wait forever. You have no
guarantee that
the ram will be "clear" (zero, or whatever) at power up.

You don't know what ram will be at power up.  This is exactly why
people
who care write routines to clear ram at the beginning of their
programs. Or
set it to some other known state.

A colleague once demonstrated to me how easy it was to write a quick
10
step program and load it into an 1802 processor via a terminal
program.
The target system had a solenoid and his program made it click on/off
at
about a 1Hz rate.  Thinking to clear it from memory, he turned the
power
off for a couple of seconds and back on. The solenoid began to click
again.
The memory had not cleared.

A voltmeter revealed that the ram power had indeed dropped to below
.5
volts but it did not forget.  We tested some more and found that the
power
could be off for over 45 seconds before the program would not run at
power
up, ie, it had scrambled at least one ram location needed for the
program.

Tom M.

- --
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>

iQA/AwUBPWLPHAVk8xtQuK+BEQKJBgCfVQ6vKIpccsPdb+nkCydGVwKDpzcAnigR
9OrvA07fXk6QJCHP22SuP77t
=peOo
-----END PGP SIGNATURE-----
rendan
---
"Rejection out of hand of all but one's favoured alternative may cost you
dearly in one way or another." -Russell McMahon

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\08\20@192611 by Brendan Moran

flavicon
face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Whups.  Have to be careful when using the PGP plugin to not do
anything while it's manipulating data.

> >> Determine the time it takes for the processor to be garaunteed
to
> >> have all its volatile RAM fail.
>
> Fail? Do you mean here to have all ram go "clear"?
>
> If so, you will find that you must wait forever. You have no
guarantee
that
> the ram will be "clear" (zero, or whatever) at power up.

Well, I said if that time was shorter than the time for it to
execute the
clear then it was worth it, but if not, it was not, it appears that
the time
for the RAM to clear is longer than the time for the program to run,
and
thus the suggestion has no merit.  I thought I had implied that that
could
be the case in my post.

--Brendan
---
"Rejection out of hand of all but one's favoured alternative may
cost you
dearly in one way or another." -Russell McMahon

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>

iQA/AwUBPWLPsQVk8xtQuK+BEQIe4wCglCniLATsKlb++LRCwQllpLmiAG0AoPDK
2q+3UkJDlYnrZoHr89mqVnhJ
=ZlSk
-----END PGP SIGNATURE-----

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\08\21@043154 by Alan B. Pearce

face picon face
>I'm sure that you can see the value of that kind of addressing
>when attempting to handle larger blocks of data.  You know,
>having 1k of RAM minimum?

Sure there are no post-operation inc or dec instructions, but I would have
thought that using the decfsz instruction on the FSR in the 16 series would
be a help here. I have not checked to see how this is done on the 18 series
yet.

--
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


2002\08\21@060428 by Michael Rigby-Jones

flavicon
face
> -----Original Message-----
> From: Brendan Moran [SMTP:spamBeGonebmoranSTOPspamspamEraseMEMILLENNIUM.CA]
> Sent: Tuesday, August 20, 2002 6:54 PM
> To:   KILLspamPICLISTspamBeGonespamMITVMA.MIT.EDU
> Subject:      Re: [PIC]: Challenge: 18F Clear RAM
>
> (yes, there are 5 (maybe 6) seperate registers
> that are all useable as indexes on some processors, 2 of which are
> 8-bit, and the rest are 16) to act as an index, and then you can
> specify an offset from that address, or do a pre/post
> increment/decrement by any value up to 9 bits.(I think.  I haven't
> looked at the specifics in 5 months)  Any time an instruction with a
> pre/post increment/decrement is used, the specified index register is
> incremented/decremented by the specified value, andstored back to
> itself.
>
Something about grandmothers and eggs springs to mind!  I'm sure Scott is
aware of more different processor architectures than most of us have had hot
dinners..

Mike

--
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


2002\08\21@085832 by Bob Ammerman

picon face
The 18F _does_ have additional addressing modes. It has 3 12-bit FSRs:

FSR0H:FSR0L, FSR1H:FSR1L and FSR2H:FSR2L

By accessing the pseudo-registers INDF0, INDF1 and INDF2 you get indirect
addressing, just like on the 16 series.

You can also access POSTINC0, POSTINC1 and POSTINC2 for indirect addressing
with post increment.

Then there is POSTDEC0, POSTDEC1 and POSTDEC2 for indirect addressing with
post decrement.

And even PREINC0, PREINC1 and PREINC2 for indirect addressing with
pre-increment.

A combination of PREINCx and POSTDECx allows for convenient stack
operations.

Note that all increment and decrement operations on the FSRs include all 12
bits of the FSR.

Finally, you can use PLUSW0, PLUSW1 and PLUSW2 to access the memory location
at FSRn + WREG. Again the addition includes all 12 bits of the FSR.

Bob Ammerman
RAm Systems


{Original Message removed}

2002\08\21@090302 by Olin Lathrop

face picon face
> If I were designing a processor, there would be the full reset
> conditions that I mentioned, and on top of that, there would be
> prioritized interrupts (probably about 4, 8 or 16 levels), the
> highest of which would be initiated without a question of GIE.  I
> would make several external pins mapable to interrupts (of various
> priorities)/normal I/O.  There would be one full-reset pin.  One that
> basically erased all volatile RAM on the processor.  You can't get
> more of a clean start than that.

Many of these things have been done on various processors, except that I
don't know of any processor that does a deliberate hardware RAM clear on
power up.  If you really want that, you can always clear the RAM in software
immediately after a reset.  The rest of the things you mentioned are an
issue of cost versus features tradeoff.  Small microcontrollers for embedded
applications are very cost sensitive.  In that kind of an environment adding
the features you described would be mostly silly.  Put another way, if I can
get a 16F876 for $4.00, I wouldn't pay $4.10 for the same processor with
these features added, at least not for the vast majority of applications.

> I'll leave that analysis to the professional chip designers.

Yes, please do.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.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


2002\08\21@090746 by Olin Lathrop

face picon face
> Determine the time it takes for the processor to be garaunteed to
> have all its volatile RAM fail.

That's...

Oh, never mind, what's the point.  <walking away throwing hands up in
disgust>


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.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


2002\08\21@092822 by Dave Tweed

face
flavicon
face
Brendan Moran <EraseMEbmoranspamEraseMEMILLENNIUM.CA> wrote:
> Respecting your professional opinion, I should point out that that is
> not always the case.  Witness the convention across the
> microcontroller board of using register or acumulator oriented
> operations where a stack would be far more effective.  Now, of
> course, the reason for that is that it's easier for programmers to
> understand, but at the same time, your system takes a performance hit
> for staying in the game that way.

If you really believe that, you should check out Chuck Moore's X18
microcomputer core, and support the development of his 25x multicomputer
chip.

  http://www.mindspring.com/~chipchuck/

I guess I can agree that in deeply-embedded applications, using
non-von-Neumann architectures (separate memories for code and stacks),
a 0-address (stack) architecture can be very efficient. However, for
general-purpose computing, it is actually much easier to achieve high
performance and exploit parallelism with a 3-address instruction set
architecture, in which the two source addresses and destination address
of a binary operation can be independently specified. Some things you can
do with a single 3-address instruction often take 5-7 (or more) 0-address
instructions to duplicate.

-- Dave Tweed

--
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


2002\08\21@094440 by Olin Lathrop

face picon face
> Witness the convention across the
> microcontroller board of using register or acumulator oriented
> operations where a stack would be far more effective.

Brendan, where DO you get this stuff from?  Frankly, you don't know what
you're talking about.  Your statement might leave some people with the
impression that it well known that a "stack" architecture is inherently
superior to an "accumulator oriented" architecture.  This is completely
untrue.

If you have opinions about these things, please label them as such so that
others listening in that may be trying to learn don't take your statements
as fact.  If you just want to start a debate founded on religious beliefs,
take it somewhere else.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.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


2002\08\21@100752 by Russell McMahon

face
flavicon
face
> If you just want to start a debate founded on religious beliefs,
> take it somewhere else.

How can you say that in a group who all use PICs :-) ?


           RM

--
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


2002\08\21@102730 by Alan B. Pearce

face picon face
>Many of these things have been done on various processors,
>except that I don't know of any processor that does a
>deliberate hardware RAM clear on power up.

The nearest I have found to doing this is on power up to initialise dynamic
RAM chips. One processor I worked on would write to one location in each
DRAM on a power up reset, and this would pre-charge the internal circuitry
enough for the RAN to work properly immediately. I suspect this is part of
the reason why every PC does a RAM "test" on power up as well. This is not a
problem with static RAM chips.

A read through the micro code listing for the one I dealt with showed that
during code development they had a 30 second delay to wait for the RAM to
initialise before they put in the "write to one location in each chip" code.

--
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


2002\08\21@124805 by Brendan Moran

flavicon
face
> Brendan, where DO you get this stuff from?

I was under the impression that numeric computation was, in general, faster
for multiple instructions on a stack oriented machine.

I read a large document about FPGA CPU design off of Xilinx's website that
discussed at least a part of the process for selecting an architecture

Xilinx, incidentally, has a great section of technical resources, provided
that you can find them.  The series on designing PSMs quite good, if you ask
me.

http://www.xilinx.com/support/techxclusives/techX-home.htm

The document http://www.xilinx.com/support/techxclusives/PSM2-techX26.htm is
part of a series on embedded CPU design, and contains this statement:

>The stack architecture is probably the most efficient in terms of silicon
resources, >as it links directly to memory that is forming the stack and
requires no data >selection logic other than the stack pointer. The
instruction encoding is also very >efficient because the location of both
operands and the result are implied as >being the top of the stack.

>However, even more instructions (stack PUSH and stack POP) are expended >to
ensure that the correct data is located at the top of the stack. Correct
>sequencing of the ALU operations will result in excellent code density and
>execution speed, but this "reverse polish" style does not come naturally to
most >of us and greatly impacts the desire to utilize a PSM that provides an
easy >methodology for implementing complex state machines.

At the end of the discussion on which architecture to use, the conclusions
were:

- The stack architecture is not the best choice, as the methodology is too
cumbersome.
- The accumulator structure seems reasonable, but expending too many
instructions to move data is a concern given limited program memory space.
- The register architecture appears to be the best for PSM applications, but
it could be expensive.

From this, I concluded that a stack orientation was the best in terms of
execution speed, code density, and silicon resources, but was complex to
use, when programming in assembly, and was therefore not used much.  It is
entirely possible that I misinterpreted the conclusion statements there, and
am entirely off-base.

I have found few other comparisons between the various architectures
available, but I would be happy to read any that you know of, if you will
provide me the links.

--Brendan

--
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


2002\08\21@131539 by Brendan Moran

flavicon
face
> > Brendan, where DO you get this stuff from?

>From this, I concluded that a stack orientation was the best in terms of
> execution speed, code density, and silicon resources, but was complex to
> use, when programming in assembly, and was therefore not used much.  It is
> entirely possible that I misinterpreted the conclusion statements there,
and
> am entirely off-base.

I should point out that after playing around with an arbitrary expression,

(a^2+b)*b/(c+d) -e

it seems that the stack solution took more instructions than the other two
architectures.  Perhaps that's not true for all expressions, perhaps it is,
and perhaps I was taking something for granted that I shouldn't.

One thing to be sure of, though, is that stack make subroutine calls a lot
nicer.  But, then that can be done on any system that has a stack pointer,
or something that can be used as one.

--Brendan

--
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


2002\08\21@132407 by Olin Lathrop

face picon face
> >The stack architecture is probably the most efficient in terms of silicon
> resources, >as it links directly to memory that is forming the stack and
> requires no data >selection logic other than the stack pointer. The
> instruction encoding is also very >efficient because the location of both
> operands and the result are implied as >being the top of the stack.
>
> >However, even more instructions (stack PUSH and stack POP) are expended
>to
> ensure that the correct data is located at the top of the stack. Correct
> >sequencing of the ALU operations will result in excellent code density
and
> >execution speed, but this "reverse polish" style does not come naturally
to
> most >of us and greatly impacts the desire to utilize a PSM that provides
an
> easy >methodology for implementing complex state machines.

In otherwords (surprise, surprise), there are tradeoffs, and different
choices may be appropriate in different circumstances.  This is also just
one person's or organization's view.

> At the end of the discussion on which architecture to use, the conclusions
> were:
>
> - The stack architecture is not the best choice, as the methodology is too
> cumbersome.
> - The accumulator structure seems reasonable, but expending too many
> instructions to move data is a concern given limited program memory space.
> - The register architecture appears to be the best for PSM applications,
but
> it could be expensive.
>
> From this, I concluded that a stack orientation was the best in terms of
> execution speed, code density, and silicon resources, but was complex to
> use, when programming in assembly, and was therefore not used much.

I think that is jumping to a conclusion too quickly.  Computer architecture
is quite an envolved field that people spend their entire careers on.  I
don't think you will find wide agreement that any one architecture is
"best", whether easily programmable by humans or not.  Borroughs used to
make a line of machines that did use a stack model.  They were reasonably
successful for a while.  HP calculators are famous for using a stack model.
That's what I use personally.  (I have two HP 11C calculators that are now
20 years old and still in active use).

However, other intelligent people have evaluated architectures and not
chosen stack-based.  I don't think that the supposed difficulty of
programming them in assembler is legitimate factor.  This would have been
far more true in Borroughs' time, but today general purpose CPUs are
programmed in high level languages.

> It is
> entirely possible that I misinterpreted the conclusion statements there,
and
> am entirely off-base.
>
> I have found few other comparisons between the various architectures
> available, but I would be happy to read any that you know of, if you will
> provide me the links.

I think there is a lot more to the architectural tradeoffs than the little
presented here.  Developing a new machine is an expensive enterprise, so
this sort of thing gets studied very carefully by experts.  Occasionally
something dubious does make it to market, or a strange arhchitecture evolves
over time due to compatibility concerns.  However, I would at least start
out assuming that choices were carefully made and only decide otherwise
after collecting sufficient information to make the case.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.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


2002\08\21@133223 by Olin Lathrop

face picon face
> (a^2+b)*b/(c+d) -e
>
>  it seems that the stack solution took more instructions than the other
two
> architectures.  Perhaps that's not true for all expressions, perhaps it
is,
> and perhaps I was taking something for granted that I shouldn't.

Stack:

 push A
 push A
 mult
 push B
 add
 push B
 mult
 push C
 push D
 add
 divide
 push E
 sub

 13 "instructions" in all

Single ACC:

 load C
 add D
 store TEMP

 load A
 mult A
 add B
 mult B
 divide TEMP
 sub E

 9 "instructions" in all, 1 temp location

However, the differences go far beyond these narrow examples.  There are
issues of how fast these instructions can be executed, how wide they need to
be, etc.  There's a lot more to it.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.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


2002\08\21@133228 by Wouter van Ooijen

face picon face
A good book to read on the subject: computer architecture, a quantative
approach (hennessy/patterson). The main pitfall when taken design
descisions for granted that might have been correct decades ago is that
some figures change over time, like

- ratio on on-chip speed versus chip-to-chip speed
- ratio of CPU speed versus memory speed
- density (hence cost) of random logic versus memory
- density of various memory cells (volatile, static, non-volatile)

Some circumstances, like the need to be rad-hard, can resurrect a
once-interesting but now abandoned architecture like the single-stack
machine to be interesting again.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
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


2002\08\21@134434 by Brendan Moran

flavicon
face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> In otherwords (surprise, surprise), there are tradeoffs, and
> different choices may be appropriate in different circumstances.
> This is also just one person's or organization's view.

I did note that, and ask for more sources...

> I think that is jumping to a conclusion too quickly.  Computer
> architecture is quite an envolved field that people spend their
> entire careers on.

Fair enough.

{Quote hidden}

I am not entirely sure that that is not simply a carry-over from days
past.  I.e. people still don't use x processor architecture because
people just don't use that architecture.  Sometimes that happens.
Not always, but in some cases, that's the reasoning.

> I think there is a lot more to the architectural tradeoffs than the
> little presented here.  Developing a new machine is an expensive
> enterprise, so this sort of thing gets studied very carefully by
> experts.  Occasionally something dubious does make it to market, or
> a strange arhchitecture evolves over time due to compatibility
> concerns.  However, I would at least start out assuming that
> choices were carefully made and only decide otherwise after
> collecting sufficient information to make the case.

I agree that there is a lot more to it.  These were conclusions based
on a single application (that of the programable state machine).
And, just a note:  Developing a new machine is not that expensive
with the use of FPGAs.  It is expensive only in terms of time.  And
high level languages to describe the flow of the device make the
development time somewhat shorter.

As to dubious things making it to the market, I have been told,
though I am uncertain as to the validity of the source, that the x86
architecture is pretty awful.  A similar source once told me that the
architecture of the Intel processors would be a limiting factor in
their attainable maximum speed, and that the AMD architecture (which
is different though it uses an almost identical instruction set, or
so I am told) is slightly better, though hampered by the klunky
instruction set.  I don't know whether to believe this or not, but
there it is.

- --Brendan

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>

iQA/AwUBPWPQ/wVk8xtQuK+BEQKKMgCcCO8V6Siex2iizfXP3Z8K9DcKd1AAoI17
mcxgCBu7o6lTeQUYfSiGfEcC
=4F5L
-----END PGP SIGNATURE-----

--
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


2002\08\21@134924 by Brendan Moran

flavicon
face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

{Quote hidden}

push e
push d
push c
add
push b
push b
push a
push a
mult
add
mult
div
sub

13 inst.


{Quote hidden}

Pretty much the same, there.

Here's one for a multi-register machine (only valid for one that
can't operate directly on something outside its working register
space)
Register:

mov 1,a
mov 2,a
mult 1,2
mov 2,b
add 1,2
mult 1,2
mov 2,c
mov 3,d
add 2,3
mov 3,e
div 1,2
sub 1,3

12 inst.

> However, the differences go far beyond these narrow examples.
> There are issues of how fast these instructions can be executed,
> how wide they need to be, etc.  There's a lot more to it.

I realise that, of course.  The less logic is required for selecting
data, the faster the processor can operate, the less space it take,
the cooler it runs, etc...

I wonder if there's another way of doing it... An architecture that
could, for example, take the best out of all three of the common
ones, and use them all...

- --Brendan

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>

iQA/AwUBPWPSUgVk8xtQuK+BEQIJhACePwvx/ughtLkxtWakRRKvB+2/JR8An0sy
8qDCWF3eOQq4Aw33QUCa2mBV
=wGeP
-----END PGP SIGNATURE-----

--
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


2002\08\21@142237 by Wouter van Ooijen

face picon face
> it seems that the stack solution took more instructions
> than the other two architectures.

Quite probably, yes. But it is not very relevant. More to the point is
how large the total instruction stream (in bits) would be for the three
variants. But for 'modern' situations the data stream is often the
bottleneck (note that this used to be different).

One of the issues that work against a (single) stack architecture is
pipelining, and hence stalls due to (data) dependencies. In a register
architecture you can often arrange instructions to avoid using the
result of a previous instructions, this is hard to do on a stack
machine.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
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


2002\08\21@171944 by Dave Tweed

face
flavicon
face
Brendan Moran <@spam@bmoran@spam@spamspam_OUTMILLENNIUM.CA> wrote:
> As to dubious things making it to the market, I have been told,
> though I am uncertain as to the validity of the source, that the x86
> architecture is pretty awful.  A similar source once told me that the
> architecture of the Intel processors would be a limiting factor in
> their attainable maximum speed, and that the AMD architecture (which
> is different though it uses an almost identical instruction set, or
> so I am told) is slightly better, though hampered by the klunky
> instruction set.  I don't know whether to believe this or not, but
> there it is.

Believe it.

If you study the architecture of modern Pentiums carefully, you'll see that
Intel is taking extreme measures to wring the last bit of performance out
of the x86 ISA, including translating sequences of x86 instructions on the
fly, in hardware, to an underlying 3-address architecture that is easier to
pipeline.

Transmeta is trying to make money on the concept of doing this entirely in
software, saving huge amounts of chip area and power consumption relative
to the hardware approach.

Olin mentioned Burroughs stack machines earlier. I used to work for
Burroughs (now part of Unisys) back in the early 1980s. They finally
standardized on a stack-oriented ISA called EMODE. At that time, they were
taking a similar approach to extracting the maximum performance out of the
ISA -- translating (in hardware) sequences of 5-9 EMODE instructions into
3-address instructions that the underlying hardware actually executed, and
caching the translations in a special memory area.

{Quote hidden}

Let's assume the five values are already in registers 1-5. A 2-address ISA
would require the following sequence, assuming you want to preserve the
input values:

  mov 6,1
  mult 6,1
  add 6,2
  mult 6,2
  mov 7,3
  add 7,4
  div 6,7
  sub 6,5

8 instructions

A 3-address ISA eliminates the register-to-register moves:

  mult 6,1,1
  add 6,6,2
  mult 6,6,2
  add 7,3,4
  div 6,6,7
  sub 6,6,5

6 instructions, and every instruction performs a computation specified by
the application.

-- Dave Tweed

--
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 2002 , 2003 only
- Today
- New search...