How do you read the object info screen? (how to proactively calculate PASM code size)

turbosupra · 2012-07-07 09:03

I started having my PASM fit command tell me that I had exceeded 492 longs, so now I'm trying to trim out the waste in my code.

I'm wondering how I read this object info window and if I can reconcile it to just the PASM code? Is there a way to move the output of the fit command so that I can print it to the PST?

Thanks for reading.

msrobots · 2012-07-07 13:26

Hi Turbosupra,

I usually comment out a couple of lines until it compiles again - then I now how much longs I need and start optimizing the code then.

Another pretty unknown feature of the prop-tool is that after compiling and before you change any code again you can click on any PUB/PRI/DAT section and constants./ labels and get the size or value displayed on the status-line on the bottom of the screen.

Enjoy!

Mike

JonnyMac · 2012-07-07 13:32

You can't use the window, but after you compile when you click in any PUB, PRI, or DAT area the size used is displayed in the info bar at the bottom of the screen.

turbosupra · 2012-07-07 13:36

Hi msrobots and thanks for the reply. I would like to know the current size of my program so that I can monitor it before I approach the fit limit, is this possible.

I clicked on my PASM section and it said 1836 bytes, strange that it is listed in bytes for cog ram if this is indeed a representation of cog ram. If it is, it does give me a way to monitor my cog size before I exceed my limit. I have fit 492, so that would mean I exceed the limit at 1968 bytes if my assumptions about this are correct.

turbosupra · 2012-07-07 13:38

Hi Jon,

So fit 492 means 1968 bytes and if I click on the DAT section as you've both shown me, I can compare that number (in bytes strangely enough) to 492 longs/1968 bytes?

Duane Degn · 2012-07-07 13:42

The compiler doesn't know much about how you intend to use the PASM code. It just loads 492 longs after your entery label.

You can use smaller numbers after "fit" to see how much room you have left when the code is loaded to the cog.

Try "fit 250", which will cause an error if your code is longer that 250 longs since the last "org" statement. By adjusting the number up or down, you can figure out the size of your PASM code.

Any variables defined using "res" wont take up hub RAM but these do count against you as longs between "org" and "fit".

This is one reason it's hard to figure out your PASM code size using the Prop Tools "F8" feature (at least as far as I know).

turbosupra · 2012-07-07 13:59

Thanks for the reply Duane, is there a better way then the F8 feature or the fit trial and error feature?

msrobots · 2012-07-07 14:17

Hi Turbosupra -

no better way. But without using res and using a simple label with a long you can use F8 and you are right it is in bytes.

Enjoy!

Mike

msrobots · 2012-07-07 14:37

Ha

you can put your PASM in a separate OBJ and provide a Method to give you the Adress of that block. So you still can start your cognew in the main programm.

instead COGNEW(@entry,Parameter) use COGNEW(obj.MyPasm,Parameter)

ooh shoot.

needed to correct that:

instead COGNEW(@entry,Parameter) use COGNEW(obj.MyPasm,Parameter)

is not fully correct

you need to use a variable, I guess or you confuse the compiler

somthing like

myAdr:=obj.MyPasm
COGNEW(myAdr,Parameter)

Then you can see that also on the Info-Screen for that OBJ. (you mentally neede to subtract some constant amount for the PUB method... 3 longs? or so.)

I think that RES then might show up as variable space ... unverified ... I need to try that out.

Example:

PUB MyPasm
RESULT:=@entry

DAT

                org 0
entry       <your pasm here>

Enjoy!

Mike

Duane Degn · 2012-07-07 14:53

Here's another awkward way to do it.

Add the following before your PASM code.

beforePasm              byte 189, 190, 189, 190
                        byte 189, 190, 189, 190
                        byte 189, 190, 189, 190
                        byte 189, 190, 189, 190
                        byte 189, 190, 189, 190
                        byte 189, 190, 189, 190
                        byte 189, 190, 189, 190
                        byte 189, 190, 189, 190
                        org
entry                   mov     dutyPtr1,par                'get first parameter

And the following after the PASM code.

fit
                        
