Searching \ for '[PIC]: Function pointers in assembly?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/microchip/devices.htm?key=pic
Search entire site for: 'Function pointers in assembly?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Function pointers in assembly?'
2003\06\12@212005 by Picdude

flavicon
face
In lots of my (assembly) code, I'm creating a "switch" statement manually as follows...
   Case:
   TryOption1:
       movlw        D'1'
       subwf        SOME_VAR,W
       btfss        STATUS,Z
       goto        TryOption2
       < Do option 1 stuff >
       goto        EndCase

   TryOption2:
       movlw        D'2'
       subwf        SOME_VAR,W
       btfss        STATUS,Z
       goto        TryOption3
       <Do option 2 stuff >
       goto        EndCase

       ....
       ....
   End Case:


It's a bit inefficient, and illegible (because the options spread over many pages of code).  I can put the actions for the options in subroutines and call them or goto them, but I'm wondering why I can't do something like function pointers....

Possibility 1....

   Case:
       movf                HIGH FunctionPointers,W
       movwf        PCLATH
       movf                SOME_VAR,W
       addwf        PCL,F
   FunctionPointers:
       goto                Option1Actions
       goto                Option2Actions
       ....
       ...
   EndCase:


All Option?Actions will end with "goto EndCase".


Possibility 2....

   Case:
       movf                HIGH FunctionPointers,W
       movwf        PCLATH
       bcf                STATUS,C
       rlf                SOME_VAR,W                ; Multiply by 2
       addwf        PCL,F
   FunctionPointers:
       call                Option1Actions
       goto                EndCase                ; Or "return" if this case-stmt was called.
       call                Option2Actions
       goto                EndCase                ; Or "return" if this case-stmt was called.
       ....
       ...
   EndCase:


Here, each Option?Actions routine would end with "return".  This second possibility would use up another stack level.  But it seems more modular, and less prone to stupid death in future modifications.

I haven't tested these, and I know I'll have some housekeeping to do with PCLATH, aligning to page boundaries, etc.  But can anyone see why this could not work?

Cheers,
-Neil.

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

2003\06\13@004457 by Sergio Masci

picon face
> Possibility 1....
>
>    Case:
>        movf HIGH FunctionPointers,W
>        movwf PCLATH
>        movf SOME_VAR,W
>        addwf PCL,F
>    FunctionPointers:
>        goto Option1Actions
>        goto Option2Actions

try it this way instead

   Case:
       movlw     HIGH FunctionPointers
       movwf     PCLATH
       movf     SOME_VAR,W
       addlw     LOW FunctionPointers
       btfsc    STATUS,C
       incf     PCLATH
       movwf     PCL

   FunctionPointers:
       goto Option1Actions
       goto Option2Actions


Your function pointer table may also need to look like this:

   FunctionPointers:
       movlw    high Option1Actions
       movwf    PCLATH
       goto     Option1Actions
       nop

       movlw    high Option2Actions
       movwf    PCLATH
       goto     Option2Actions
       nop

       movlw    high Option3Actions
       movwf    PCLATH
       goto     Option3Actions
       nop


Regards
Sergio Masci

http://www.xcprod.com
Assemblers, Simulators, Compilers, CASE tools

XCSB - Structured PIC BASIC Compiler
Free for personal non-commercial use.

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

2003\06\13@013626 by Picdude

flavicon
face
On Thursday 12 June 2003 23:16, Sergio Masci scribbled:
> > Possibility 1....
> >
> >    Case:
> >        movf HIGH FunctionPointers,W
> >        movwf PCLATH
> >        movf SOME_VAR,W
> >        addwf PCL,F
> >    FunctionPointers:
> >        goto Option1Actions
> >        goto Option2Actions
>
> try it this way instead
>
>     Case:
>         movlw     HIGH FunctionPointers

Oops... yes, that should've been "movlw".


{Quote hidden}

Ahhh.... you're computing instead.  That's good.


{Quote hidden}

Hopefully won't.  I'm doing this on a 16F628 (2k), and hoping that I can squeeze it into a 16F627 (1k), so page boundaries mean nothing to me!

In this case as well, I'd need to multiply SOME_VAR by 4 before adding it to the future PC value.

Must try this tomorrow.

Cheers,
-Neil.

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

2003\06\13@082441 by Olin Lathrop

face picon face
>     Case:
>         movf HIGH FunctionPointers,W

That should be MOVLW functionpointers

