Simple Code Question

JonJon

Guys,

Could some one explain the character '/' in code.· I understand that it means divide as in x/b but in the syntax:

··· MOV··· W,/RC

Is this an 'or' function or what?· I've searched all documentation and have found nothing but this is used in the led28.src file.

Best Regards,

JonJon

·

Paul Baker

the / in this context means inverse. mov w,/rc takes the content of rc, and places the inverted value in w.
so if rc had %11110101, w would have %00001010 after execution of mov w,/rc.

mov w,/rc is the same as:

mov w,rc
not· w

but does it in one clock cycle instead of two.

Post Edited (Paul Baker) : 1/23/2005 10:52:28 PM GMT

JonJon

Paul,

Thanks! this is a very illusive piece of information. Did I miss this in the documentation? Is there a list of these magic operands anyplace?

Regards,

JonJon

Paul Baker

there are a set of mov w,(operand)fr opcodes, they are:

mov w,/fr···· ;move the inverted value of fr into w
mov w,<>fr·· ;move fr into w with the upper four bits swapped with the lower four bits
mov w,fr-w·· ;move (fr-w) into w
mov w,--fr·· ;move (fr-1) into w
mov w,++fr· ;move (fr+1) into w
mov w,<<fr· ;move the shift left by 1 of fr into w the leftmost bit is in the carry bit
mov w,>>fr· ;move the shift right by 1 of fr into w the rightmost bit is in the carry bit

they are in pages 94-100 of the SX Users Manual
http://www.parallax.com/dl/docs/prod/sx/SxUsersManualV31.pdf·and anywhere the command set instructions are listed (such as Gunther's book)

JonJon

Paul,

Your the Man...

The only document I 'was' using was the Parallax SX-Key / Blitz! Development System Manual V1.1.

Thanks,

JJ

Jim G.

Hi all...

I was going to start a new thread with this question, but found this one to add on to.

Regarding this set of special move instructions, Scenix surely went to a lot of trouble to incorporate them into the instructions set, but I have found very few times I was able to use them.

Is there a programming construct that I am missing? Can anyone provide examples of how these would be used in an effective way?

Thanks,
Jim

TD-Linux

[noparse][[/noparse] -- Removed because I was wrong, read Gunther's post below -- ]

Post Edited (TD-Linux) : 7/31/2005 10:22:04 PM GMT

Guenther Daubach

TD-Linux,

sorry, I can't agree. MOV instructions with modifiers like "/", "++", "--", "<<", ">>", "<>", and "fr-W" are not equivalents to "expanded machine language instructions". They are in fact single word, sincle cycle instructions (in turbo mode).

As stated before in this thread,

MOV W, /fr

is executed within one clock cycle, where the functional equivalent

MOV W, fr
NOT W

"eats up" two clock cycles, and two words in program memory.

There are good practical reasons for such modified instructions, and I'm glad that Scenix/Ubicom has implemented them when designing the SXes. For example, let's assume port B configured with all pins as inputs with internal pull-ups active, and push-buttons connected to all of these pins pulling them low when pressed.

With no button pressed,

MOW W, rb

would set W to $FF, and with the button at RB.0 pressed, W would be set to $FE, i.e. this is negative logic (we Germans are said to mostly think this way - Arghhhh).

If you'd use

MOW W, /rb

the results would be

$00

or

$01

instead. I think, this looks much more "positive"

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,

G

TD-Linux

Oh, really? I always thought that the SX had an instruction set similar to the PIC, and the compiler did all the work. Not any more.

I have never seen them used at all, which is odd, considering that they do fairly common tasks. Thank you for pointing them out! Will use in my next tight timing loop (which will also be my first ). I'm new to SX - which means I take in information too fast

Editing my other post to avoid confusion.

Guenther Daubach

Well,

Let me tell you a secret: There are some similarities between the many PICs and the few SXes but we should not discuss them here in detail because this forum is dedicated to the SX controller, the "better one" - I hope noone will kill me for this.

FYI: Besides the one-word/one cycle instructions, SASM, the SX assembler also supports many "expanded machine language instructions" which I usually call "compund instructions". For example,

MOW fr, #$55

can't be directly executed by the SX. SASM converts this into the sequence

MOV W, #$55
MOV fr, W

i.e. into two single word/single cycle instructions.

Please be aware that such compound instructions can cause some real trouble when they a placed after a skip instruction:

SZ
MOV fr, #55

is good for a desaster as this expands to

SZ
MOV W, #55
MOV fr, W

i.e. the

MOV W, #55

is skipped or not, depending on the status of the Z flag, but

MOV fr, W is always executed (either with the expected value in W, or some arbitrary nonsense).

Fortunately, the latest version of SASM gives you a warning on such constructs.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,

G

Bean

Good info Gunther, what usually get me into trouble is forgetting that MOV fr,#55 will also make W equal to #55.
Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95

http://www.parallax.com/detail.asp?product_id=30012

Product web site: www.sxvm.com

"One experiment is worth a thousand theories"
·

Guenther Daubach

Bean,

yes this is another important point I forgot to mention. Many "compound" instructions make use of W as temporary register, so code like this

mov W, #11
mov fr, #55

ends up in both, fr and W containing 55, and W does not contain 11 as one might expect on first glance as this sequence is expanded into

mov W, #11
mov W, #55
mov fr, W

So, "compound" instructions are nice shorthands, on the other side, they can be dangerous. You can always avoid such pitfalls by simply not using them as each can be replaced by two or more "native" SX instructions. This does not increase the code size, it is just more typing work. Sometimes, not using "compund" instructions can even save code, like the following example shows:

mov !RB, #$ff
mov !RC, #$ff

is expanded into

mov W, #$ff
mov !RB, W
mov W, #$ff
mov !RC, W

i.e. into four instruction words. Using ""native" instructions, i.e. the sequence

mov W, #$ff
mov !RB, W
mov !RC, W

results in only three instruction words, as there is no need to re-load W with $ff in this case.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,

G

Jim G.

I appreciate the info in the previous posts...

As I think about these move instructions, they all help answer a "what if" question, "what would be in fr if I had decremented it?"

So, for instance, if you wanted to decrement a counter to 1, and not less, you could use this:

mov w, --Counter
sz
dec Counter

Or a more universal impementation (useable with all of the special move instructions) would be to conditionally copy w to fr, like:

mov w, --Counter
sz
mov Counter, w

In the simple case of inc/dec however, you could just "put it back" if you didn't like the result, like:

dec Counter
sz
inc Counter

I don't want to beat this to death, but as I mentioned earlier, Scenix must have had something special in mind for these instructions. I may dig into some of their VP code to see if they used any of them.

Thanks for thinking about this...

Jim

James Newton

You might be interested in looking at the bock diagram of some microcontroller or microprocessor designs. One of the things you notice is that the logic unit that does stuff like inc, dec, shift, swap, negate, etc... has to be connected in-line with the registers and accumulator wether it is used or not. It doesn't take any more time to turn it on while you are moving data than it does to leave it of. So why not provide opcodes that allow that to happen? It turns out that it takes more logic to turn OFF the ALU for op codes that don't use it than it does to just "hardwire" the bits in the opcode that select the ALU operation to the ALU and let them be active for a wider range of operations.

I'm not sure I said that in a way that will inc or dec everyones confusion counter but in general, I'm saying that it would probably require more logic in the chip to NOT provide those "move with operation" instructions than it does to just let them happen.

CPU design is fun.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
James Newton, Host of SXList.com
james at sxlist,com 1-619-652-0593 fax:1-208-279-8767
SX FAQ / Code / Tutorials / Documentation:
http://www.sxlist.com Pick faster!

KenM

Which is why I avoid such instructions and use the "root" instructions

mov w,#55
mov fr,w

Bean (Hitt Consulting) said...
·what usually get me into trouble is forgetting that MOV fr,#55 will also make W equal to #55.
Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Ken

Jim G.

Thanks for the reply James, I know exactly what you mean.

If what you said is true then the task is to figure out what these instructions are good for... ;-)

