Is there a limit to local longs? Strange behavior when I initialize some local longs.

turbosupra · 2012-03-14 07:26

I have code with a bunch of local longs and I was testing to see if there was a limit to that.

When I do not comment out some of the initializations of the local longs, it appears that it hoses the repeat loop or maybe its timing.

When I comment out lines 189-197, the loop then works. Can anyone please explain why this is occurring for my own learning? I have pin 4 feeding pin 5 through a 100ohm resistor.

I can't attach the code to the forum because of the work firewall, but I can place it here. As a warning, the code is not cleaned up, things are commented out everywhere and normally I would try and clean it up a bit, but since this is such an oddball issue, I wanted to present it as is.

http://turbosupra.herobo.com/hosting/seq.zip

Thanks for reading.

Duane Degn · 2012-03-14 07:33

I haven't looked at the code yet, but do you know local longs need to be initialized to zero? They will start with some random number if not initialized. Only "result" starts out zero.

Duane Degn · 2012-03-14 07:35

I'm getting a directory error when I try to extract the file.

[SIZE=2][FONT=arial]Caution: Zip file comment truncated.
Error: central directory not found.
[/FONT][/SIZE]

MagIO2 · 2012-03-14 07:49

Local longs are placed on the stack. So, if your stack is to small you should expect any kind of problems.
Potentially there might also be a limit, as SPIN might use a byte offset for referencing local variables?! Not sure if I remember having heared something like that ;o)

But in general it's a bad idea to code the propeller in the same way that you'd code a PC. Using to many local variables should simply be avoided.

Can't access your ZIP file because of firewall settings here. Your hoster seems to be on our "NoNo"-list ;o)

@Duane:
Why do they have to be initialized to zero? What if zero does not make sense? Hopefully it can be reassigned to other values after initialization! ;oP

Duane Degn · 2012-03-14 07:54

MagIO2 wrote: »

Using to many local variables should simply be avoided.

I agree. They also don't show up as using the correct amount of memory when you press "F8".

idbruce · 2012-03-14 07:54

I haven't looked at the code yet, but do you know local longs need to be initialized to zero? They will start with some random number if not initialized. Only "result" starts out zero.

I did not know that. Now I will have to recheck all my source for errors. What a bummer.

MagIO2 · 2012-03-14 08:02

idbruce wrote: »

I did not know that. Now I will have to recheck all my source for errors. What a bummer.

I think that's common to most kind of stacks. It's only that other compilers will give you at least a warning that your variable has not been initialized. But I think this is a kind of a problem you would not be aware of even if it's describes somewhere in the manual. Some things you have to find out the hard way ;o)

Duane Degn · 2012-03-14 08:02

MagIO2 wrote: »

@Duane:
Why do they have to be initialized to zero? What if zero does not make sense? Hopefully it can be reassigned to other values after initialization! ;oP

;oP ;oP ;oP

As you know, when the "not initilized" thing is a problem it's because the programmer is expecting the values to equal zero as global variables do.

And yes, they can be initialized to anything you want (as long as it fits in a long). Germans!!

I think I should be the only one allowed to purposefully misinterpret a post.

idbruce · 2012-03-14 08:08

MagIO2

Before making my post, I checked the Propeller Manual for PUB, and sure enough it stated that local variables had a random value.

I normally initialize locals with values, but I may have taken it for granted in a few instances.

Bruce

idbruce · 2012-03-14 08:14

Duane

I am not sure whether to thank you or curse you for that info.

I think I will thank you.

Bruce

turbosupra · 2012-03-14 08:29

Eh ... I'm getting that error too now.

Can I email it to you instead?

Duane Degn wrote: »
I'm getting a directory error when I try to extract the file.
[SIZE=2][FONT=arial]Caution: Zip file comment truncated.
Error: central directory not found.
[/FONT][/SIZE]

Duane Degn · 2012-03-14 08:44

turbosupra wrote: »

Eh ... I'm getting that error too now.

Can I email it to you instead?

You can and then I'll post it for you.

My email is my first initial followed by my last name (five letters total so far) at abreviation for Micro Soft Network dot com.

turbosupra · 2012-03-14 09:00

Thanks everyone for the replies.

I have increased the stack size of the other cog calls and because they weren't related to the main cog that didn't make a difference I guess, could it be local cog ram related?

Also, this is in the main cog, so is there a way to hard code the amount of stack size for that?

Rayman · 2012-03-14 09:08

I thought you figured out is was due to the local variables not being initialized...

Duane Degn · 2012-03-14 09:33

turbosupra wrote: »

Thanks everyone for the replies.

I have increased the stack size of the other cog calls and because they weren't related to the main cog that didn't make a difference I guess, could it be local cog ram related?

Also, this is in the main cog, so is there a way to hard code the amount of stack size for that?

The cog ram only has the Spin interpreter in it (unless you're running PASM code). The interpreter runs the code from hub and sets aside "stack" space for that cog in the hub (how could that be confusing?

).

turbosupra · 2012-03-14 09:48

Hi Rayman,

I was initializing all local variables originally. When I started to comment out some of those initializations in "main" before entering the repeat loop in "main", the code started working??? (backwards I know) I spent 6 hours messing around with it yesterday before I even got to that point of figuring that out. Since this is so bassackwards, I had to post about it and find out for my own sanity why this was happening and to avoid it.

It may be because I have so many local variables and if there is a ceiling on that, I would just like to know?

Rayman wrote: »

I thought you figured out is was due to the local variables not being initialized...

turbosupra · 2012-03-14 09:49

Ok, so it isn't cog ram

... could it be the initial cogs stack and that I've exceed the space for that with local variables?

Did you receive my email? I guessed at the abbreviation as msn.com ?