>         movwf PCLATH
>         movf SOME_VAR,W

Assuming SOME_VAR can be access with the current bank settings, and
contains the 0-N opcode.

>         addwf PCL,F
>     FunctionPointers:
>         goto Option1Actions
>         goto Option2Actions
>         ....
>         ...
>     EndCase:

Yes, you've managed to reinvent a primitive jump table.  This will work as
long as the table doesn't cross a 256 word boundary because you ignored
any carry from adding to PCL.

> I haven't tested these, and I know I'll have some housekeeping to do
> with PCLATH, aligning to page boundaries, etc.

But those are exactly the issues that need to be worked out with PIC
tables.  Anyone can make a jump table that doesn't work, big deal.

See the HOS_CMD.ASPIC module of my HOS project at
http://www.embedinc.com/pic/hos.htm.  This is real tested code of a
command processor thread that uses a jump table to dispatch to specific
command routines based on an opcode byte.  As you can see, there's a bit
more to it if you'd like it to actually work.  It's also documented.  Gee,
what a concept.  Can you say "COM-MENTS"?  Try it: "COM-MENTS, COM-MENTS".
Very good, I knew you could.


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

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

2003\06\13@150153 by Picdude

flavicon
face
Sergio,

I got this working last night -- was actual quite simple indeed.

Thanks much.
-Neil.


On Friday 13 June 2003 00:35, Picdude scribbled:
{Quote hidden}

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

2003\06\13@185705 by Picdude

flavicon
face
On Friday 13 June 2003 07:22, Olin Lathrop scribbled:
> Yes, you've managed to reinvent a primitive jump table.  This will work as
> long as the table doesn't cross a 256 word boundary because you ignored
> any carry from adding to PCL.

Which is because it's pseudo-code and explained to be such with this following statement...

> > I haven't tested these, and I know I'll have some housekeeping to do
> > with PCLATH, aligning to page boundaries, etc.

My point was that I was trying to see if I could use a "standard" table-lookup routine for a switch statement implementation, and thought it would be good to get opinions from the more experienced on this list.


{Quote hidden}

What's your point here Olin?  If as you say "anyone can make a jump table ..." etc, then why do YOU, the mighty brain of all, need comments?  And more importantly, do you think your need/request for comments warrants your childish attitude here?  There's a saying that (paraphrased) there are two types of great people in this world -- those that become great by doing great things, and those that think they're great by bringing everyone down.  Figure out where you fit in, since you're so "great"!  You love nitpicking over other's mistakes and way of doing things that are not *exactly* the way you would do it, but does that mean the other points-of-view are not valid?  If you can't understand this pseudo-code, then why bother responding at all?  Do you really think I'll apologize and repost the code with comments just for you?  Or do you think I'll take it as a slap on the wrist and go whimpering back to a corner?  Perhaps you think everyone else will see you as a perfectionist?  What's your intention?  Why bother to waste time typing up a reply here?  I have received other (very helpful) responses from others who seem intelligent enough to understand the pseudo-code, so I feel sorry for you that you cannot understand it.

At this point, I'll appeal to any minute sense of maturity you have to just not respond in these circumstances where you do not have anything valuable to add.  And if you have criticism, there are better ways to state it, else STFU.

Cheers,
-Neil.

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

2003\06\14@075051 by Olin Lathrop

face picon face
> then why do YOU ... need comments?

Comments are an integral part of the code.  Yes, I could see what this
snippet did, but the point is to get people to do things right, especially
before asking 2000 people for a favor.  In this case, I think I understood
what you thought the code was doing or intended it to do, but often we see
code posted here where that is not the case.

You should get into the habit of commenting your code carefully.  You'll
probably be surprised how many little bugs and typos you catch by forcing
yourself to explain each line to a hypothetical person looking over your
shoulder.  This is the cheapest way to find bugs.  Even one simulator
session is worth a whole page of comments.  I think there is a good chance
you would have seen your MOVLW error on your own if you had tried to
explain the meaning of each line.

In other words, good commenting speeds up code development, makes the code
more reliable, makes it less likely you need to ask others for help, and
makes it easier for them to help you if you do.  Given all that, it's
frankly irresponsible not to do it.

> And more importantly, do you think your need/request for
> comments warrants your childish attitude here?

The need for comments has been stated here many many times.  If good
coding practise, common sense, and respect of others doesn't get you to do
it, maybe public humiliation would at least shame you to do it.

