Can't get CALL to work... [Solved]

Bean · 2006-12-05 17:07

I have a routine that I want to CALL, but whenever I do the code doesn't work (doesn't seem to do anything).
If I put the code from the subroutine right into the main code it works fine. But when I "CALL #Plot1" I get nothing.

:YLoop        MOV _accum,_distX
              SHR _accum,#1
              MOV _count,_distY  WZ
:YLoopNext    CALL #Plot1
              ADD _Y,_dirY
              ADD _accum,_distX
              CMP _accum,_distY  WC
        IF_NC SUB _accum,_distY
        IF_NC ADD _X,_dirX
        IF_NZ DJNZ _count,#:YLoopNext
              MOV _temp,#0
              WRLONG _temp,_par
              COGID _cogID
              COGSTOP _cogID
 
' -----------------------------------------

 
Plot1         MOV _pixelAddr,_Y   
              SHL _pixelAddr,#8
              ADD _pixelAddr,_X   
              SHR _pixelAddr,#3   
              ADD _pixelAddr,_screenAddr
              MOV _pixelMask,#1
              MOV _temp,_X
              AND _temp,#7
              SHL _pixelMask,_temp
              RDBYTE _temp,_pixelAddr
              OR _temp,_pixelMask
              WRBYTE _temp,_pixelAddr
Plot1_ret     RET

Any ideas ? I can post the complete code if you want.

Bean.
·

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheap used 4-digit LED display with driver IC·www.hc4led.com

Low power SD Data Logger www.sddatalogger.com
SX-Video Display Modules www.sxvm.com
Stuff I'm selling on ebay http://search.ebay.com/_W0QQsassZhittconsultingQQhtZ-1

"People who are willing to trade their freedom for·security deserve neither and will lose both." Benjamin Franklin

Post Edited (Bean (Hitt Consulting)) : 12/6/2006 7:51:09 PM GMT

bambino · 2006-12-05 17:30

I,m really new at this, but I'll take a stab in the dark here.

Extra Stack space maybe?

Phil Pilgrim (PhiPi) · 2006-12-05 18:01

Bean,

Your example shows the two blocks of code as contiguous. Is that the way they appear in your app (i.e. without any intervening RES lines)? (I'm sure you know better, but it never hurts to ask!

)

-Phil

Bean · 2006-12-05 18:22

There is just code between them.

Now I do have two assembly routines in this one file, each start with their own ORG line, but the subroutine and the calling code is completely contained within the first section of code. All of the DAT and RES are at the end of the file.

It seems like it doesn't even get to the Plot1 code, because I don't even see 1 pixel on the screen.

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheap used 4-digit LED display with driver IC·www.hc4led.com

Low power SD Data Logger www.sddatalogger.com
SX-Video Display Modules www.sxvm.com
Stuff I'm selling on ebay http://search.ebay.com/_W0QQsassZhittconsultingQQhtZ-1

"People who are willing to trade their freedom for·security deserve neither and will lose both." Benjamin Franklin
·

Phil Pilgrim (PhiPi) · 2006-12-05 18:28

Bean,

That extra ORG is your problem. This will reset the program counter to the value specified. References in the first block of code to locations after the second ORG will point to the wrong locations.

-Phil

Bean · 2006-12-05 18:45

Phil,
The Plot1 code and the YLoop code are both completely in the first code block. IOW the second ORG comes AFTER all of the code I posted.

I will work on pearing down the complete code so I can post it.

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheap used 4-digit LED display with driver IC·www.hc4led.com

Low power SD Data Logger www.sddatalogger.com
SX-Video Display Modules www.sxvm.com
Stuff I'm selling on ebay http://search.ebay.com/_W0QQsassZhittconsultingQQhtZ-1

"People who are willing to trade their freedom for·security deserve neither and will lose both." Benjamin Franklin
·

Phil Pilgrim (PhiPi) · 2006-12-05 19:23

Bean,

But if code in the first block refers to variables after the second block (i.e. the LONGs and RES lines at the end), you will still have a problem. This is because their addresses will be referenced to the second ORG.

But post your complete code, and I'll take a look...

-Phil

rokicki · 2006-12-05 19:31

Yeah, the ORG stuff confuses me somewhat, and I've never been able to get a multi-ORG object to do what I want.

So I just don't do multi-ORG objects anymore; I always use a single ORG and a dispatch at the top.

Another trap: you can pass values to the initialization of a cog by writing assembly RES locations in SPIN.
But there's a big gotcha. If you do something like this:

pin := 14
cognew(@entry, 0)
pin := 15
cognew(@entry, 0)

dat
org
entry ...
pin res 1

what happens is the cognew returns before the copy has completed, so the pin := 15 can happen before
the copy, meaning that potentially both cogs see a value of 15 for the pin. If you stick a short delay
after the cognew this problem goes away.

There seem to be an awful lot of traps in Spin and assembly. Nothing that an experienced coder can't
handle, of course, but still.

I also seem to encounter the same problems over and over, although I'm getting better. I always want
to use ina as a destination register. I always want to jmp foo rather than jmp #foo. etc.

I find it helps me to put a sentinel program into the EEPROM that just blinks a light. Then, when my
assembly program runs away and resets the chip, I see that blinking light, rather than (perhaps) an
old version of the program. (And yes, I frequently accidentally hit F11 rather than F10, so I end up
having to reload this sentinel program.)

