Self-modifying code question - one way works t'other doesn't!

Alex Mackinnon

Hi,

In my ASM this works...

······· mov vv2,#table
······· add vv2,idx
······· movs :rdtab,vv2
:rdtab··mov vv1,#0
...etc,·······

but this does not...

······· movs :rdtab,#table
······· add :rdtab,idx
:rdtab··mov vv1,#0
...etc,

...and I think it should! The second would potentially save 2 longs (1 instruction and 1 temporary register)

Thanks,
A.

Graham Stabler

looks OK to me too, I'll be interested to see the solution.

Mike Green

Neither case "should" work (I don't know why the first case does). You can't modify an instruction with the immediately preceeding instruction because the Propeller fetches the next instruction before the destination of the previous instruction is stored. This should work:

        movs :rdtab,#table
        add :rdtab,idx
        nop
:rdtab  mov vv1,#0
...etc,

Alex Mackinnon

Here's the actual code and, for whatever abherrant reason, it is working fine...

DAT
              org       0
'not using PAR - setting values in spin before starting
doinputa      or        dira,rmask
:loop         mov       vcnt,#8
              mov       vidx,#0
              mov       csv,#0
:loop1        mov       vv2,#regi
              add       vv2,vidx
              movs      :soutv,vv2
:soutv        mov       outa,0
              mov       vv1,ina
              and       vv1,lomask
              mov       vv2,#rshft
              add       vv2,vidx
              movs      :sshft,vv2
:sshft        ror       vv1,0
              or        csv,vv1
              add       vidx,#1
              djnz      vcnt,#:loop1      
              wrlong    csv,dika1
              jmp       #:loop

vv1     long  0
vv2     long  0
vcnt    long  0
vidx    long  0
csv     long  0
rmask   long  $70_00
lomask  long  $0000_0F00
regi    long  $00_00, $10_00, $20_00, $30_00, $40_00, $50_00, $60_00, $70_00
rshft   long  8,4,0,28,24,20,16,12
dika1   long  0

I'm really just still playing at the moment... getting the feel of the best way to use the assembly and the cogs - for instance I've just spotted that I could do away with the regi table and just shift the idx value by 12-bits for the same effect. Like I say - just playing to see how it all works - although I've got 6-axis with quadrature feedback, jog-buttons, VGA display, keyboard, G&M code interpreter and programme editor all in 24K at the moment LOL.

Post Edited (Alex Mackinnon) : 5/23/2007 2:37:08 PM GMT

Mike Green

You really do need the NOPs before :soutv and :sshft. Frequently, you can change the order of instructions to put something useful (instead of a nop) in that position.

Alex Mackinnon

Thank you, yes, I will put the NOPs in and bear in mind the Propeller has some simple pipelining going on. I wish the datasheet was a bit more complete but I guess I can't really complain as the processor is great and I'm sure they don't have the resources of a Zilog, Intel, Motorola or even a Microchip [noparse]:)[/noparse].

Paul Baker

Alex,
You are correct that the information is lacking from our literature, however that information belongs in the manual when discussing MOVS/MOVD/MOVI since no in depth discussion of the instructions occurs in the datasheet. I will get the information added to the errata. Meanwhile you should check out the Propeller Tricks and Traps sticky thread, it has the information about the self-modifing instructions plus a whole slew of other gotchas you may not be aware of.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

Alex Mackinnon

Thanks - I think a little T-state diagram in the manual and datasheet would be appropriate - with a T-state diagram I would have been able to see that there was an overlap on the instruction processing.

I'll download the tips and tricks too.

My gripe about the parsity of the data is no detraction from the processor though [noparse]:)[/noparse]

Paul Baker

Alex,
You're correct; a T-state diagram is just the sort of thing which belongs in the datasheet. I have added it to the to-do list for the datasheet. For your current edification, the Pipeline is SDIR (Source Destination Instruction Result) where the instruction stage is for the next executed instruction (this is also the execute stage for the current instruction), but it is this interleaving of the instruction fetch and result which dictates the need for an intervening instruction when doing self-modifying code.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

ericball

Question, say you update the next instruction, will that update be effective the next time through the loop? i.e.

loop ADD plot, d1
plot WAITVID lineram, #%%3210
DJNZ count, #loop

So the first time through the loop, it's WAITVID lineram, and the second time it's lineram+1.

Mike Green

Yes. The WAITVID instruction is fetched before the ADD completes. The next time through the loop, the modified instruction will be fetched. Essentially the WAITVID is "one loop behind".

potatohead

Are flag states pipelined too?

So, instead of a NOP, one puts a useful instruction between the modifier, in self modifying code, and the target of the modifier. The target instruction is conditional, with the flag condition being set in the instruction immediately prior to it.

           shr  data, #5  wz
     if_Z  mov  x, y

Mike Green

No, only the instruction fetch is pipelined. The result is stored before the actual instruction execution cycle occurs (where the conditional execution happens).