> If you can't understand this pseudo-code, then why bother responding
> at all?

Actually, I showed you a bug in your code, and pointed you to a complete
documented and tested working example that you can download for free.


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

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

2003\06\14@153102 by Mike Singer

picon face
Hi, Neil,

Please blame me as hard as you can, when I post nonsense
like your post against Olin right to express his approach.

Asking questions like "why bother responding at all?" is
Admin's work, not yours, as for me.

Say "thank you for having different opinion" to Olin, maybe
he is right; who knows; at least he sure is not a "Dude".

Personally, I've found his "common theme" post very
interesting regardless of do I agree with him or not.
In fact, I'd state his "common theme" thoughts are much
more useful to newbies and dudes :-) than just "plain"
replies.(They could save them from staying newbies and
dudes forever)

I think that taking few hours break before posting such
insulting things isn't a bad idea. (Still, I wish I could
resist to respond quickly)

Best Wishes,
Mike.

P.S. I agree with Olin on the subject; perhaps he was too
mild replying to your post :-)



Pic_DUDE_ wrote:
{Quote hidden}

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

2003\06\16@044128 by Alan B. Pearce

face picon face
>Hopefully won't.  I'm doing this on a 16F628 (2k), and hoping that I can
>squeeze it into a 16F627 (1k), so page boundaries mean nothing to me!

Just do not forget that for a jump table like this, you have to remember
that it works in 256 byte pages, not the 2k code page boundaries.

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

2003\06\16@061601 by Picdude

flavicon
face
On Monday 16 June 2003 03:41, Alan B. Pearce scribbled:
> >Hopefully won't.  I'm doing this on a 16F628 (2k), and hoping that I can
> >squeeze it into a 16F627 (1k), so page boundaries mean nothing to me!
>
> Just do not forget that for a jump table like this, you have to remember
> that it works in 256 byte pages, not the 2k code page boundaries.

Yes.  I'm using the anywhere-in-code-space version now during development, but will optimize later once I ensure I put them in non-boundary-crossing locations.  All because I know I expect I'll end up squeezing as much as possible into the available code memory.

Cheers,
-Neil.

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

2003\06\16@151526 by William Chops Westfield

face picon face
do not forget that for a jump table like this, you have to remember
   that it works in 256 byte pages, not the 2k code page boundaries.

