using coginit in assembler

Chris Micro · 2009-07-02 08:33

Hello,

how can I use coginit with symbolic labels? Here is my code example: cog 0 starts with the coginit instruction cog3.
But my problem is, that I have to write the startadr as an absolut value. How can I tell the compiler to to it automatically.


        org     0
start0
        shl startadr,#4

        add startadr,#3 'cog3
        coginit startadr

end0
        jmp #end0

startadr long $38

        fit 496

'####################### COG3 #########################################################

        org     0
start
        mov r0,#$00 'clear screen command
        wrbyte r0,#PUTCHAR

kuroneko · 2009-07-02 09:07

Either initialise it from SPIN (before you start the cog) with e.g.

startadr := @start

or from within the DAT section with

startadr   long @start + $10

Chris Micro · 2009-07-02 09:36

Hi kuroneko,

on my emulator I have no Spin interpreter. Therefore I will use the version with the DAT-section. Is the DAT section always starting from $10 ? What happens if I have multiple objects with DAT sections, does it work?

Thanx,
chris

kuroneko · 2009-07-02 09:43

IIRC that's just a compiler bug which doesn't take care of the global 16 byte header of the binary. It's not tied to a specific DAT section. I haven't tried multiple objects specifically but I expect it's the same.

heater · 2009-07-02 09:49

Hmm.. not sure off hand.

I don't know if this is any use but bstc has an @@@ operator that will get the correct address for you.

So:

startadr   long @@@start

Then bstc can also output the raw binary of the PASM with the -c option

bstc -c filename

According to Brad:

It drops a raw .bin file of the first objects DAT section with no header, method table or spin code.

Which might help if you only want one DAT section out I guess.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

BradC · 2009-07-02 09:53

kuroneko said...
IIRC that's just a compiler bug which doesn't take care of the global 16 byte header of the binary. It's not tied to a specific DAT section. I haven't tried multiple objects specifically but I expect it's the same.

It's not a bug, that is by design. You are only referencing the address of the label within the object. It happens to work the way you describe for the top object as the compiler always starts the object at $10, however any sub-objects will start wherever the compiler puts them.

There was an "extension" implemented my mpark in Homespun that allowed you to use @@@ on a DAT label, and that would return the hub address of that particular label, but while many requested it, I don't think it's ever been used in anger.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Missed it by ->" "<- that much!

kuroneko · 2009-07-02 10:01

I see, didn't know that. My knowledge is/was based on comments found in the OBEX or some other SPIN file which suggested a bug [noparse]:)[/noparse] Anyway, it's something to be aware of.

Edit: Just verified, $10 is only valid for the top object.

Post Edited (kuroneko) : 7/2/2009 10:24:27 AM GMT

heater · 2009-07-02 10:23

BradC: Getting a bit off topic maybe but whenever I start thinking about @, @@, @@@ in Spin, VAR and DAT I get a bit confused.
Just now I don't know what I'm looking at with the following code and listing from BST.
Where no @ is used the listing shows a value of 4 for startaddr0.
Using a single @ results in $3C for staraddr1, as expected $10 away from the start HUB address.
Using @@ results in startaddr2 being zero.
Using @@@ gives what we want, the actual HUB address of start.

So what is happening in the @@ case?

PUB something

DAT
        org     0
start0
        shl startadr0,#4

        add startadr0,#3 'cog3
        coginit startadr0

end0
        jmp #end0

startadr0 long start
startadr1 long @start
startadr2 long @@start
startadr3 long @@@start

r0      long  0
        fit 496

'####################### COG3 #########################################################

        org     0
        nop
        nop
        nop
        nop
start
        mov r0,#$00 'clear screen command
        wrbyte r0,#5

From the listing:

...
0028(0004) 04 00 00 00 | startadr0 long start
002C(0005) 3C 00 00 00 | startadr1 long @start
0030(0006) 00 00 00 00 | startadr2 long @@start
0034(0007) 4C 00 00 00 | startadr3 long @@@start
0038(0008) 00 00 00 00 | r0      long  0
003C(0009)             |         fit 496
003C(0009)             |         org     0
003C(0000) 00 00 00 00 |         nop
0040(0001) 00 00 00 00 |         nop
0044(0002) 00 00 00 00 |         nop
0048(0003) 00 00 00 00 |         nop
004C(0004)             | start
004C(0004) 00 10 FC A0 |         mov r0,#$00 'clear screen command
0050(0005) 05 10 7C 00 |         wrbyte r0,#5
...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

BradC · 2009-07-02 10:27

