Spin and asm code using the same cog

Patrick1ab · 2010-04-18 18:03

Hi everyone!

Is it somehow possible to call an assembler function without using another cog?
If yes, please let me know how to do this? If not, please try to tell me why it isn't possible?

Thanks

Patrick

Oops, seems I've found the answer in the manual:

Propeller Manual said...

Spin code is executed from Main RAM by a cog running the Spin Interpreter, however, Propeller Assembly code is executed directly from within a cog itself. Because of this nature, Propeller Assembly code and any data belonging to it must be loaded (in its entirety) into a cog in order to execute it. In this way, both assembly code and data are treated the same during the cog loading process.

But why can't the Spin interpreter "pass it on"?

Post Edited (Patrick1ab) : 4/18/2010 6:14:50 PM GMT

potatohead · 2010-04-18 18:14

It can't be done.

The reason it's not possible is your SPIN code is being executed by a COG, running the SPIN intrepeter. That takes the whole COG. PASM only executes in a COG, not the HUB. SPIN is actually a PASM program, that gets loaded onto a COG, which then "runs" your SPIN byte code, residing in the HUB.

When you call a PASM function, another COG must be loaded with the program, as that's where PASM runs.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!

Patrick1ab · 2010-04-18 18:24

Thanks for your quick reply, potatohead.

It's a pity that it isn't possible.
Perhaps this could be a feature of future chips (maybe too late for Prop II)

potatohead · 2010-04-18 18:31

Well, there are some alternatives, including just launching the COG, getting PASM done, then shutting it down. One bad thing is that it takes a while to start up a COG...

If you've a few PASM things you need to get done, pack them into one COG, which then loops, checking HUB memory. Have a defined start value for each procedure, and shared memory locations to get results back to the SPIN program. The graphics library does this kind of thing. You have your SPIN program set the memory values up, pass them to the "library cog', which then waits. When it sees the value it needs to go off and do something, it does it, then resets the value back to the "waiting" value. Your SPIN program can then, just set a value, knowing something is going to get done, then it watches for the value to be reset, knowing the task is complete, with the data in the HUB.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!

Patrick1ab · 2010-04-18 19:06

potatohead said...
Well, there are some alternatives, including just launching the COG, getting PASM done, then shutting it down. One bad thing is that it takes a while to start up a COG...

... and assuming you still have a free COG

Okay, I still have three, but maybe I'm going to need them later.

potatohead said...
If you've a few PASM things you need to get done, pack them into one COG, which then loops, checking HUB memory. Have a defined start value for each procedure, and shared memory locations to get results back to the SPIN program. The graphics library does this kind of thing. You have your SPIN program set the memory values up, pass them to the "library cog', which then waits. When it sees the value it needs to go off and do something, it does it, then resets the value back to the "waiting" value. Your SPIN program can then, just set a value, knowing something is going to get done, then it watches for the value to be reset, knowing the task is complete, with the data in the HUB.

This is made in several objects I included in my program.

Dave Hein · 2010-04-18 19:12

Hmm, maybe someone could squeeze an LMM interpreter into a Spin interpreter -- or has this already been done?· It might be a nice feature for the Prop II interpreter.· A part of the spin interpreter could reside in Hub RAM, and be executed as an LMM program.· This would allow future extensions of the Spin language.

Bean · 2010-04-18 19:20

Dave,
· That is an excellent idea, and should be possible.
· The LMM loop is really small (although in most implementations it is unrolled to make it faster).

· Here is the PropBasic LMM loop (I removed the unrolled loop to make is smaller).

  ORG 0                                                     
                                                            
_LMM_Entry                                                  
                  mov           __PC,__OFFSET               
                                                            
_LMM_LOOP                                                   
                  rdlong        __INSTR1,__PC               
                  add           __PC,#4                     
__INSTR1                                                    
                  nop           ' Placeholder for LMM instruction
                  jmp           #_LMM_LOOP                  
                                                            
_LMM_JUMP                                                   
                  rdlong        __PC,__PC                   
                  add           __PC,__OFFSET               
                  jmp           #_LMM_LOOP                  
                                                            
_LMM_CALL                                                   
                  rdlong        __temp1,__PC                
                  add           __temp1,__OFFSET            
                  add           __PC,#8                     
                  wrlong        __PC,__temp1                
                  sub           __PC,#4                     
                  rdlong        __PC,__PC                   
                  add           __PC,__OFFSET               
                  jmp           #_LMM_LOOP                  
                                                            
_LMM_MOVS                                                   
                  rdlong        __MOVS,__PC                 
                  movs          __MOVS,__INDEX              
                  add           __PC,#4                     
