COG Register use in HUBEXEC
potatohead
Posts: 10,261
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]
Both orgs needed, and shown for clarity, rest of thread left for archive.
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
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?
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)
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.
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.
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.
Address define of registers, is not a Program Counter problem.
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 ?
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.