Searching \ for '[PIC] No native MOVLF instruction?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'No native MOVLF instruction?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] No native MOVLF instruction?'
2007\07\27@100434 by Matthew Rhys-Roberts

flavicon
face
As far as I can see, there's no built-in MOVLF (move literal to file)
instruction, at least on the 18F6680 I've been working on.

I know it's hardly a problem to load the literal into W first, then move
W into the desired file, but why would they fail to design such a useful
one-step function?

have fun
Matt

2007\07\27@101709 by Dario Greggio

face picon face
Matthew Rhys-Roberts wrote:

> I know it's hardly a problem to load the literal into W first, then move
> W into the desired file, but why would they fail to design such a useful
> one-step function?

a matter of RISC architecture... I guess :)
MOVFF (file to file) came out in 18F parts, was not there on earlier ones.

You can write a macro for MOVLF: the rationale is that such a macro will
still, probably, be faster than a MOVLF-like instruction on a 80x86 CPU...


--
Ciao, Dario

2007\07\27@115938 by Jan-Erik Soderholm

face picon face
Well, at least there is a "MOVLF h'00'" instruction... :-)
But for other values, no.

Jan-Erik.

Dario Greggio wrote:
{Quote hidden}

2007\07\27@121015 by Tamas Rudnai

face picon face
> You can write a macro for MOVLF: the rationale is that such a macro will
> still, probably, be faster than a MOVLF-like instruction on a 80x86 CPU...

It depends on... which x86 you are talking about and what is the program
flow. This was true with 80286, 80386 but 486 was far better on this manner,
especially Cypress clones. Intel Pentium has a quite reasonable pipelining
mechanism, so that in ideal case each instruction takes 1 cycle - well,
almost :-) A P4 has a nice dual pipeline and program flow perdition, and 3
level of cache. IA64 executes 3 instructions in a cycle so we should not
really compare that huge elephant to a our small mouse :-)

Tamas



On 7/27/07, Dario Greggio <spam_OUTadpm.toTakeThisOuTspaminwind.it> wrote:
{Quote hidden}

> -

2007\07\27@124230 by Mark Scoville

flavicon
face
Yup, also a MOVLF h'FF' instruction :-)

-- Mark

{Quote hidden}

> --

2007\07\27@132201 by Herbert Graf

flavicon
face
On Fri, 2007-07-27 at 14:58 +0100, Matthew Rhys-Roberts wrote:
> As far as I can see, there's no built-in MOVLF (move literal to file)
> instruction, at least on the 18F6680 I've been working on.
>
> I know it's hardly a problem to load the literal into W first, then move
> W into the desired file, but why would they fail to design such a useful
> one-step function?

That's RISC. A large part of RISC is using the W register, so most
instructions have W as either source or target. With the PIC some
instructions were added due to the "controller" nature of a PIC core
(i.e. bsf type things).

TTYL

2007\07\27@133149 by Jan-Erik Soderholm

face picon face
Hm, let's see, my MOVLF h'00', is a CLRF,
but what am I missing about the MOVLF h'FF' ?

A COMF doesn't work, if it's not h'00' before.
The same with INCF, DECF. What else ?

Jan-Erik.

Mark Scoville wrote:
{Quote hidden}

>> --

2007\07\27@134644 by Marcel Birthelmer

picon face
On 7/27/07, Jan-Erik Soderholm <.....jan-erik.soderholmKILLspamspam@spam@telia.com> wrote:
> Hm, let's see, my MOVLF h'00', is a CLRF,
> but what am I missing about the MOVLF h'FF' ?
>
> A COMF doesn't work, if it's not h'00' before.
> The same with INCF, DECF. What else ?
>
> Jan-Erik.

Isn't there a SETF in the 18f instruction set?
- Marcel

2007\07\27@134913 by Dario Greggio

face picon face
Jan-Erik Soderholm wrote:

> Hm, let's see, my MOVLF h'00', is a CLRF,
> but what am I missing about the MOVLF h'FF' ?

SETF was introduced only in 18F series, IIRC :)

2007\07\27@140047 by Mark Scoville

flavicon
face
SETF :-)

{Quote hidden}

2007\07\27@142813 by Mark Scoville

flavicon
face
>
> SETF was introduced only in 18F series, IIRC :)
> --

My earlier response should have said the 17*C* series has the SETF... as far
as I know there isn't a 17F series.. :-)

-- Mark



2007\07\27@142819 by Mark Scoville

flavicon
face
>
> SETF was introduced only in 18F series, IIRC :)
> --


SETF was (and still is) in the 17F series as well.


-- Mark


2007\07\27@170932 by Jan-Erik Soderholm

face picon face
Right.

My natural respons is of course that i *thought*
that we where talking about the PIC16... :-)

Regards,
Jan-Erik.

Marcel Birthelmer wrote:
{Quote hidden}

2007\07\27@174701 by Jinx

face picon face


> As far as I can see, there's no built-in MOVLF (move literal to file)
> instruction, at least on the 18F6680 I've been working on.

It is a bit of a pain, just from a more-typing POV. I suspect most
people would use a macro

movlf    macro   val,file ; or just 'mov'
        movlw   val
        movwf   file
        endm

Have to keep an eye on the macro changing W though

2007\07\28@091707 by Howard Winter

face
flavicon
picon face
On Fri, 27 Jul 2007 14:58:28 +0100, Matthew Rhys-Roberts wrote:

