Searching \ for '[PIC] Paging and Banking. Any benefits?' 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/memory.htm?key=bank
Search entire site for: 'Paging and Banking. Any benefits?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Paging and Banking. Any benefits?'
2005\06\23@205451 by Mario Mendes Jr.

flavicon
face
OK, maybe not necessarily limited to pics, but....

So, I remember when I started reading about cpus/mcus a long time agon
about why banking and paging came about.

Being a beginer, I do find banking and paging to be a nusiance,
nevermind making code a little more complex to deal with.

But rather than trash the idea, what I wanted to know from the more
experienced guys in the list is: are there any actual benefits to
banking and paging?  Is there ever a situation where banking and paging
actuall makes things easier/better?

Thanks.


-Mario


2005\06\23@215006 by Matthew Miller

flavicon
face
Hi Mario,

On Thu, Jun 23, 2005 at 08:54:48PM -0400, Mario Mendes Jr. wrote:
> OK, maybe not necessarily limited to pics, but....
>
> So, I remember when I started reading about cpus/mcus a long time agon
> about why banking and paging came about.
>
> Being a beginer, I do find banking and paging to be a nusiance,
> nevermind making code a little more complex to deal with.
>
> But rather than trash the idea, what I wanted to know from the more
> experienced guys in the list is: are there any actual benefits to
> banking and paging?  Is there ever a situation where banking and paging
> actuall makes things easier/better?

Yes, it is tempting to bash banking and paging. This is my (slightly
educated) guess about why it exists: banking and paging make the hardware
more simple. Someone else may have some evidence for or against this idea,
but for what little bit of digital design I remember this is my stand. ;)

Take care.

Matthew.

--
Your chair has moved. Windows will now reboot to update your system
settings. Click [OK] to accept.

2005\06\23@223947 by Spehro Pefhany

picon face
At 08:54 PM 6/23/2005 -0400, you wrote:
>OK, maybe not necessarily limited to pics, but....
>
>So, I remember when I started reading about cpus/mcus a long time agon
>about why banking and paging came about.
>
>Being a beginer, I do find banking and paging to be a nusiance,
>nevermind making code a little more complex to deal with.
>
>But rather than trash the idea, what I wanted to know from the more
>experienced guys in the list is: are there any actual benefits to
>banking and paging?  Is there ever a situation where banking and paging
>actuall makes things easier/better?
>
>Thanks.

For one thing, they increase the code density. If you had instructions that
could  address all of the RAM, for example, they might have to have 12 bits
just for one address (4K of RAM). A direct move would need 24 bits for the
two addresses, plus the opcode.

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
spam_OUTspeffTakeThisOuTspaminterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
->> Inexpensive test equipment & parts http://search.ebay.com/_W0QQsassZspeff


2005\06\24@022546 by Wouter van Ooijen

face picon face
> This is my (slightly
> educated) guess about why it exists: banking and paging make
> the hardware
> more simple. Someone else may have some evidence for or
> against this idea,
> but for what little bit of digital design I remember this is
> my stand. ;)

Main reason is that the (data or code) address field must fit in an
instruction, an instruction has a limited size, and this size should not
be choosen too large because the Flash is a large part of the cost
(size) of the chip. Another: some PICs have an address range that is
large than the register size (8 bit).

Note that in a sense even an ARM has some sort of paging/banking:
neither 32-bit constants, nor full 32-bit data or code (same thing on an
ARM) addresses fit into a (32 bit!) instruction. So there are tricks and
workarounds to get a 32-bit value in a register, and to address anything
in the 32-bit address space (but not paging/banking as we know it on the
PICs).

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\06\24@050324 by Mike Harrison

flavicon
face
On Thu, 23 Jun 2005 20:54:48 -0400, you wrote:

>OK, maybe not necessarily limited to pics, but....
>
>So, I remember when I started reading about cpus/mcus a long time agon
>about why banking and paging came about.
>
>Being a beginer, I do find banking and paging to be a nusiance,
>nevermind making code a little more complex to deal with.
>
>But rather than trash the idea, what I wanted to know from the more
>experienced guys in the list is: are there any actual benefits to
>banking and paging?  Is there ever a situation where banking and paging
>actuall makes things easier/better?
>
>Thanks.
>
>
>-Mario

Most of the benefits are in instruction size, however there is an occasional side-benefit - A while
ago  did a keypad controller on a 16C57, which had to control 4 independent keypads, keeping lots of
status & mode info for each keypad. The RAM banking provided a very neat and elegant solution, using
one bank per keypad. Of course if it was 5 keypads it would have bene a different matter..!

RAM banking can occasionally be useful on the more recent parts, allowing a few tricks with
bit-set/clear instructions to do pointer wrapping.

However I think mostly it is a pain, but a necessary evil to get the parts cost sufficiently low.

In this market, price, availability and peripheral mix are the only significant parameters-
architectural elegance or otherwise comes way down the list.  

2005\06\24@074435 by olin piclist

face picon face
Mario Mendes Jr. wrote:
> are there any actual benefits to banking and paging?

Yes.  It requires less address bits directly in the instruction.  This
allows for less silicon area to implement the processor, which makes it
smaller, cheaper, and probably also lower power.  Everything is a tradeoff.

This kind of address segmentation has been around for a long time, and is
common in "small" machines where you want the basic architecture to be light
weight, but want the possibility of extending the address space.
Compatibility with older smaller versions can be an issue too.

>From the software point of view, address segmentation is generally
undesirable, but something you live with in return for smaller, cheaper,
faster, lower power, compatible, etc.


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

2005\06\24@141126 by Peter

picon face


On Thu, 23 Jun 2005, Mario Mendes Jr. wrote:

{Quote hidden}

In theory banked and paged address spaces make for more compact program
code since the addresses used for any indirect access will be shorter.
But that is history (once upon a time code storage was extremely
expensive and nobody had optimising compilers). On most 8 bit micros
there were addressing modes for 'short' and 'long' distance of indirect
objects. The 8080, Z80, MCS51 and most Motorola 8 bit CPUs all have this
feature. When storage became cheap the banking (and shadowing which is a
form of banking) became obsolete and they are still used only for
acceleration (f.ex. the BIOS in a pc is copied to RAM and then mapped
out during boot - code runs up to 100 times faster from ram than from
flash BIOS), and in 'legacy' architectures (like mask programmed 4 bit
cpus).

I do not know why Microchip chose to go with banking and paging instead
of making wider instruction words (to make room for the extra address
bits). It may have saved some silicon real estate (in the form of less
code storage bits required for the same task). Others went with wide
words all the way. The ARM is a good example, its words encode a lot of
information: example (from 'Introduction to the LPC2000'):

       if(Z==1) R1 = R2+(R3*4)

encodes as:

       EQADDS R1,R2,R3,LSL #2

which is a single word on 32 bits. On a pic one would do:

       btfss        STATUS,Z
       goto        noz

       rlf        R3,w        ; w  = r3 * 2
       movwf        R1        ; r1 = r3 * 2
       addwf        R2,w    ; w  = r3 * 2 + r2
       addwf        R1,f        ; r1 = 2 * r3 + 2 * r2 + r2 = r2 + r3 * 4
noz:

which takes 6 x 12 or 6 x 14 bits and only operates on 8 bit numbers in
a 32-register file. So the pic consumes at least 72 bits of code to do
1/4 (8 bit registers instead of 32) of the equivalent single 32 bit ARM
instruction word, and runs in 6 T cycles (the ARM takes 1 T cycle to do
the job).

On the other hand, a simple bit banging code can consume less space on a
pic than on an ARM. E.g. toggling an output can be done as:

       movlw        0xFF,w
       mofvwf        RB
again:
       xorwf        RB,f
       goto        again