__MOVS                                                      
                  nop           ' Placeholder for LMM instruction
                  jmp           #_LMM_LOOP                  
                                                            
_LMM_MOVD                                                   
                  rdlong        __MOVD,__PC                 
                  movd          __MOVD,__INDEX              
                  add           __PC,#4                     
__MOVD                                                      
                  nop           ' Placeholder for LMM instruction
                  jmp           #_LMM_LOOP                  
                                                            
                  '             Variables for LMM execution code
__INDEX          LONG 0  ' Used by MOVS and MOVD            
__OFFSET         LONG 0-0' Set by spin                      
__PC             LONG 0  ' Program counter

Bean

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134

March 2010 Nuts and Volts article·http://www.parallax.com/Portals/0/Downloads/docs/cols/nv/prop/col/nvp5.pdf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
There are two rules in life:
· 1) Never divulge all information

Dave Hein · 2010-04-19 18:15

Bean said...
Dave,
· That is an excellent idea, and should be possible.
· The LMM loop is really small (although in most implementations it is unrolled to make it faster).

· Here is the PropBasic LMM loop (I removed the unrolled loop to make is smaller).
...

I looked at the Spin interpreter source in the Propeller Wiki, and it might be done by moving some of the bigger spin instructions to hub RAM.· The only instruction I could find that may not be used that much is the SQRT instruction.· It uses 14 longs.· If the lookup, lookdown, strcomp, strsize, fill and move instructions were move to hub RAM it would open up about 80 longs all together.· Your LMM interpreter takes 29 longs, which would leave about 32 longs to load small loops and 16 longs for registers.
There is only one unused spincode in the table -- $3C.· This code could be used to call the LMM interpreter.· When the LMM interpreter is done it would return back to the Spin interpreter.· It seems like it should work.
Dave

Cluso99 · 2010-04-19 19:43

Thanks Bean. I just asked on another thread how long it was for LMM. I did a 4 instruction LMM loop in the shaddow ram when I was writing my faster spin interpreter but of course it does not handle long jumps, calls, movs, movd. What about movi ?? Nor do I have the 3 variables. your implementation uses 29 longs - OUCH!

Actually thinking further, I handle jumps in a different way altogether.

@Dave:
Not only does there have to be room for the LMM execution but room for variables will also be required. Only $3C is unused, but there are other 2 byte codes that are not fully utilised. Doing a minimised LMM within the spin interpreter actually works as that is how my debugger runs on top of spin in shaddow ram. The debugger can trace all the pasm instructions of the interpreter and even single step them.

I said elsewhere that I initially used overlays so I could work on the Interpreter. This works well too if there is any loops in the code.

@Patrick1ab: PropII will not solve the problem as it is still limited to 496 (well actually it increases to about 508 IIRC) longs. Using a kludge with the current PropI I think we can actually squeeze 496 + about 6-7 = about 502-503 longs.

However, the moment we add inline pasm to spin, the requirement for variables will become apparent and that is when the fun begins (or ends!!!).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz

Dave Hein · 2010-04-19 22:42

Cluso99,

When you are talking about variables in reference to inline pasm I assume you are referring to cog variables, correct?· In my previous post I suggested allowing for 16 cog variables and 32 longs for overlay space.· However, if the LMM code doesn't use the overlay it could use the 32 longs for variables.· Or maybe another way to look at it is that there would be 48 longs available for overlays and variables, which could be used in any combination that the programmer wants.

Are there spincodes that copy from hub ram to cog memory?· If there are, then the interpreter could be patched by overwritting a method with a small spincode program that would splice the LMM interpreter into the Spin interpreter.

Do you have a link for your debugger?· I'd like to take a look at it.

Dave

Cluso99 · 2010-04-20 00:39

Dave: The link is via the Prop Tools in my signature.
There is no spincodes that copy hub to cog, other than the normal byte read.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz

ManAtWork · 2010-04-20 08:05

Patrick said...
Is it somehow possible to call an assembler function without using another cog?

Hello Patrick,

I havent tried·out·but I think you could restart the current cog with a PASM section. When it's done you could reload the same cog with the spin interpreter and pass the spin routine to execute as argument. This should theoretically work as you can self-reload the curent cog with the COGINIT command. Reloading the cog takes a lot of cycles from the ASM point of view because it has to fetch 496 longs from cog memory. But it doesn't take longer as a few spin commands as spin is relatively slow.

Cheers

Cluso99 · 2010-04-20 09:31

@MenAtWork: It takes a lot longer than you realise... 496 * 16 clocks @12.5ns = ~100us just to load the cog each time

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz

Spin and asm code using the same cog

Comments