> As far as I can see, there's no built-in MOVLF (move literal to file)
> instruction, at least on the 18F6680 I've been working on.
>
> I know it's hardly a problem to load the literal into W first, then move
> W into the desired file, but why would they fail to design such a useful
> one-step function?

Well historically, there wasn't room.  With a "mid-range" 14 bit instruction, 8 bits are needed for the literal, leaving only 6 for the opcode and the
destination address.  Even if they used just one bit for the opcode (really wasteful, as it would take up half of the instruction "space" available for
this one instruction) it would only leave 5 bits, or 32 addresses for the deatination - next to useless.

Why they didn't introduce it with the 18 series I don't know, but I presume there's a reason deep in the design philosophy!  :-)

Cheers,


Howard Winter
St.Albans, England


2007\07\31@144009 by peter green

flavicon
face

> a matter of RISC architecture... I guess :)
> MOVFF (file to file) came out in 18F parts, was not there on earlier ones.
>
> You can write a macro for MOVLF: the rationale is that such a macro will
> still, probably, be faster than a MOVLF-like instruction on a 80x86 CPU...
>
>  
Afaict there is no easy way to move a literal to a file register without
overwriting w in the process.

2007\07\31@155909 by Dario Greggio

face picon face
peter green wrote:


> Afaict there is no easy way to move a literal to a file register without
> overwriting w in the process.

hmmm, 8 BCF o BSF ? :)


'[PIC] No native MOVLF instruction?'
2007\08\02@021200 by William Chops Westfield
face picon face

On Jul 31, 2007, at 12:58 PM, Dario Greggio wrote:

>> Afaict there is no easy way to move a literal to a file
>> register without overwriting w in the process.
>
> hmmm, 8 BCF o BSF ? :)

one SETF (on pic18) or CLRF followed by 4 or fewer BCF/BSF !

It'd be mildly interesting to come up with a code generator
that would set a file register to any given constant in a
minimum number of instructions.  RLF, RRF, and DECF might be
useful as well, and there's always the XOR hack to fall back
on.  ARM compilers do something similar because of the weird
way ARM does constants...

BillW

2007\08\02@024136 by Dario Greggio

face picon face
William Chops Westfield wrote:

>>hmmm, 8 BCF o BSF ? :)
>
> one SETF (on pic18) or CLRF followed by 4 or fewer BCF/BSF !

Smart one :)

> It'd be mildly interesting to come up with a code generator
> that would set a file register to any given constant in a
> minimum number of instructions.  

Yes...

> ARM compilers do something similar because of the weird
> way ARM does constants...

You're absolutely right! I remember working on a "simple" C compiler for
Acorn Archimedes, probably one of the first ARM out there, and due to
its peculiar instructions, I ended up with a "integer constant parser"
which was able to generate the lowest possible number of instructions to
express it (using Shifts etc).


--
Ciao, Dario

2007\08\02@054033 by wouter van ooijen

face picon face
> You're absolutely right! I remember working on a "simple" C
> compiler for
> Acorn Archimedes, probably one of the first ARM out there, and due to
> its peculiar instructions, I ended up with a "integer
> constant parser"
> which was able to generate the lowest possible number of
> instructions to
> express it (using Shifts etc).

Why would a compiler want to do that, for speed? For size 1 instruction
+ 1 PC-relative-adressable constant is enough!

Wouter van Ooijen

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



2007\08\02@061854 by Mike Harrison

flavicon
face
On Thu, 2 Aug 2007 11:40:20 +0200, you wrote:

>> You're absolutely right! I remember working on a "simple" C
>> compiler for
>> Acorn Archimedes, probably one of the first ARM out there, and due to
>> its peculiar instructions, I ended up with a "integer
>> constant parser"
>> which was able to generate the lowest possible number of
>> instructions to
>> express it (using Shifts etc).
>
>Why would a compiler want to do that, for speed? For size 1 instruction
>+ 1 PC-relative-adressable constant is enough!

Yes - speed (and also possibly size if there are no convenient breaks in the code within branch
range to insert the constant).
But if it can be done in 2 instructions, PC-relative load is wasteful.
There is always a tradeoff between size and speed, but where one can be improved without impacting
the other, this is always going to be better.


2007\08\02@062812 by Dario Greggio

face picon face
wouter van ooijen wrote:

>>its peculiar instructions, I ended up with a "integer
>>constant parser"
>>which was able to generate the lowest possible number of
>>instructions to
>>express it (using Shifts etc).
>
> Why would a compiler want to do that, for speed? For size 1 instruction
> + 1 PC-relative-adressable constant is enough!

Well, now I don't remember the exact reasons, but: (I still have the
sources!)

more or less, since the 32bit Op-Code could handle only some limited
Constant Value in its fields, say 10 bits (i.e. max = 1023), but there
was also a "Shift" field, say up to 8, you could sayt that:
* for numbers below 1023, use MOV D0,#number,Shift=0
* for numbers >= 1024 but with zero bits in the lowest positions and a
total amount of significative bits still <= 10, use MOV
D0,#number,Shift=shift
* for other numbers >= 1024 , MOV D0,#(number & 1023),Shift=0 .. ADD
DO,#(number >> 10),Shift=shift




--
Ciao, Dario

2007\08\06@091901 by Matthew Rhys-Roberts

flavicon
face
Just been catching up with all the replies to my question. Very
educational. Thanks for so much interest!

Regards,
Matt

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