the loop uses 2 x 12 bit words and runs in 3T per loop. An equivalent
ARM loop will use 2 x 32 bit words and run in 2 or 3T (depending on MAM
settings). so the PIC saves 60% code space because it uses narrower code
words (which is possible due to banking).

Peter

2005\06\24@142210 by Peter

picon face


On Fri, 24 Jun 2005, Wouter van Ooijen wrote:

> Note that in a sense even an ARM has some sort of paging/banking:
> neither 32-bit constants, nor full 32-bit data or code (same thing on an
> ARM) addresses fit into a (32 bit!) instruction. So there are tricks and
> workarounds to get a 32-bit value in a register, and to address anything
> in the 32-bit address space (but not paging/banking as we know it on the
> PICs).

The ARM branches directly and conditionally on +/-32MB using a single
32bit word and indirectly on 4GB (by loading a register or immediate
value into the PC which is also a register).

Peter

2005\06\24@143639 by Mike Harrison

flavicon
face
On Fri, 24 Jun 2005 21:11:22 +0300 (IDT), you wrote:

{Quote hidden}

Not so. The bulk of an embedded micro's die area is memory. Cost is very dependent on die area (i.e.
how many chips you can get on a wafer). Cost is usually the most important parameter for low to
mid-range micros.  Therefore code size is extremely important, which is why Microchip do so many ROM
size variants.

These issues change as you move to higher end parts, which is what the PIC18 series is for.
 


2005\06\24@153254 by Wouter van Ooijen

face picon face
> I do not know why Microchip chose to go with banking and
> paging instead
> of making wider instruction words (to make room for the extra address
> bits).

check a die photo

{Quote hidden}

Note that for the ARM example the operands and result are in registers,
of which there are only 16. That's why an ARM instruction can encode 3
registers (sometimes 4) in 32 bits. More instructions are needed to get
the values into and the result out of the registers. Note also that an
ARM can not load an arbitrary value in a register using only a single
instruction (it can using a single instruction + a nearby data location
by using PC-relative adressing).

> which takes 6 x 12 or 6 x 14 bits and only operates on 8 bit
> numbers in
> a 32-register file.

128 registers in a 14-bit core bank

{Quote hidden}

I dont see how an ARM can do that in 2 instructions?

> so the PIC saves 60% code space because it uses
> narrower code
> words (which is possible due to banking).

I would say a PIC is more closely coupled with its I/O, and has a (at
least partially) memory-to-memory architecture. An ARM is a register
architecture.

PS don't take me for a PIC fanatic / ARM basher.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\06\24@153342 by William Chops Westfield

face picon face

>> are there any actual benefits to banking and paging?
>>
Easier hardware, as everyone has said...

Also, something like the much-hated 8086 segmentation gives you a
large amount of "automatic" relocatability of both your data and code,
which can be handy (code relocatability is usually pretty useless on a
rom microcontroller, and it's nice if your page size is large enough
that most individual programs don't have to deal with it (like in the
x86 till about a year after it came out :-))

BillW

2005\06\24@154038 by Wouter van Ooijen

face picon face
> > Note that in a sense even an ARM has some sort of paging/banking:
> > neither 32-bit constants, nor full 32-bit data or code
> (same thing on an
> > ARM) addresses fit into a (32 bit!) instruction. So there
> are tricks and
> > workarounds to get a 32-bit value in a register, and to
> address anything
> > in the 32-bit address space (but not paging/banking as we
> know it on the
> > PICs).
>
> The ARM branches directly and conditionally on +/-32MB using a single
> 32bit word

Indeed, in a (proportionally smart but absolutely large) part of its
address space.

> and indirectly on 4GB (by loading a register or immediate
> value into the PC which is also a register).

Indeed, using one instruction + one nearby data word. So using 64 bits.
Or by having the target value in a register, but that would have taken
64 bits to get that value there.

As I said, a way to cope with the limitations of its instruction set,
although very different from the paging/banking of a PIC.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\06\24@162456 by William Chops Westfield

face picon face

On Jun 24, 2005, at 11:11 AM, Peter wrote:

> But that is history (once upon a time code storage was extremely
> expensive and nobody had optimising compilers). On most 8 bit micros
>  there were addressing modes for 'short' and 'long' distance of
> indirect objects. ... When storage became cheap the banking (and
> shadowing which is a form of banking) became obsolete and they are
> still used only for acceleration and in 'legacy' architectures...
>
> I do not know why Microchip chose to go with banking and paging
> instead of making wider instruction words...

huh?  The PIC *is* a legacy architecture.  You see in the PIC18 and
dsPIC chips microchip's attempts to modernize the architecture without
losing "mindshare" or the value of accumulated expertise in the existing
PIC architectures.

We could debate the virtues of retaining an "obsolete" architecture
vs chasing the latest fads separately, but I think microchip's apparent
decision to focus on peripherals, pervasiveness, packaging, and
usability
was *a* correct one...

BillW

2005\06\25@000737 by William Chops Westfield

face picon face
On Jun 24, 2005, at 12:30 PM, Wouter van Ooijen wrote:

> I would say a PIC is more closely coupled with its I/O, and has a (at
> least partially) memory-to-memory architecture.

It's hard to tell whether the PIC "memory" is closer to registers or
memory from a more conventional architecture...

A modern pentium is quite divorced from IO.  I found out recently (the
hard way :-) that the IN and OUT x86 instructions effectively take
like a microsecond to execute (you know; several THOUSAND CPU cycles,
on a processor where most instructions take  ONE.)  I guess that's
predictable, since it has to flush all the pipelines, can't be
reordered,
and has to actually manipulate external signals, but it was still a
bit of a shock...

BillW

2005\06\25@034341 by Wouter van Ooijen

face picon face
> > I would say a PIC is more closely coupled with its I/O, and
> has a (at
> > least partially) memory-to-memory architecture.
>
> It's hard to tell whether the PIC "memory" is closer to registers or
> memory from a more conventional architecture...

There is nothing else that could be called memory, so I would rather
call it memory. But there are no absolute truths in this area. Remember
the 1802?

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\06\25@080704 by Gerhard Fiedler

picon face
Peter wrote:

> On Fri, 24 Jun 2005, Wouter van Ooijen wrote:
>
>> Note that in a sense even an ARM has some sort of paging/banking:
>> ...
>
> The ARM branches directly and conditionally on +/-32MB using a single
> 32bit word and indirectly on 4GB (by loading a register or immediate
> value into the PC which is also a register).

By having two different mechanisms for different branch distances, this may
not be "classic" paging, but it amounts to the same problem. Whether one or
two or three instructions are involved is not the issue, the issue is that
how branching is done depends on the distance and/or the absolute target
address -- which is something arbitrary, as far as the branching
instruction itself is concerned.

And it is still limited. There /will/ be a time where a limitation to 4GB
will sound ridiculous... :)

Gerhard

2005\06\25@084549 by olin piclist

face picon face
William Chops Westfield wrote:
> A modern pentium is quite divorced from IO.  I found out recently (the
> hard way :-) that the IN and OUT x86 instructions effectively take
> like a microsecond to execute (you know; several THOUSAND CPU cycles,
> on a processor where most instructions take  ONE.)  I guess that's
> predictable, since it has to flush all the pipelines, can't be
> reordered,
> and has to actually manipulate external signals, but it was still a
> bit of a shock...

That's why most real I/O on PCs is done via DMA, not (shudder) programmed
I/O.


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

2005\06\25@135656 by Peter

picon face


On Fri, 24 Jun 2005, William Chops Westfield wrote:

> huh?  The PIC *is* a legacy architecture.  You see in the PIC18 and
> dsPIC chips microchip's attempts to modernize the architecture without
> losing "mindshare" or the value of accumulated expertise in the existing
> PIC architectures.
>
> We could debate the virtues of retaining an "obsolete" architecture
> vs chasing the latest fads separately, but I think microchip's apparent
> decision to focus on peripherals, pervasiveness, packaging, and usability
> was *a* correct one...