Gerry Keely · 2006-12-05 19:49

Should label have a colon in front of it -- see page 348 of manual ????

Label is an optional statement label. Label can be global (starting with an underscore
‘_’ or a letter) or can be local (starting with a colon ‘:&#8217[noparse];)[/noparse]. Local Labels must be
separated from other same-named local labels by at least one global label. Label is
used by instructions like JMP, CALL and COGINIT to designate the target destination.

regards

Gerry

Bean · 2006-12-05 20:43

Okay, here is the code. You'll need an LM1881 chip to actually use it, but maybe you can see what I'm doing wrong.

As posted the code works. But if you uncomment the "CALL #Plot1" lines, and comment out the indented code below them (which is the exact same code as in the Plot1 subroutine) then it doesn't work. Doesn't even plot 1 point, so it seems like it is not getting to the "Plot1" subroutine.

Any help...

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheap used 4-digit LED display with driver IC·www.hc4led.com

Low power SD Data Logger www.sddatalogger.com
SX-Video Display Modules www.sxvm.com
Stuff I'm selling on ebay http://search.ebay.com/_W0QQsassZhittconsultingQQhtZ-1

"People who are willing to trade their freedom for·security deserve neither and will lose both." Benjamin Franklin

rokicki · 2006-12-05 21:01

You have:

org
(code that uses some res vars)
org
(more code)
... res vars ...

What's happening here is the org is resetting the address, so the res vars are with
respect to the *second* org, and thus code that modifies the res vars are overwriting
that code in the second org.

For instance:

org
mov v1,#0 ' curr address is zero
org
mov v1,#0 ' curr address is zero, but *loaded* at 1+
v1 res 1 ' curr address is 1, so the first mov killed the second instruction.

Bean · 2006-12-05 21:08

Yep, you're right.
I move the RES up before the 2nd ORG and it seems to work.

Thanks.

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheap used 4-digit LED display with driver IC·www.hc4led.com

Low power SD Data Logger www.sddatalogger.com
SX-Video Display Modules www.sxvm.com
Stuff I'm selling on ebay http://search.ebay.com/_W0QQsassZhittconsultingQQhtZ-1

"People who are willing to trade their freedom for·security deserve neither and will lose both." Benjamin Franklin
·

Phil Pilgrim (PhiPi) · 2006-12-05 21:13

Actually, since the code block in the second ORG section is shorter, the RES variables will have addresses that overlie code in the first ORG section. So writing to those addresses from the first ORG section will overwrite code in that section. And therein lies the trouble.

-Phil

rokicki · 2006-12-05 21:33

What are you trying to do with the second ORG, anyway? It looks like you want two entry points in the same object,
but this will almost always lead to problems. Why not just use a dispatch at the top?

Bean · 2006-12-05 22:42

rokicki,
The Overlay code runs in the cog all the time to generate the video overlay.
The DrawLine code is used to quickly draw a line, then it is stopped. So this code is started and stopped all within the object. Kinda like an assembly helper program.

Phil,
So I was modifying the DrawLine code by putting values in the RES variables. Effectly create "junk" code that crashed when executed ?

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheap used 4-digit LED display with driver IC·www.hc4led.com

Low power SD Data Logger www.sddatalogger.com
SX-Video Display Modules www.sxvm.com
Stuff I'm selling on ebay http://search.ebay.com/_W0QQsassZhittconsultingQQhtZ-1

"People who are willing to trade their freedom for·security deserve neither and will lose both." Benjamin Franklin
·

Phil Pilgrim (PhiPi) · 2006-12-05 23:00

Bean,

Bean said...
So I was modifying the DrawLine code by putting values in the RES variables. Effectly create "junk" code that crashed when executed ?

Yup.

-Phil

rokicki · 2006-12-05 23:03

Okay, so you're launching multiple cogs at different entry points.

Right, easiest way to do this is to only use one org, one entry, and dispatch at the top. This way you have a single address space within the
cog and everyone is happy, no variables smash code or anything like that.

Bean · 2006-12-05 23:05

rokicki,
Yes, that would make it less painful, but I want to keep everything in one object if possible. Plus I'm learning alot about the Propeller [noparse];)[/noparse]

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheap used 4-digit LED display with driver IC·www.hc4led.com

Low power SD Data Logger www.sddatalogger.com
SX-Video Display Modules www.sxvm.com
Stuff I'm selling on ebay http://search.ebay.com/_W0QQsassZhittconsultingQQhtZ-1

"People who are willing to trade their freedom for·security deserve neither and will lose both." Benjamin Franklin
·

Phil Pilgrim (PhiPi) · 2006-12-05 23:14

Bean,

If you're launching into separate cogs, it's fine to use separate ORGs. But make sure each ORG section is self-contained. You just don't want to refer in one section to symbols in another. As long as you can avoid that, you'll be fine.

Also, I notice that your DrawLine routine gets "cognewed" each time it's called. That adds a breathtaking amount of overhead. It would be better to launch it once and pass commands and arguments through a data structure in hub memory. That way, you can also put additional routines (e.g. DrawCircle) in the same cog.

-Phil

Can't get CALL to work... [Solved]

Comments