I was a bit dissappointed to notice that this is still true on the PIC18
series parts :-(  In fact, now that I've actually been RTFM, the PIC18s
still seem to have quite a lot of the old warts...

BillW

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

2003\06\16@171657 by Herbert Graf

flavicon
face
> do not forget that for a jump table like this, you have to remember
>     that it works in 256 byte pages, not the 2k code page boundaries.
>
> I was a bit dissappointed to notice that this is still true on the PIC18
> series parts :-(  In fact, now that I've actually been RTFM, the PIC18s
> still seem to have quite a lot of the old warts...

       I don't think it's a matter of being "like" the PIC16 parts, I think it has
more to do with understanding that you are working with an 8bit processor.
TTYL

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

2003\06\16@185320 by Igor Pokorny

flavicon
face
Right, but there isn't any problem to write some macro and to forget about
256 byte pages at all.
Igor

{Original Message removed}

2003\06\16@205824 by Herbert Graf

flavicon
face
> Right, but there isn't any problem to write some macro and to forget about
> 256 byte pages at all.
> Igor

       True, but that's only because Microchip "expanded" things so you don't
normally have to worry about it. The simple fact is PCL is an 8bit register,
because the PIC is an 8bit architecture, to go past the 256 boundary you
need to worry about PCH, this will be the case with almost any 8 bit
processor, assuming the processor is as free as with the PIC in letting you
write to the PC. TTYL

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

2003\06\16@235943 by William Chops Westfield

face picon face
   The simple fact is PCL is an 8bit register, because the PIC is an 8bit
   architecture, to go past the 256 boundary you need to worry about PCH

Bah.  All it would have taken was the ability to propagate the carry bit
into PCH, and the logic is mostly there already, since the PC as a whole
increments from 0xFF to 0x100 just fine.

BillW

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

2003\06\17@005045 by David VanHorn

flavicon
face
>
>        I don't think it's a matter of being "like" the PIC16 parts, I think it has more to do with understanding that you are working with an 8bit processor.
>TTYL

8 bit AVRs don't have page registers, or any problems with tables that span pages in ram.

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

2003\06\17@100539 by Herbert Graf

flavicon
face
>     The simple fact is PCL is an 8bit register, because the PIC is an 8bit
>     architecture, to go past the 256 boundary you need to worry about PCH
>
> Bah.  All it would have taken was the ability to propagate the carry bit
> into PCH, and the logic is mostly there already, since the PC as a whole
> increments from 0xFF to 0x100 just fine.

       I think it's more complicated then you think, you don't have a 16bit ALU in
a PIC, you only have an 8bit. Remember, the PCL is "real time, however the
PCH is not, it is only used when PCL is purposely modified, therefore I
think there is a large amount of circuitry "missing", circuitry that would
make doing what you say much easier. I'm sure Microchip has a good reason
for not doing it, personally I don't see why it's so hard to do it yourself.
TTYL

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

2003\06\17@100754 by Herbert Graf

flavicon
face
> >        I don't think it's a matter of being "like" the PIC16
> parts, I think it has more to do with understanding that you are
> working with an 8bit processor.
> >TTYL
>
> 8 bit AVRs don't have page registers, or any problems with tables
> that span pages in ram.

       Correct me if I'm wrong cut I believe the AVR is designed around a
completely different architecture, one that mixes 8bit and larger size
operands more easily?

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

2003\06\17@103510 by Olin Lathrop

face picon face
>         I think it's more complicated then you think, you don't have a
> 16bit ALU in a PIC, you only have an 8bit. Remember, the PCL is "real
> time, however the
> PCH is not, it is only used when PCL is purposely modified, therefore I
> think there is a large amount of circuitry "missing", circuitry that
> would
> make doing what you say much easier. I'm sure Microchip has a good
> reason
> for not doing it, personally I don't see why it's so hard to do it
> yourself.

I agree.  I think the problem is that when you do a ADDWF PCL,F the adder
is part of the general purpose ALU related to W.  It is adding W to a file
register, then writing the result back, but has no special knowledge that
the file register is PCL.  It therefore has no idea that you would like
the carry added to PCH.

To implement this for real would probably require a special instruction to
add W to the program counter, with the associated special case circuitry.
I'd rather have a cheaper PIC.

In my experience, this hasn't been a problem.  Most of the time the few
extra instructions to deal with PCLATH isn't a big deal.  That's how I
write all such code unless cycles are tight, because it's so much more
maintainable.

I did have a case recently where I needed a table in a 25 instruction
loop, and there were no free cycles to give away.  In that case the table
only needed 16 entries and could easily be arranged to be within 256 - 16
locations from the start of the routine (the whole routine was well under
256 instructions long).  It was no problem to fix that one routine at a
256 word boundary and let the linker fill in around 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

2003\06\17@111259 by David VanHorn

flavicon
face
At 10:07 AM 6/17/2003 -0400, Herbert Graf wrote:

>> >        I don't think it's a matter of being "like" the PIC16
>> parts, I think it has more to do with understanding that you are
>> working with an 8bit processor.
>> >TTYL
>>
>> 8 bit AVRs don't have page registers, or any problems with tables
>> that span pages in ram.
>
>        Correct me if I'm wrong cut I believe the AVR is designed around a
>completely different architecture, one that mixes 8bit and larger size
>operands more easily?

The implication seemed to be that this was a limitation of 8 bit processors generically.  The PIC is the only one I've worked with that has this limitation.  Pic, AVR, Z8, 8051..

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

2003\06\17@112736 by hael Rigby-Jones

picon face
{Quote hidden}

This "limitation" is simply hidden within the architecture of other
processors using a multi-word instruction for a long call or jump.  The (14
bit) PIC is designed around a single word instruction.

Mike



=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================
Any questions about Bookham's E-Mail service should be directed to EraseMEpostmasterspam_OUTspamTakeThisOuTbookham.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

2003\06\17@114051 by David VanHorn

flavicon
face
>
>> The implication seemed to be that this was a limitation of 8 bit
>> processors generically.  The PIC is the only one I've worked with that has
>> this limitation.  Pic, AVR, Z8, 8051..
>>
>This "limitation" is simply hidden within the architecture of other
>processors using a multi-word instruction for a long call or jump.  The (14
>bit) PIC is designed around a single word instruction.

So is the AVR.

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

2003\06\17@121754 by Daniel Serpell

flavicon
face
On Tue, Jun 17, 2003 at 10:10:14AM -0500, David VanHorn wrote:
> At 10:07 AM 6/17/2003 -0400, Herbert Graf wrote:
> >
> >        Correct me if I'm wrong cut I believe the AVR is designed around a
> >completely different architecture, one that mixes 8bit and larger size
> >operands more easily?
>
> The implication seemed to be that this was a limitation of 8 bit
> processors generically.  The PIC is the only one I've worked with
> that has this limitation.  Pic, AVR, Z8, 8051..

The 6502 has the same limitation (8bit PCL), and also has indirect
jump instructions that can't cross page boundaries. I also think
that any 8bit micro that has access to the PC has this 8bit restriction
(how you add a value to the PC to do a call table in Z8, 8051, etc.?)

The real pain in PIC's are that absolute jumps and calls are restricted
to (big) pages. It's a restriction that comes from the word size of
programm memory.

   Daniel.

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

2003\06\17@133131 by Randy Ott

flavicon
face
----- Original Message -----
From: "Michael Rigby-Jones" <Michael.Rigby-Jonesspamspam_OUTBOOKHAM.COM>
To: <@spam@PICLISTKILLspamspamMITVMA.MIT.EDU>
Sent: Tuesday, June 17, 2003 10:27 AM
Subject: Re: [PIC]: Function pointers in assembly?


> > {Original Message removed}

2003\06\17@151223 by William Chops Westfield

face picon face
   > I think it's more complicated then you think, you don't have a 16bit
   > ALU in a PIC, you only have an 8bit. Remember, the PCL is "real time,
   > however the PCH is not, it is only used when PCL is purposely
   > modified, therefore I think there is a large amount of circuitry
   > "missing", circuitry that would make doing what you say much easier.

   I agree.  I think the problem is that when you do a ADDWF PCL,F the
   adder is part of the general purpose ALU related to W.  It is adding W
   to a file register, then writing the result back, but has no special
   knowledge that the file register is PCL.  It therefore has no idea that
   you would like the carry added to PCH.

Well, presumably there's a clock that increments PCH, right?  Normally
it's driven only by carry out of PCL.  To handle adds to PCH, you could
OR this with something like:

       ALU-carry-out                   (already exists)
  and  Store-to-PCL                    (already exists)
  and  instruction-is-add              (probably already exists.)

The last part is so that random other instructions on PCL don't
increment PCH based on a 'stale' value in the carry bit.  Perhaps the
"store flags" signal would work.  So I count about 3 additional gates.


   > I'm sure Microchip has a good reason for not doing it

backward compatibility.  :-(  I'll bet there are programs that count on
this NOT happening.  Also, you probably have to UNDO the logic that
moves PCLATH to PCH, and THAT might be tougher.  Lots tougher, actually.


   > personally I don't see why it's so hard to do it yourself.

Oh.  Well, there is that.  I think I'm somewhat pissed off by early
experiences with the 12bit cores where there is no PCLATH, and all sorts
of nasty restriction suddenly appear in your jump table code...

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

2003\06\17@154330 by Igor Pokorny

flavicon
face
I wrote something about 6502 microprocessor and its ability to have
addressed stack, a couple of addressing modes etc. here a couple months ago.
An answer from some guy probably from Microchip sounded they produce
microcontrollers, not microprocessors and their goal is to be cheapest. I
must agree they do this well.
Never the less, I personally use C, so the headache about paging has had
someone else :-)
Igor

{Original Message removed}

2003\06\17@162414 by Igor Pokorny

flavicon
face
PCL is only projection of a real P counter into some place in memory.
No way how to propagate a carry bit by a plain ADD instruction.
Igor

{Original Message removed}

2003\06\17@164248 by Igor Pokorny

flavicon
face
You are not right about 6502. Because of an addressable stack you could do
16 bit adding to PC easily. Many problems could have been solved very easy
if  PIC16 had a stack pointer as a register and the whole stack projected
somewhere to not used memory.

Igor

{Original Message removed}

2003\06\17@181805 by Daniel Serpell

flavicon
face
On Tue, Jun 17, 2003 at 10:44:25PM +0200, Igor Pokorny wrote:
> You are not right about 6502. Because of an addressable stack you could do
> 16 bit adding to PC easily. Many problems could have been solved very easy
> if  PIC16 had a stack pointer as a register and the whole stack projected
> somewhere to not used memory.
>

But you have to do the address calculation in the stack memory, and
then execute a rts. It's the same as do the calculation in a pair of
registers and then copy to pch/pcl.
The fact that people likes to do "addwf PCL,F" is the problem, using
only moves to the PCL you can avoid all "page boundary problems".

   Daniel.

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

2003\06\17@194146 by Charles Craft

picon face
I attended the current Microchip seminar last week and they refer to all existing chips as 8 bit micros.

There are chips with 12 and 14 bit memory sizes but somewhere inside is a 8 bit bottleneck.




   > personally I don't see why it's so hard to do it yourself.

Oh.  Well, there is that.  I think I'm somewhat pissed off by early
experiences with the 12bit cores where there is no PCLATH, and all sorts
of nasty restriction suddenly appear in your jump table code...

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
>

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

2003\06\17@201250 by William Chops Westfield

face picon face
   > I think I'm somewhat pissed off by early experiences with the 12bit
   > cores where there is no PCLATH, and all sorts of nasty restriction
   > suddenly appear in your jump table code...

   I attended the current Microchip seminar last week and they refer to all
   existing chips as 8 bit micros.  There are chips with 12 and 14 bit
   memory sizes but somewhere inside is a 8 bit bottleneck.

That's not what I was talking about, but I wasn't clear.  The PICs with a
12 bit instruction word have a 9,10, or 11 bit PC (512-2048 words.)  The
GOTO instruction has a 9 bit destination, so the part has nice 512word
program space pages, and you have to do "banking stuff" to get to the other
pages.  But there is no PCLATH.  Instead, there are two bits in the status
register that are copied into PC9 and PC10 (the "page") in a PCLATH-like
manner.  PCL, of course, is 8bits worth in PC0:7) There is no method of
setting PC8 other than the goto instruction, or normal PC incrementing.
Other instructions that operate on the PC (including CALL and ADDWF) set
PC8 to 0. This means things like:

1) All jump tables using ADDWF PCL,f  have to be in the first 256 words
  of a page.
