Shop OBEX P1 Docs P2 Docs Learn Events
Loading several cogs from one SPIN file — Parallax Forums

Loading several cogs from one SPIN file

FMMT666FMMT666 Posts: 14
edited 2013-01-12 04:42 in Propeller 1
It has been quite a while since I used the Propeller and I am pretty sure
this question has already been answered a thousand times, but I did not
manage to find a clear answer for that one:

What exactly happens if I load more than one cog from only one SPIN file?

Like this:
PUB Start

  cognew( @one, 0 )
  cognew( @two, 0 )

DAT                     org     0     

one                     jmp     #one

BLABLA                  long    $12345678
var1                    long    1
var2                    long    2
var3                    long    3
var4                    res     1


DAT                     org     0

two                     mov     var4, BLABLA
three                   jmp     #three     

Are all of the "variables" appended to the second DAT section?
If yes, at what address do they go, are they appended to the end of the
section or do they use absolute addresses (which would result in overwriting code)?

From and to what address is "BLABLA" written to?

What happens if I use the "FIT" directive between these DAT secions?
Is it able to detect an overflow?

Are there any other pitfalls related to this structure?
Anything else I should know or should take care of?

D*mn, and I thought I already mastered the Propeller ;-)


Axel

Comments

  • RaymanRayman Posts: 14,666
    edited 2013-01-12 04:18
    These are pretty advanced questions, so I may not know the correct answers, but I'll try anyway...

    First, yes you can launch two cogs this way from one spin file.

    The cognew command just copies 512 longs from RAM to the cog without looking at what's there, so yes your "two" data will be in your "one" cog.
    Exception is that "res" doesn't actually have a HUB spot, it's just a reserved placeholder.

    not completely sure about BLABLA. I think the assembler will just try tu use that long value there, which should give a compile error, I think...

    Two Fit commands should work fine. I think it's all relative to the previous org 0.
  • MagIO2MagIO2 Posts: 2,243
    edited 2013-01-12 04:42
    As rayman already stated, cognew is as simple as that : it always copies 512 Long (2048 Bytes) into COG RAM.

    The tricky part is to understand what the compiler is doing!
    DAT, RES, ORG and FIT are compiler-statements which for example effect the compiler-internal label & address handling (RES & ORG).

    You have to understand that there are 2 address-counters, one for the HUB-RAM addresses and one for the COG-RAM addresses and each label inside of a DAT-section has 2 addresses: 1. the HUB-RAM address and 2. the COG-RAM address!
    HUB-RAM addresses are used in SPIN-instructions, COG-RAM addresses are used in PASM code.
    Per Default, when starting a DAT section with the ORG 0 Statement, you tell the compiler that all labels used int the following code are relative to this ORG in terms of COG-RAM addresses . So, in your example one has whatever address in HUB-RAM, but it has address 0 in COG-RAM. BLABLA has address 1 in COG-RAM ...

    The idea behind RES is to allow having labels without occupying memory in HUB-RAM. So, these labels are local for the COG which also includes that you have to initialize these variables before using. After the first RES statement you loose sync with the HUB-RAM (COG address-counter is increased, but HUB-address Counter is NOT increased), that's why RES have to be at the end of your PASM code.

    In function two you have a problem, because cognew will start copying exactly starting from two, so there is NO BLABLA in this COG-RAM.

    Normally with FIT you specify the COG-RAM size. FIT is a check that the PASM / data between an ORG and that FIT do not exceed the given COG-RAM address-space. So, it's only purpose is to give you a warning in case your PASM/data-section grows too big.
Sign In or Register to comment.