heater said...

Using @@ results in startaddr2 being zero.

So what is happening in the @@ case?

That's a bug in the compiler. It's fixed in the latest version (which with any luck will be released tomorrow - I'm running all my validation checks at the moment). Ale picked it up a while back. @@ is not valid in anything other than a SPIN block.

The other thing I'd forgotten about is @@@ is actually valid spin. Not at all useful, but valid. The Parallax compiler parses and generates code from it. It treats it as @@ @ together.

Has anyone actually used the @@@ operator in anything useful?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Missed it by ->" "<- that much!

Post Edited (BradC) : 7/2/2009 10:33:22 AM GMT

Chris Micro · 2009-07-02 12:23

>The other thing I'd forgotten about is @@@ is actually valid spin. Not at all useful, but valid. The Parallax compiler parses and generates code from it. It treats it as @@ @ together.

Now I'm confused: You mean the spin tool and your bstc gives the same result for @@@?

heater · 2009-07-02 13:24

Chris: Presumably in the Spin tool it treats it as as single @ operating on something. Which compiles to an address value that will sit in the code somewhere. Then it applies @@ to that address producing a not useful "address of an address of something".

So, no, not the same as @@@ in BSTC.

BradC: Actually I was contemplating replacing some Spin code that sets up some pointers in ZiCog/MoCog with @@@ the other day.
I decided against it thinking that maybe someone somewhere might want to remove the #defines etc we now have and compile in the Prop Tool again.

Then again @@@ might still be useful if it is desired to compile a Spin free version of the PASM modules.

Then again I could put more ifdefs around use of @@@.....

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Chris Micro · 2009-07-02 13:34

>I decided against it thinking that maybe someone somewhere might want to remove the #defines etc we now have and compile in the Prop Tool again.

That is the reason, why I asked if it is compatible. I made the test.spin file for the emulator with BSTC but in my opinion it is useful if people can use the standard Prop Tool.

The emulator can be started in the linux console with

./propsim.out

it then loads the file "test.binary" and executes the code. No installation is needed.

I created test.binary with BSTC and it is useful to have the @@@ operator. I don't like the version with the +$10 bytes because it is limited to the top object.

heater · 2009-07-02 13:55

Chris: "I don't like the version with the +$10 bytes because it is limited to the top object."

Quite right to. One should avoid "magic numbers" as much as possible when programming. There is a solution to this, instead of using +$10

1. Declare a variable in DAT that will hold the objects base address

object_base long 0-0 'HUB address of this object

2. Initialize it in Spin with this magic phrase:

object_base := @@0 'Set up the base address of this object

3. Declare your pointer(s) in DAT section (Which point to HUB data) with the @

dispatch_tab_addr long @dispatch_table

3. Add object_base to those pointers:

add dispatch_tab_addr, object_base 'Fixup this object offset to HUB real address

Could do that last step in Spin before starting the PASM I guess.

I have used this in old versions of the 8080 emulator. Not sure I can fathom why it works or remember who suggested it.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

heater · 2009-07-02 13:56

P.S. Above solution works for non-top level objects as well.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Ale · 2009-07-02 18:30

I used @@@ in one my thesis' projects. But I could have left +16 because it is just one big assembler file, i.e. no "objects".

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL
OMU for the pPropQL/020 propeller.wikispaces.com/OMU

mpark · 2009-07-02 18:35

heater said...
...
Could do that last step in Spin before starting the PASM I guess.

You're already doing half the fixup in Spin; why not just do the whole thing in one step:

PUB blah...
  dispatch_tab_addr := @dispatch_table
...launch PASM code...

DAT
...
dispatch_tab_addr long 0-0 ' dummy value to be filled in by Spin at run time
...
dispatch_table

rokicki · 2009-07-02 18:45

There's one small gotcha here. If you do this routine *twice* (launching two cogs), they will probably both end
up getting the parameter value of the second one, because launching a cog is asynchronous to the execution
of the spin interpreter.

Chris Micro · 2009-07-02 19:11

And there is a proplem with the

dispatch_tab_addr := @dispatch_table

my Emulator has no Spin interpreter yet. I would need a spin.binary.
And I don't know to which address I should set PAR for the first calling of the interpreter.

heater · 2009-07-02 20:03

mpark: Yes indeed and the newer ZiCog emulator does it that way.

Not sure now why the old PropAltair does it the long way except that PropAltair used a lot of little LMM routines and I fixed up their start addresses in one place dynamically in PASM rather than with a whole list of Spin assignments.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

using coginit in assembler

Comments