I think that wou will find that a Gedankenexperiment that assumes an
assembly language level compatible extension of the basic PIC (16C54
vintage) to say 20 bit wide words and a corresponding growth in address
space (4096 registers and who knows how much code based on 12 bit near
addresses + 20 bits far addresses = 32bit) would be interesting. To keep
things in proportion, a growth by 4 bits would have bought 512 directly
accessible ram registers and 2k calls/jumps, without paging. I think
that this is entirely a cost factor. Beyond a certain size of ram and
rom every doubling of size costs twice the area, no matter how it is
done.

Peter

2005\06\25@140954 by Peter

picon face


On Sat, 25 Jun 2005, Gerhard Fiedler wrote:

>> value into the PC which is also a register).
>
> By having two different mechanisms for different branch distances, this may
> not be "classic" paging, but it amounts to the same problem. Whether one or
> two or three instructions are involved is not the issue, the issue is that
> how branching is done depends on the distance and/or the absolute target
> address -- which is something arbitrary, as far as the branching
> instruction itself is concerned.

Correct, but I prefer that the page size be about 300 times the size of
the largest program I intend to run on that machine, and hope that by
the time I'll outgrow that there will be something better to work with.

Peter

2005\06\25@141430 by Peter

picon face

On Fri, 24 Jun 2005, Wouter van Ooijen wrote:

>> the loop uses 2 x 12 bit words and runs in 3T per loop. An equivalent
>> ARM loop will use 2 x 32 bit words and run in 2 or 3T
>> (depending on MAM
>> settings).
>
> I dont see how an ARM can do that in 2 instructions?

ok, 3+ ;-) Anyway being able to jump +/-32MB on an embedded cpu that
comes with (currently) up to 512k or flash looks good (as in, page ?
what page ?!)

Peter

2005\06\25@143935 by William Chops Westfield

face picon face

On Jun 25, 2005, at 5:45 AM, Olin Lathrop wrote:

> That's why most real I/O on PCs is done via DMA,
>  not (shudder) programmed I/O.

Yeah, what bit me was manipulating the interrupt controller.  Not
'real' IO, really, but not something you want to do thousands of
times per second in course of enabling/disable certain interrupts
around pieces of critical code, either :-(

BillW

2005\06\25@165754 by Byron A Jeff

face picon face
On Thu, Jun 23, 2005 at 08:54:48PM -0400, Mario Mendes Jr. wrote:
> OK, maybe not necessarily limited to pics, but....
>
> So, I remember when I started reading about cpus/mcus a long time agon
> about why banking and paging came about.

Because it allows access to a larger memory space when instruction bits
are limited.

> Being a beginer, I do find banking and paging to be a nusiance,
> nevermind making code a little more complex to deal with.

It's a nuisance. A flat address space is always easier from a programmer's
standpoint.

> But rather than trash the idea, what I wanted to know from the more
> experienced guys in the list is: are there any actual benefits to
> banking and paging?

Not from a programmer standpoint.

>  Is there ever a situation where banking and paging
> actuall makes things easier/better?

Only one: it makes the resulting chips cheaper.

BAJ

2005\06\26@100046 by Gerhard Fiedler

picon face
Peter wrote:

> Correct, but I prefer that the page size be about 300 times the size of
> the largest program I intend to run on that machine, and hope that by
> the time I'll outgrow that there will be something better to work with.

Agree completely. Which concludes that the problem with paging in PICs is
not that Microchip created a core that uses paging, but that people work
with it :)  

(Or that people work without a compiler or assembler scheme that takes care
of that automatically. It's been ages that I have been bothered with paging
in PICs -- the last time when I started to work with them and tried to
understand the architecture. Ever since, while I know that it exists and
know how to identify it in code, I simply don't bother.)

Gerhard

2005\06\26@114247 by Wouter van Ooijen

face picon face
> > Correct, but I prefer that the page size be about 300 times
> the size of
> > the largest program I intend to run on that machine, and
> hope that by
> > the time I'll outgrow that there will be something better
> to work with.
>
> Agree completely. Which concludes that the problem with
> paging in PICs is
> not that Microchip created a core that uses paging, but that
> people work
> with it :)  

