implicit SPIN variable initialization?
K2
Posts: 693
After wasting spending 20 minutes searching the Propeller manual in vain, I could find no mention of the apparent fact that SPIN variables are initialized to zero if not explicitly initialized to some other value. Where in the lovely manual is this precious detail spelled out?
And if SPIN variables are not automatically zeroed, how is it that numerous ASM examples rely on them to start out with a value of zero?
So many mysteries, so little time.
And if SPIN variables are not automatically zeroed, how is it that numerous ASM examples rely on them to start out with a value of zero?
So many mysteries, so little time.
Comments
Edit: You are correct JonnyMac. There is a discrepancy wrt page numbers among the manuals I have. The manual here (wherever 'here' is) puts RESULT on pg. 194.
Seems it isn't documented as initial scans show (it mentions result being cleared though). That said, one could argue this fact (globals are cleared) can be deduced from looking at the memory map in the Propeller Tool when an object is compiled.
- global variables are cleared to zero
- local variables - with the exception of result - are not
There is one exception for globals. A program could modify the EEPROM location for a specific global variable. When the program is re-loaded (from EEPROM) after a reset, that particular variable will be initialised with whatever was written previously.Editorializing for a second, I would like to point out that both SPIN and its typical usage pattern violate just about every rule in the book for writing legible software. I used to think the rule book was a bit strict. My experiences here have done wonders to convince me of the absolute genius of it.
-Phil
Okay, that was mean. I don't want Ken kicking me off the forum.
But, seriously, I feel like a freaking guinea pig right now. What I can't figure out is whether I fell into a rabbit hole or wandered into the Twilight Zone.
I’m sorry that's wrong, C taught me to initialize variables. It was my mother that said eat your vegetables. Both are good advise.
The content of a DAT section is set as defined (as LONG / WORD / BYTE statements or as assembly instructions). Remember that RES definitions occupy no hub storage.
The download program in the ROM zeroes any of the 1st 32K of EEPROM that's not occupied by the program. The EEPROM loader that I wrote that's part of FemtoBasic and the SD card loader, also part of FemtoBasic, similarly zero the space between the end of the program and the start of the stack area. This includes the space allocated for VARs.
C teaches you to initialise?
Hmm - I just found out the hard way that sbasic does too. Now I'm just doing it for every language. I guess things like "FOR" loops implicity initialise. But not DO and WHILE and REPEAT type loops.
But I'm still not so sure about eating my vegetables.
It's a grave mistake (reading to non-portable code and strange crashes) to think that if one compiler for the language does something, that "something" is a feature of the language and all compilers will do that.
Mike Green, your remarks both puzzle and interest me. So ultimately it is the ROM downloader that zeroes VARs? That is a useful piece of information. I shall tuck it away. Thanks!
BTW, I looked through some of your code a couple days ago and was quite impressed with the pains you took with commenting. Your variable names and function names were expertly chosen, too. My boss would be delighted with your work.
The whole idea is to clarify rather than obfuscate. Following code written by someone else is so vastly easier if everything is spelled out. Many employers insist on it. Magically initialized variables are "right out!" (channeling Monte Python, here)
Because of inconsistencies from one embedded platform to another, I no longer initialize variables when I declare them. Instead I initialize them in the first few lines of code.
Edit: In other words, what Pavel said!
There are other cases, on the Prop for example, where one is up against the 496 long limit and has to economize any way possible, so if there are tricks, take them.
In fine, folks can write their programs any damn way they please unless they are writing them for hire.
My only gripe is that the manufacturer of the Propeller, to my knowledge, has not released a SINGLE program, in FIVE YEARS, that actually illustrates, documents, and explains ANY of this stuff. Blinky. That's it. If it's not illustrated in Blinky, apparently we don't need to know it.
If I'm wrong, if there are instructive example codes that Parallax has provided, I'd love to be shown them. I'd love to be dead wrong on this point.
Personally, I don't particularly need such examples anymore. But as I have come to realize what the Prop is about, I have come to realize how odd the Parallax approach to documentation is. The Propeller Manual IS a lesson manual for the hobbyist. It's too long, it's too verbose, it's too hard to find crucial information, and sometimes the crucial information isn't even there.
If you want to sell chips to the masses, you can't expect every potential customer to exhaustively dissect uncommented assembly code to find undocumented chip features that are critical for its use. It is preposterous!
There are all sorts of documents from the application note on the cog counters to the Propeller Education Kit tutorials that contain well documented sample code. They're not collected together in one omnibus document, but there is a readily available mass of sample code.
If you're looking for an introductory text, you're right, there's not one single introductory text on the Propeller, either Spin or assembly language. There have been several proposals from 3rd parties (experienced authors) that have gotten to different points in development and production, but none of them to my knowledge have made it to publication as of yet.
Anyway, you've proven me wrong! Chapter 5 of "PELabsFunBook" delves into the heart of the matter. AN001 ultimatey gets there, too. And those two examples are quite adequate. In losing, I win.
Perhaps I should create my own pseudo-sticky thread, a la StefanL38, announcing to the world the actual existence of coding examples. Or perhaps as part of the PropTool installation, a separate folder could be created entitled "Useful Examples" or "Documented Examples." Some of us (or maybe I'm alone) just don't have the time, patience, or proper attitude to start a new Grand Adventure, searching out the possible existence of commented and documented code. And even if we (or I) did, the FunBook might be the last place we (or I) would look.
Thank you, Mike.
Words to live by