Duane Degn wrote: »

The cog ram only has the Spin interpreter in it (unless you're running PASM code). The interpreter runs the code from hub and sets aside "stack" space for that cog in the hub (how could that be confusing?).

Rayman · 2012-03-14 09:55

Ok, it sounds like you are out of stack space then. Your stack space is overlapping with your code. So, when you initialized it, you erased your code...

Duane Degn · 2012-03-14 10:08

turbosupra wrote: »

Did you receive my email?

Sorry, day job got in the way.

It will be a while before I can look at it.

turbosupra · 2012-03-14 10:10

Ok, that makes sense Rayman. Is there a way to manually set the main cog's stack, so that I can verify this before I covert the local variables to global variables?

turbosupra · 2012-03-14 10:13

No worries, just wanted to make sure I got the address correct.

Thanks for attaching.

Duane Degn wrote: »

Sorry, day job got in the way.

It will be a while before I can look at it.

Duane Degn · 2012-03-14 10:16

I notice the Prop Tool doessn't like to display local variables it they extend past the intial screen.

You might want to break them into several lines like this.

PUB Main | localIndex, localPeriod, localCamPeriod, localCrankPeriod, timeStamp, {
         } currentCam, previousCam1, previousCam2, previousCam3, previousCam4, {
         } previousCam5, previousCam6, trigger1, trigger2, trigger3, currentCrank, {
         } previousCrank1, previousCrank2, previousCrank3, previousCrank4, {
         } previousCrank5, previousCrank6, previous5CrankAverage, elapsedTime, {
         } previousGap, currentGap, toothGap, toothGap1, toothGap2, toothGap3, {
         } toothGap4, toothGap5, toothGap6, previousToothGapAverage, toothGapRpm, {
         } crankToothRpm, previousNum1, previousNum2, previousNum3, previousNum4, {
         } previousNum5, previousNum6, current, previous5average, toothRpm

turbosupra · 2012-03-14 10:24

^ Sweet, I didn't know you could do that, that is a great trick!

The problem still exists after doing that, but that makes readability much much easier.

turbosupra · 2012-03-14 11:01

I just converted them all to global variables and had the same problem, then I converted them all back to local variables, still had the same problem ... commented some of the local variables out and it worked as expected?

So although there may be a local variable limit based on the main cogs stack, I don't believe that was my issue after this testing procedures results

The mystery continues ...

Rayman · 2012-03-14 11:08

Let me ask some usual questions... How my free longs does the compiler say you have? Are you using Graphics.spin?

turbosupra · 2012-03-14 11:22

Hi,

Program - 1023 longs
Variable - 437 longs
Stack/Free - 6728 longs

I am not using graphics.spin

I am using

OBJ
  pst : "Parallax Serial Terminal"
  n : "Numbers"
  fcam : "jm_freqin"
  fcrank : "jm_freqin"
  f : "jm_freqin"

Rayman wrote: »

Let me ask some usual questions... How my free longs does the compiler say you have? Are you using Graphics.spin?

Rayman · 2012-03-14 12:12

You have plenty of free space then... I'd guess you have an error in your code and not a memory issue...

Unless... Are you calling that routine with a lot of local vars recursively?

MagIO2 · 2012-03-14 12:31

The main function running in the initial COG has the whole free HUB-RAM as stack-space. That's what this "Stack/Free - 6728 longs" tries to tell you ;o)

If these things happen when commenting code you maybe have a problem with race conditions. For example several code-pieces running in different COGs use the same variable one has to write the other reads and does calculations with the read value. In these circumstances such problems might occur if the writer code did not run in time.
It could also be related to the cognew which needs some time to start up the code.

Rayman · 2012-03-14 12:34

Sometimes Stack/Free lies though... A lot of people start from Graphics_Demo, which uses a huge amount of undeclared HUB ram at the top of memory...

turbosupra · 2012-03-14 12:40

The psuedocode is

Cog sends frequency out pin 4, jm_freqin reads frequency on pin 5, main cog polls jm_freqin.period method every so often for value and calculates data

This could be the race condition you describe, but would it continually loop over and over, or would it only 0 out in some cases?

Do I need to copy the value before performing calculations on it? How do you eliminate the possibility of a race condition?

MagIO2 wrote: »

The main function running in the initial COG has the whole free HUB-RAM as stack-space. That's what this "Stack/Free - 6728 longs" tries to tell you ;o)

If these things happen when commenting code you maybe have a problem with race conditions. For example several code-pieces running in different COGs use the same variable one has to write the other reads and does calculations with the read value. In these circumstances such problems might occur if the writer code did not run in time.
It could also be related to the cognew which needs some time to start up the code.

MagIO2 · 2012-03-14 15:03

The things going on here are pretty complex. I've spotted the following:

1. You seem to work with timings in several areas of your program. But on the other hand you are very generous with usage of PST. But PST has a buffer of 64 bytes. So, when you extend the number of characters send this will slow down your whole program and the conversions will be done in the COG calling the PST functions anyway. So, I'd suggest to think about a debugger/logger COG which runs independently.

2. Chances are high, that these kind of if-statements don't do what you expect
if(cnt > (timeStamp + (clkfreq/l_updateRateDenominator)))

The problem is that the > operation is working with signed numbers. So, from $0000_0000 - $7fff_ffff it will see a positive number and from $ffff_ffff-$8000_0000 it will see negative numbers. In other words for the > operator $0000_0000 will be bigger than $8000_0000.
If you work with a difference you don't have this problem:
if((cnt-timeStamp) > (clkfreq/l_updateRateDenominator))

Is there a limit to local longs? Strange behavior when I initialize some local longs.

Comments