2) All subroutines that are called need to be in the first 256 words of
  a page.
3) 1+2 means it is "interesting" to write code that has a full 256 value
  jump table.  If you want it to be a subroutine, you sorta have to put
  your subroutine code in the first half of one page, and your table in
  the first half of another page.  If your pic happens to have more than
  one page of code memory...

It's enough to give one an inappropriately bad taste of PIC banking
schemes, even though microchip HAS improved the situation in each
successive generation...

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

2003\06\17@203606 by Herbert Graf

flavicon
face
> I attended the current Microchip seminar last week and they refer
> to all existing chips as 8 bit micros.
>
> There are chips with 12 and 14 bit memory sizes but somewhere
> inside is a 8 bit bottleneck.

       Well, over the years, there has been a large debate about how to classify
processors. Some think the address bus is important, some think the
instruction size is important. The most common "definition" though, and
correct me if I'm wrong, is the ALU, if it can chug 16bit numbers then the
processor is USUALLY considered 16bit. TTYL

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

2003\06\18@075526 by Olin Lathrop

face picon face
> I attended the current Microchip seminar last week and they refer to
> all existing chips as 8 bit micros.
>
> There are chips with 12 and 14 bit memory sizes but somewhere inside is
> a 8 bit bottleneck.

The "8 bit" in this context refers to the data path width.


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

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

2003\06\19@124256 by Igor Pokorny

flavicon
face
You are right, but there isn't any PCH using PIC series 16 .
Igor



-----Original Message-----
From: pic microcontroller discussion list [KILLspamPICLISTKILLspamspamMITVMA.MIT.EDU]On
Behalf Of Daniel Serpell
Sent: Wednesday, June 18, 2003 12:18 AM
To: RemoveMEPICLISTTakeThisOuTspamMITVMA.MIT.EDU
Subject: Re: [PIC]: Function pointers in assembly?


On Tue, Jun 17, 2003 at 10:44:25PM +0200, Igor Pokorny wrote:
> You are not right about 6502. Because of an addressable stack you could do
> 16 bit adding to PC easily. Many problems could have been solved very easy
> if  PIC16 had a stack pointer as a register and the whole stack projected
> somewhere to not used memory.
>

But you have to do the address calculation in the stack memory, and
then execute a rts. It's the same as do the calculation in a pair of
registers and then copy to pch/pcl.
The fact that people likes to do "addwf PCL,F" is the problem, using
only moves to the PCL you can avoid all "page boundary problems".

   Daniel.

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

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

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