Shop Learn
COG Register use in HUBEXEC — Parallax Forums

COG Register use in HUBEXEC

potatoheadpotatohead Posts: 10,170
edited 2016-01-25 06:48 in Propeller 2
I'm at the point now where I'm writing HUBEXEC code. And it's cool. For a while, I just kept it simple, COG code only, but I've got the basic COG functions I need to proceed with a larger project done, and I'm pretty sure it won't fit into a COG. Even if it does, I want to do it HUBEXEC.

Everything went fine, until I wanted to use COG Registers as working registers. Somewhere in this long discussion, we talked about that, and I can't seem to remember or find the detail on it.

Say I want to do something like this: [edited for clarity, both orgs needed]

                orgh    $20000
                org    0
play            jmp     #hubex                          'game loop to go here, hubexec


gtemp   long    0                                       'COG working temp registers for computation
gtemp1  long    0

                orgh    $21000                          'hubexec, just for clarity
hubex           mov     dirb, #$f
.loop           testb   inb, #24 wz
                                                        'this works as expected, no worries
        if_z    wrlong  ##@blitlist, ##@bmail
        if_nz   wrlong  ##@startlist, ##@bmail

                rdlong  gtemp, ##@score                 'this works, reference "org 0" for COG register address

                jmp     #.loop


Both orgs needed, and shown for clarity, rest of thread left for archive.

Comments

  • potatoheadpotatohead Posts: 10,170
    edited 2016-01-23 19:02
    Do I need both orgs?

    I just tried that, and it appeared to work correctly. I'll have to write a test to make sure, but maybe that's the answer right there. Pnut doesn't know where the COG is, without both orgs?

    Secondly, I recall a discussion about no relative jumps from COG to HUB, HUB to COG. So, if I want to include some COG code in that code block above, I need to specify absolute addresses as well. Technically, one could hand assemble PASM to do it, and I don't want to, but we ruled relative out for sanity purposes, right?

    Does that apply to reads and writes, or just execute mode changes?



  • MJBMJB Posts: 1,200
    potatohead wrote: »
    Do I need both orgs?

    I just tried that, and it appeared to work correctly. I'll have to write a test to make sure, but maybe that's the answer right there. Pnut doesn't know where the COG is, without both orgs?
    yes - need to ORGs for COG and HUB
    potatohead wrote: »
    Does that apply to reads and writes, or just execute mode changes?
    here you use different instructions for COG and HUB so no issue ...

  • Of course, as I've realized writing code today. Doh!
  • jmgjmg Posts: 14,650
    MJB wrote: »
    yes - need to ORGs for COG and HUB
    Other assemblers use SEGMENT semantics to manage register/data allocation, which I find preferable to pushing ORG to do both.
    Usually, ORG is mainly used to change PC, so is best avoided in a more confusing use.

    Also, the Segment approach 'tacks-on' address requests that may appear in include files, or subroutines, and this also helps the assembler catch usage errors. (ie accidental opcodes into the wrong segment)


  • potatoheadpotatohead Posts: 10,170
    edited 2016-01-24 05:36
    I would rather not discuss segments. The two orgs are just fine. Truth is, segment would not be inclusive of all that the two orgs can do. Now I regret a momentary brain lapse... (which segment would not have remedied, and would have required more than I just had to recall)

    If a pasm programmer specifies only a COG org, that's COG code, explicit. If they specify a HUB org, then it's HUB code, explicit. The same is true for data in both cases.

    When both are specified, it's HUB or COG code (and that means both concurrently, not just one or the other XOR style), meaning the two can be mixed, code and data, in the context of the COG and HUB at the same time. Frankly, there may not actually be a clear segment, depending on what one chooses to do, and I like it that way.
  • jmgjmg Posts: 14,650
    potatohead wrote: »
    The two orgs are just fine. Truth is, segment would not be inclusive of all that the two orgs can do.

    Assemblers I use have both Segment and ORG directives, so clearly there is no subset problem.
    The user problem I see is in having one directive pushed to manage both CODE and DATA spaces, which is bound to cause confusion. (and this seemed to me to be a thread about usage confusion)
    Linkers also expect to be dealing in Segments.


  • potatoheadpotatohead Posts: 10,170
    edited 2016-01-24 06:46
    Well, this very clearly is a mistake I won't make again.

    Truth is, I was in the middle of coding something. Thought I would post up a quickie to my friends on the forum, and in the middle of that, recalled what I needed to.

    It's literally, "Oh yeah, gotta make sure to set the COG PC, so Pnut can address the COG registers properly."

    Nothing else is needed. It's not hard, nor all that confusing either.

    SEGMENT doesn't help here. Not in the context of the small, simple, unified SPIN+PASM environment. With the two ORGS, people can do anything they want, and put it all in one file, and mix it together anyway they want to, and that's just great.

    I want that to exist, and be no more complex than it needs to be so that it will fit on the chip and be very useful. And we've had that chat a ton of times too.

    "those other assemblers" designed to work with "those other tools" will get Propeller 2 support soon, and with them comes all this stuff you keep pushing for. Great!

    Now is not the time.
  • jmgjmg Posts: 14,650
    potatohead wrote: »
    It's literally, "Oh yeah, gotta make sure to set the COG PC, so Pnut can address the COG registers properly."
    ..and there you nicely prove my point : PC means Program Counter to most ASM coders.
    Address define of registers, is not a Program Counter problem.
    potatohead wrote: »
    Now is not the time.
    Sure, 'kick the can down the road' means there will be (at least) two future assembler sytaxes.
    The proper one using Segments, and the hard-to-explain one using ORG in strange ways...
    Code examples will be less portable, and more confusing.
    Surely smarter to think to avoid such issues as early as possible ?
  • potatoheadpotatohead Posts: 10,170
    edited 2016-01-24 20:53
    Surely not.

    :)

    Oh, and I mean that, and in a nice, genuine way.

    To a PASM programmer, the PC means program counter same as it does for anyone else. Most assembly programmers aren't working on a device that copies data from the shared memory, into a local memory like a COG does, are they? Given that behavior, the org and orgh statements make perfect sense. At that point, one could run the code in hubex or start a cog, or do both frankly, multiple times, concurrently even. There are, after all, 16 program counters.

    So, if I plan on running a COG image from there, the org 0 did set the PC to the start of the COG, and that start of the COG is also the addressing base, all one and the same. If that code jumps out of the COG, the PC is off in HUB land, which the orgh xxx takes care of, and I also know what will be in the COG registers, should the HUB code reference them. It's all one nice, neat package. Programmer does what they want to. It will just work.

    I'm not really sure what a segment is, in that context. Are you?

    You can be 100 percent sure there will be at least two, if not more assembly syntaxes out there. There already are. More are coming. People will do stuff, and that's fine. :)

Sign In or Register to comment.