Exactly. When the PIC was first designed the 300 factor was probably a
fact (OK, maybe it was just a factor 2). But right now alternatives do
exist, so why are you using PICs and/or are you on the PIClist?

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\06\26@175110 by Peter

picon face

On Sun, 26 Jun 2005, Wouter van Ooijen wrote:

>>> Correct, but I prefer that the page size be about 300 times the size
>>> of the largest program I intend to run on that machine, and hope
>>> that by the time I'll outgrow that there will be something better to
>>> work with.
>>
>> Agree completely. Which concludes that the problem with paging in
>> PICs is not that Microchip created a core that uses paging, but that
>> people work with it :)
>
> Exactly. When the PIC was first designed the 300 factor was probably a
> fact (OK, maybe it was just a factor 2). But right now alternatives do
> exist, so why are you using PICs and/or are you on the PIClist?

*I* am using *small* pics, the ones that need only minor paging and
banking. Also the ones that were reportedly successfull on the market
afair (and thus low cost) ? Must be a coincidence. But I am just a guy.

Peter

2005\06\27@042402 by Alan B. Pearce

face picon face
>ok, 3+ ;-) Anyway being able to jump +/-32MB on an embedded
>cpu that comes with (currently) up to 512k or flash looks
>good (as in, page ? what page ?!)

What is the part no for the SOT23 version? I could do with this to replace a
10F in an application.

2005\06\27@125722 by Gerhard Fiedler

picon face
Wouter van Ooijen wrote:

> Exactly. When the PIC was first designed the 300 factor was probably a
> fact (OK, maybe it was just a factor 2). But right now alternatives do
> exist, so why are you using PICs

I'm not sure that was targeted to me... but I answer it anyway :)

Why I'm using them has not really a simple answer. One is that I know them,
that they provide for me a reasonable cost/benefit relation (where I use
them), another may be that they are within a customer's preference for a
number of reasons -- and that's not all yet.

As I said, I never had a problem with paging. I let the compiler take care
of it. For me, that's not a reason not to use a PIC.

> and/or are you on the PIClist?

Because of the interesting discussions about contentious subjects :)

Gerhard

2005\06\27@130442 by Sergio Masci

flavicon
face
Mario Mendes Jr. wrote:

> OK, maybe not necessarily limited to pics, but....
>
> So, I remember when I started reading about cpus/mcus a long time agon
> about why banking and paging came about.
>
> Being a beginer, I do find banking and paging to be a nusiance,
> nevermind making code a little more complex to deal with.
>
> But rather than trash the idea, what I wanted to know from the more
> experienced guys in the list is: are there any actual benefits to
> banking and paging?  Is there ever a situation where banking and paging
> actuall makes things easier/better?

Better yes, easier - depends on the specific CPU.

Think about a CPU that has instructions wide enough to hold an address that can
access all of its memory. If you have a large memory space these instructions
will tend to contain a high degree of redundency mainly because of the way
programs are written. That is: sections of code tend to use variables that are
located close to each other in memory or else calculate addresses in registers
and use these to access memory (as is the case when processing arrays). Also
these sections of code tend to make up small self contained groups of
instructions (loops, subroutines etc).

Paging and banking allows you to take advantage of this property.

Consider a CPU such as the 6502 which has instructions which are 1, 2 and 3
bytes long. To load a value from anywhere in memory into the accumulator using
an absolute address requires a 3 byte instruction (2 bytes just for the
address). These 3  byte instructions execute slower than the 1 and 2 byte
instructions. If the 6502 had paging like the PIC then you could reduce some of
the 3 byte instructions to 2 byte instructions and improve their execution
speed. In fact the 6502 has a page zero addessing mode (you cannot change the
page for instructions using this mode, it is always page 0). The 6809 goes one
better than the 6502 in that it has a Direct Page addressing mode. It is like
the page 0 addressing mode of the 6502 except that the programmer can change the
page by loading the DP register.