afterPasm               byte 189, 190, 189, 190
                        byte 189, 190, 189, 190
                        byte 189, 190, 189, 190
                        byte 189, 190, 189, 190
                        byte 189, 190, 189, 190
                        byte 189, 190, 189, 190
                        byte 189, 190, 189, 190
                        byte 189, 190, 189, 190

Characters 189 and 190 make up the horizontal resistor symbol in the Prop Tool. Now I just need to find where these reistors are in the hex display.

attachment.php?attachmentid=94023&d=1341697478

attachment.php?attachmentid=94023&d=1341697478

Looking in the far right column for the reistor symbols, I see my PASM starts at $58 and ends at $CB making it ($CB - $57) / 4 = $1D or 29 longs in size. This doesn't include any variables declared using "res" since "res" variables don't take up hub RAM space.

You could of course choose any character you think would be easy to spot in the far right colum.

Did I mention this was an awkward way of finding PASM code size?

msrobots · 2012-07-07 15:00

ooh shoot.

needed to correct that:

instead COGNEW(@entry,Parameter) use COGNEW(obj.MyPasm,Parameter)

is not fully correct

you need to use a variable, I guess or you confuse the compiler

somthing like

myAdr:=obj.MyPasm
COGNEW(myAdr,Parameter)

Enjoy!

Mike

Phil Pilgrim (PhiPi) · 2012-07-07 15:46

Or, more simply:

  cognew((obj.MyPasm), Parameter)

The parentheses turn it into an expression.

-Phil

msrobots · 2012-07-07 16:35

@Phil,

this is nice ... i did not know ... thanks

Enjoy!

Mike

turbosupra · 2012-07-07 16:49

Ok, thanks everyone for your replies, since I cannot move my PASM code to their own objects. Duane, you once told me you were a masochist, I believe this might be another example of that

I copied the code to an empty window and then added pub main as F8 doesn't work without a pub. Here were the results, which I guess are pretty accurate? I'm still trying to understand msrobot's way of doing this with pub mypasm ? I tried it as the following but it didn't work, maybe it only works for entire object sizes?

pub getPasmSize
  result := @camsim

  
    
DAT

                        org     0

camsim

mindrobots · 2012-07-07 19:35