Just for·the record·"mov· w, <<fr" can be handy for putting the high-order bit of a register into the carry bit in preparation for an arithmetic right shift using "rr· fr".

And, of course, "mov w, <>fr" is handy for dealing with hex to ASCII conversions without messing with the actual source value in the register.

Thanks for everyone's input.

Jim G.

Guenther Daubach

When looking at the instruction set of a processor/controller, in most cases, you will find some instructions that make you think "what are these good for?". Don't worry, one day, you will be glad that they are there.

For example, when I started with the SX I was wondering about the SKIP instruction, asking me why should I ever use an instruction that always skips the next one, I could always leave out the SKIP and the next instruction.

Later, when dealing with code to handle the I²C protocol, I found a good use for SKIP: To handle the bus timing, you sometimes need a delay routine for a certain period - let me call it T1 here, but sometimes you need to delay twice as long, i.e. T * 2, or T2. Here is a code snippet for this using the SKIP instruction:

DelayT1
mov w, #Delay
SKIP
DelayT2
mov w, #Delay * 2
mov DelayCounter, w
:Loop
decsz DelayCounter
jmp :Loop
ret

As you can see, the SKIP is used here to skip the initialization of W for the longer delay in case DelayT1 is called. Using SKIP instead of a JMP requires two clock cycles instead of three - not a big deal but "tricky" .

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,

Günther

pjv

Hey Guenther;

While you're on the SKIP instruction, it is very useful to turn a DECSZ into a DECSNZ or an INCSZ into a INCSNZ.

Simply use the standard DECSZ followed by the SKIP ; see the following snippet for an example to SKIP a JUMP (or whatever other instruction you lke) when the variable is NOT zero. Very handy!


DECSNZ:···· ·DECSZ·· ·Variable······· ;this will skip the next instruction if the variable equals zero
·········· ······· SKIP········ ··············· ;the variable was not zero, so now this instruction will skip the next instruction
········ ········· JUMP···· ·Wherever····· ;this (arbitrary) instruction is executed when the variable is zero, and will be skipped when the variable is non-zero

Cheers,

Peter (pjv)

Post Edited (pjv) : 8/5/2005 10:11:33 PM GMT

Guenther Daubach

Hey Peter,

good trick - I owe you a beer!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,

G

pjv

Hi;

Next time I'm in Germany I'll probably look you up! It would be fun to share experiences and compare notes.

And, of course, I'd be happy to take that beer off your hands!

Peter (pjv)

Guenther Daubach

Peter,

the beer is for granted - I'm living in the Cologne area, i.e. not that far away from your location. I'd be glad meeting you some day - just let me know then you are around.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,

G

pjv

Guenther;

Perhaps you are thinking of one of the other chaps; but I live in Canada, and I think that a ways from Cologne!

But I'll come and see you regardless; It'll be worth the trip. And if you ever want to see the Rocky Mountains or Banff and Lake Louise, I'd be happy to host you!

Cheers,

Peter (pjv)

Guenther Daubach

Peter,

sorry, I obviously have messed up the various "Peters" on this forum thinking of one, living a bit closer to Cologne .

Nevertheless, should you make it to Germany, please let me know in time - you are more than welcome here at any time. I also appreciate your hosting offer. So far, I only had the chance to visit Canada/Toronto just once, besides the many trips to the US (about 40 so far).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,

G