To put this another way, if you have a tight loop consisting of a few
instructions that each use a 16 bit address you could greatly improve
performance by moving all the variables into the same page, then setting the
page register OUTSIDE the loop to that page and then using short 8 bit page
relative addresses in your instructions.

The alternative to paging is (1) to have very wide instructions that can
accomodate the whole address of an any operand (fast but memory inefficient) and
(2) to have variable length instructions that have the address packed into
subsequent words of the instruction (slow but memory efficient).

Within this thread I have seen discussions about increasing the word length from
14 bits to 16 bits to eliminate paging. The fact is that doing so would require
an increase in program memory of about 14% whereas an optimising compiler such
as XCSB introduces an overhead of about 4%. That is, the number of page select
instructions added for a typical program that uses all available RAM is about 4%
of the total number of instructions generated for the entire executable. For
people who really must use an assembler, the XCASM assembler provides automated
page and bank management. It includes an execution profiler which allows the
assembler to optimise how page and bank select instructions are inserted. XCASM
is the assembler used by the XCSB compiler.

Many people bitch about the paging and banking on the PIC. The fact is that if
you can get past the initial iritation it can yield benefits.

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use





2005\06\27@153054 by jrem

picon face


--- Sergio Masci <.....smplxKILLspamspam@spam@xcprod.com> wrote:

{Quote hidden}

I know I'm going to get yelled at for typing this, and I know it's not
the right way to go, but what is wrong with just keeping an eye on page
boundries and setting up an "org 0x754" or whatever to make sure the
data fits the page boundry?  I've done this successfully, although I
can imaging that what works for one application won't work for another,
and it might not be graceful, but once it's running others can't see
what's "under the hood".  I can see a down fall is I'm not optimizing
the total memory available, i.e., there are "holes" in the memory that
don't get code, but I can buy a bigger chip if I need it, too.

Regards, John.




               
____________________________________________________
Yahoo! Sports
Rekindle the Rivalries. Sign up for Fantasy Football
http://football.fantasysports.yahoo.com

2005\06\27@163819 by olin piclist

face picon face
jrem wrote:
> what is wrong with just keeping an eye on
> page boundries and setting up an "org 0x754" or whatever to make sure
> the data fits the page boundry?

Lots of things.  First, it's not that easy to "keep and eye on" the page
boundary.  You'd have to build the project, and adjust the ORGs
interatively.  Second, even once you get it right for that build, it can't
be transferred to the next build.  You'll be doing this every time.  Third,
its probably not obvious to someone modifying code near the top that there
are issues as code ends up in different locations part way thru.  This is a
maintainence disaster.

Do it right and let the linker take care of all this for you.


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

2005\06\27@184352 by Peter

picon face

On Mon, 27 Jun 2005, Alan B. Pearce wrote:

>> ok, 3+ ;-) Anyway being able to jump +/-32MB on an embedded
>> cpu that comes with (currently) up to 512k or flash looks
>> good (as in, page ? what page ?!)
>
> What is the part no for the SOT23 version? I could do with this to replace a
> 10F in an application.

lqfp48 is the smallest I have seen so far (LPC2104). HVQFN48 is also
available. lqfp48 can be hand soldered without trouble.

Jokes apart, this is an impressive chip. One could build a PDA using
just one of these, driving a graphical lcd and doing the other things
expected from a low end PDA. It is not a PIC, it does not resemble a
PIC, and it probably never will. It fits in a different bracket imho.

Peter

2005\06\28@204832 by Mario Mendes Jr.

flavicon
face
Hi guys,

Just a quick note to thank everyone for the insightful discussion.  I
for one did not anticipate such a huge discussion, but it was
interesting to see everyone's responses.

Thanks.


-Mario


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