You may want to look at BST (Brad's Spin Tool). The command line compiler (bstc) generates TONS of listing information with the -ls option and you can find where your DAT section starts and what the offset is for everything. I didn't have an example that blew out the end of a COG but it may help you find places you can trim, reuse or recycle code.

msrobots · 2012-07-08 00:15

Turbosupra,

no. you got me wrong. the pub does not give you the PASMSIZE but the PASMADRESS. So you can have the pasm in a seperate obj but still use it in the main object by its adress.

kind of an answer to another question you have asked lately but yet not have solved...

Enjoy!

Mike

turbosupra · 2012-07-08 09:06

Hey guys, I think I figured something out ... maybe how the fit command works.

I noticed that if I use entry (or whatever it is named in your cog new command) and then after the fit command I put exit I can then call the two pub commands and did some math I would get a difference of 1856 bytes, which was the exact same value if I clicked on the dat section like Mike and Jon said to do after compiling.

So to get the long size, I just divided by 4 and got 464, so I started adding variables to see where the limit was, as expected each long I added would add 1 to the getPasmSize value.

I was able to get to 481, when I tried for the 482nd long, I would fail the "fit 492" command that I have at the bottom of my PASM code so there is apparently the fit command accounts for 11 longs that are not between PASM entry and PASM exit, which I then transferred over to my getPasmSize as well.

Now I can programmatically and proactively keep track of my PASM code size

Thanks to everyone who helped, I don't know if I'm the only one who stresses over this, but if not maybe this can help others.

pub getPasmEntry
result := @entry

pub getPasmExit
result := @exit

pub getPasmSize
result := (((@exit - @camsim)/4)+11)

Phil Pilgrim (PhiPi) · 2012-07-08 09:10

turbosupra wrote:

...so there is apparently some sort of overhead of about 11 longs built into the fit command, ...

No, that doesn't sound right.

-Phil

JonnyMac · 2012-07-08 10:59

FIT is a compiler directive, not a Propeller command. It adds no overhead to your code.

turbosupra · 2012-07-08 11:57

I didn't explain very well what I meant to say, apparently the fit command accounts for 11 longs that are not between PASM entry and PASM exit, I don't know what they are used for, maybe someone from Parallax could chime in on that.

Phil Pilgrim (PhiPi) · 2012-07-08 12:02

fit accounts for all longs between DAT or the previous org and the fit directive. There is no overhead. Perhaps you've just counted wrong?

-Phil

turbosupra · 2012-07-08 12:40

Try it yourself with a project you have? The subtraction and division is done by the program so I didn't count wrong there and as much as I'd like to blame it on human error 492-481 is 11.

Since no one else offered this solution though, it would be nice to have a second set of eyes, let me know what you find.

Phil Pilgrim (PhiPi) wrote: »

fit accounts for all longs between DAT or the previous org and the fit directive. There is no overhead. Perhaps you've just counted wrong?

-Phil

Duane Degn · 2012-07-08 12:45

If you place "exit" after fit then "(@exit - @entry) / 4" should give you the number of longs in your PASM section. If "exit" is the the last long before "fit" the you'll need to add one long to make the math come out right.

"(@exit - @entry) / 4" does not include any variables declared with "res".

Are you using the F8 info as your code size? If so, the "PUB" method you had to add has some overhead as well has initialization overhead that isn't part of your PASM code.

The "462 LONGS" value includes this extra overhead but your PASM code doesn't take up 462 longs.

Phil Pilgrim (PhiPi) · 2012-07-08 13:32

Duane's right. If you've got res variables, you can't use the "@" notation to compute PASM size, since that notation refers to hub addresses, and res space does not exist in the hub. However, fit does include res space in its size determination.

-Phil

turbosupra · 2012-07-08 20:20

Haha, good call guys. Guess how many res variables I have?

... Yup you guessed it, 11! The mystery has been solved and I did not know that, so thank you. Is there a way to programmatically count the res variables?

So I guess I have two choices, keep a manual count of the res variables or get rid of the res variables altogether. The res variables I am using are for a math function that I took from the spin compiler, but there is no reason they couldn't be initialized variables. I really can't see the advantage, or maybe I should say I haven't found the advantage to using a cog ram reserved variable over an initialized variable. Maybe it takes up less hub ram space to use res variables instead of an initialized long that has to then be copied over from hub ram to cog ram? Maybe it is purely stylistic?

Phil Pilgrim (PhiPi) · 2012-07-08 20:24

The use of res variables is not merely stylistic. The advantage is that it requires less hub RAM; and, when that space is tight, it matters.

-Phil

Phil Pilgrim (PhiPi) · 2012-07-08 20:35

trubosupra wrote:

Is there a way to programmatically count the res variables?

Yes. In the following example, end is a variable that's initialized with the long size of the PASM code, including the res space:

attachment.php?attachmentid=94065&d=1341805091

attachment.php?attachmentid=94065&d=1341805091

-Phil

Heater. · 2012-07-08 22:06

As mentioned here before, just use BST instead of the Prop Tool.
For example, for the code posted by Phil above BST produces this listing output:

0048(000C)             |     org 0
0048(0000) 00 00 00 00 | begin nop
004C(0001) 00 00 00 00 |       nop
0050(0002)             |       res 7
0050(0009)             |       fit
0050(0009)             | There are 487 ($1E7) Longs left in the cog
0050(0009) 09 00 00 00 | end   long  end - begin

Where it plainly tells you what space is left in the cog. No need for that end - begin business unless you need it at run time of course.

Dave Hein · 2012-07-09 05:46

After you compile a program you can left-click on a label and the Prop Tool will display the object address and cog address at the bottom of the screen. If you want to print out the cog address at run time you could do something like ser.dec(lastlabel), where lastlabel is defined at the end of the PASM program.

turbosupra · 2012-07-09 06:41

Awesome, thanks everyone. This actually helps me tremendously.

Dave Hein · 2012-07-09 12:08

And if you want to print out the size of the cog program at run time you could do something like this:

pub main
. . .
  ser.dec(cog_size)
. . .
dat
. . .
cog_size last_label
. . .
last_label res 1

How do you read the object info screen? (how to proactively calculate PASM code size)

Comments