Methods in Spin can have local variable like i, f and p here:
PRI _read | i, f, p
They ARE ephemeral in the same way as in C. They live on the stack and are gone when the method returns. so it is probably not a good idea to pass the addresses of them to cognew and such.
Be aware that:
1) Variable defined in a VAR section get replicated if you have multiple instances of the object. i.e. it is used in multiple OBJ statement in your program. In this way they are like members of a class in C++.
2) Variables defined in a DAT section only exist once for all instances of the object. All instances of the object will share them. In this way they are like "static" members of a C++ class.
3) BYTEs, WORDs, and LONGs in a VAR section get rearranged in memory by the compiler, all LONGS first then all WORD's then all BYTES. This is not so for DAT variables.
Recently I have been coding in both Spin and C on the Prop, like you I get myself in the "wrong mode" from time to time. For example I might find myself writing in Spin:
repeat for i = 1 to 10
{
'Do something here
}
And will take me 10 minutes to realize why nothing happens:)
Suggestion:
As you said already, keep a copy of all the little things that trip you up as you go along. Keep a copy of all the advice you get in responses here.
You are in the ideal position to collect a lot of "gotchas" that the more experienced don't think much about any more. Perfect material to an introduction to Prop and PASM document or even just as additional material for such existing documents.
This is absolutely another Heater classic for the compilation. Every detail of what you wrote seems essential. I suspect I would have fallen into the pipe-declared local variable pit this very morning. It might have been a spell before I dug myself out - or someone had to dig me out. It serves as a caution that there is much more to learn.
The C in SPIN mistake was the funniest thing I've come across in a while. LOL doesn't do it justice, and ROFL isn't true - I stayed in my chair. But I'm still smiling over it. I'd share it with family but they would miss the the nuance.
I'll take your suggestion, and I'm very grateful for your help!
And do NOT read it again after three years: you will be ashamed.
Three years? I'm already ashamed of what I wrote three *days* ago.
As an example, there is nothing wrong with page 178 in the Propeller Manual. In fact, if I had any criticism of the manual at all it would be that it attempts to separate SPIN from ASM. They are intertwined on the Prop.
The sole ASM coding example in the book (pg. 339) completely ignores the involvement of SPIN that exists in virtually every ASM application in the real world. Where are the documented examples to help the hapless student? Instead of selecting an example that excludes all SPIN content possible, imho they should have chosen an example that specifically illustrates and documents several forms of interaction between SPIN and ASM.
I wish they would make available such an example, with appropriate comments and description, Monday!!! Honestly, how many man-hours would it take? One?
I say 'Monday' simply because it makes no sense to wait until Tuesday. Or next year. Or 'someday'.
Well, for what it's worth, I'm doing a SPIN to PASM example.
It's a simple task, done in SPIN, using DAT storage for variables, where a PASM program picks those up, and does the same task on a different pin, if desired. Most of the key ideas are there, and can be expanded on, or one could go look at other code and understand what's happening. That's the plan anyway.
This is needed, and will be incorporated into my beginner document, and maybe will fill the gap between that, and the more advanced examples that are laying around all over the place.
I won't promise the best form, but if one can have that argument, the problem has moved past the initial barrier of learning, IMHO.
Well, for what it's worth, I'm doing a SPIN to PASM example.
This is needed, and will be incorporated into my beginner document, and maybe will fill the gap between that and the more advanced examples that are laying around all over the place.
It's true that there are more advanced examples laying around all over the place. Some of them would be excellent objects of study along the path to learning. Mostly what they are missing are the comments and the explanations. Understandably so. When Cam Thompson wrote Float32, it wasn't for the purpose of instructing initiates in the fine art of PASM programming.
Yet a detailed explanation of each step of what Cam is doing - at least in CON, VAR, the first three PUBS, and the relevant lines in DAT - might indeed be the Rosetta Stone for a newcomer to PASM.
The various interactions of SPIN and ASM are subtle. There's no blinking neon sign announcing what's going on. At first glance, there's no apparent interaction whatsoever. I guess that's what threw me - the quiet unannounced subtleties. The legerdemain. A neon sign here and there might have been just the ticket. Your proposed example sounds like a perfect addition to the beginners guide.
EDIT: Belated realization... PASM, per se, never was the problem. For those who have seen assembly language before, the Prop is no big deal. It has its share of quirks, but every processor does. I had little trouble converting C algorithms to PASM, right off the bat, with the only problem being one of inconsistency in the nomenclature, which kuroneko pointed out could have been avoided if I'd just looked at the data sheet instead of the prop manual.
The problem all along, it turns out, was the invisible SPIN/PASM interface. I've been fighting a war of major misunderstandings. There's still some sporadic gunfire but most of the commotion has died down.
"At first glance, there's no apparent interaction whatsoever. I guess that's what threw me - the quiet unannounced subtleties."
Yes! That is a difficult area. It turns out, the chip is full of these things. When you reach a point where you might be interested in the LMM efforts, the ways in which SPIN + PASM can be mixed are pretty amazing. LMM itself is very cool, and something I think we as a user community are still getting to the top of. I'm happy in just PASM land, and am watching with great interest. We've some real talent here, that's for sure! I think that kind of thing rubs off, and so it's all good.
Where I found I have trouble is dealing with pointers, synchronizing tasks, and knowing that something is actually doing what I think it is. When doing SPIN + PASM, it's hard sometimes because several things must align before the good stuff happens, or one even gets feed back.
That's particularly true of video, which I've been jamming on since I found the chip.
A scope for debug, along with factoring the project into small pieces, each to be vetted and encapsulated, so that others can be built on top of, or around them is essential.
In that example, that is what I am doing right now. Got the SPIN running nicely. On the way through to translating to PASM, I've a few bumps, one being math, the other being whether or not the core task (making simple sounds by toggling a pin) is actually doing what I think it is.
So, I'll use the SPIN to setup everything but that task, then hand it all off to a COG running PASM. Then, one by one, I'll peel back the onion, until PASM is doing all of it.
BTW: That example has a metric ton of comments. I've seen what Kye is doing, and have read the feed back you and others have tossed in, and am commenting big.
Honestly, that helps me as much as it might anyone else. Good call there.
When it's working and the docs are done, I'll post it up here. Might not be on your time line, but know I was influenced by your comments here. It's great feed back.
Rest assured that I'll study it and benefit from it. I'm excited, too, about its prospects of helping others yet to come.
A big amen to your comments about the talent here and the positive influence it is. Sometimes, all I can do is just shake my head in wonder...wondering among other things whether I'll ever know half as much.
"...it's hard sometimes because several things must align before the good stuff happens, or one even gets feed back... A scope for debug, along with factoring the project into small pieces, each to be vetted and encapsulated, so that others can be built on top of, or around them is essential."
I excerpted that piece simply because I believe it completely. It's true of complex embedded projects with conventional chips, and it must especially be true of the Prop. With eight processors, two languages, who-knows-how-many threads - and no JTAG - you've got a recipe for disaster otherwise.
Thanks for the mention of LMM. It sounds like a great thing to grok eventually.
Edit: Do you mean to say that you would create a series of related examples, with Spin doing most things in the first example and ASM doing practically everything in the last? I think that is a FANTASTIC idea! To my knowledge, there's nothing like that in the whole Propeller world, and it seems like the perfect way to knock down perhaps the biggest barricade to Prop understanding.
I like your choice of sound, too. Maybe it's just my simmering odium for insipid Blinky (because of what it could have been but wasn't), but sound is a whole lot more attention-grabbing and intriguing to the beginner than a blinking LED, imho. And all it takes is any old speaker (w/possibly a resistor and capacitor) or a ubiquitous cheapy piezo transducer.
I haven't delved into PASM yet but I have been reading the reference manual.
It sure looks different from the assembly language I used for MSDOS 5.1!
Some tutorials would really be helpful...
I believe i have such tutorials from '07-'08 archived on my tower PC (on laptop @ the moment). I will post back later tonight with some attatchment files &/OR a link to the tutorial files on my website. The tutorials were done by a brilliant german professor, he actually wrote a book on the tutorials, and he was in the process of translating it to english.. not sure what ever came of him or his english tutorial book on pasm.
I followed a few pasm tutorials when they were posted, imho, pasm seems fairly straight forward, and even makes more sense than spin to me in some instances.
The problem all along, it turns out, was the invisible SPIN/PASM interface.
potatohead:
...it's hard sometimes because several things must align before the good stuff happens...
K2, I've been thinking about your problems here. I just realized that pretty much all systems have that "invisible" connection between high level languages and their assembly language.
For example, let's say you have some regular processor, Intel, ARM or whatever and you have written a program in C for it. Let's say that you have a function called from C that is actually written in assembler and it gets passed some parameters on the stack.
Well the problem is: When you write that assembler function where are you going to find those parameters, in registers, on the stack(what offsets)? Which order will they be in? Do they comply to some memory alignment rules? How should you access them? How/where should you return the results, push to stack or in a register, which register?
At this point you have to know how your C compiler is passing parameters to functions so that you find them on the stack and how it returns results. When you compile, assemble and link all this there will be no errors or warnings that you are using the wrong stack offsets in your assembler code. It will just fail at run time.
I have had this problem many times, in CORAL 66, PL/M, ADA, C, C++ and others.
Often the advice in the manuals is to write you assembler function in C, say, first. Compile it and then inspect the assembler code produced. Use that compiler generated code as the calling interface when creating your assembler function.
Now with Spin and a Cog task in PASM we actually have the advantage here. They are sharing data through memory. The position and layout of that data is entirely under our control.
Heater, that's one of the things I really like about SPIN + PASM.
Whatever scheme one thinks of, is the scheme by which the two interact. Of course, that's good and bad. It's good, because the number of things one needs to know goes down, but it's bad in that a bad scheme is ...well just bad, and will cause other problems later on, where something pre-cooked is simply there, but one has to know about it.
@K2 --> It's actually the exact same task done by both.
Where I'm at right now, is I have a little SPIN program that makes sounds, based on some pitch and time delays found in a table. It reads the table, loops to make the sounds, and it does the basic pin setup. No counters or waitvid, just a simple loop. It's nothing fancy either. It just makes beeps that have numbers associated with them, and units of time.
In the same file, there is a PASM program that reads the same values, then does the same work, with many of the SPIN statements appearing in the PASM comments. When it's all done, I may present it as two files as well. I don't know.
Interestingly, I set to work on completing it yesterday, and the PASM blorked. (I think the PASM math I've attempted is at fault actually --thought I had dealt with that) So, I will be peeling back the onlon, starting with a very small PASM loop that just makes a sound, hard coded. Then I'll have it make sounds based on values in HUB, working up to where the trouble is.
Not sure how to put the text together yet. That comes after building some examples. That I know is absolutely true. Build the code, built it again, break it in to pieces, break it, then write the text
The other thing done is some additional pieces. Right now, the primer takes one through all the very core things needed for PASM. It's really basic. A few things, such as accessing hub memory with a index, addressing COG memory, and test, branch loop, code fragments are needed to support the sound player piece. That's the highlight of where the next revision will go.
What I did originally, was take a classic LED blinker, or pin toggle program, and expand it just slightly, then document all the supporting info needed. My approach is to generally sort the info, being careful to avoid invoking something that references something else, not communicated to the reader. That worked well, but wasn't inclusive enough. The jump from that to other resources isn't user friendly, so I'll go one more layer up.
re: Sound. Yeah, I like bleeps and noises too. I want to keep anything I write very lean, with few dependencies. I don't like the GEAR section, but may leave it, and or put it into an addendum. One great thing about sound is one can also just put a scope on it, and look at the pulses and get all the info out of the text anyway. Someday, if I head down to a particular subject matter, like video, or something, then it won't be as lean, but then again, the reader will know stuff, so it won't matter.
And this: Sometimes, all I can do is just shake my head in wonder...wondering among other things whether I'll ever know half as much.
Well, I have come to a point in my life where this is a binary thing. One either knows enough, or they don't. And one is either smart enough to enjoy this, or not. So, that's only 4 cases, three of which are positive for the hobby, and that's as good as it gets.
And I think having them is a good idea. I also think they are not necessary to learn PASM.
Here's what I've seen in my limited experience:
On one path, we've got the simulator / debugger approach. That person makes the investment in both the core tech (the Propeller), and the add-on sim / debug kits, whatever they are. Having done both of those, they can write code, then pick through it with those tools, fixing things along the way, eventually seeing success.
There is absolutely nothing wrong with this.
On the other path, we've got people who make the investments in the core tech, and in simple understanding of what the instructions do, and how things link together. They write code a bit differently. Instead of just writing it, only to start re-writing it, as they get input from the tools, they learn to factor things into small pieces, and they learn how to manage the number of unknowns they are working with at any one time. Things tend to get built incrementally, and in nice chunks, each chunk sort of making sense. (because it has to)
There is nothing wrong with this either.
For me personally, I don't generally favor tech dependence. That is required enabling technology being a part of using technology. The leaner the better. Why? Because the skills learned are useful no matter what one's particular scenario is. Really, all that is needed is the Propeller, and a suitable computer to interact with it.
The primary reason for this is I've mapped skills onto enabling technology before, only to see it go away, or cost more, or be changed in some way that just chaps my ***. None of those things are good things, because when they occur (and they do occur), the productivity of those skills is put at risk, due to factors not under my control.
So, that's just me. Others vary, of course.
I've watched people, who can consume data about a CPU, think through the problem and generate code, and what I observe is they understand all the elements of the problem completely. Those people, who use other means and methods often don't, and will often use empirical means to get stuff done.
I'm a purist at heart, and so that just breaks down for me on a lot of levels, mostly because I value reason over those other things, because we always have reason. We don't always have other enabling things available to us.
So there you go. That's just how I see things, and what my preferences are.
The first thing I used to do with a new processor was to write my own monitor/debugger, sometimes in machine code if I didn't have an assembler. The program always started off very simply, but I rapidly got to a point where the program could be used to debug additions to itself. Nowadays I don't bother, as most manufacturers and third-parties provide such tools, but it's still one of the best ways to learn a new chip. The other is to write a simulator for it, or an assembler.
I believe i have such tutorials from '07-'08 written by desilva, archived on my tower PC (on laptop @ the moment). I will post back later tonight with some attatchment files &/OR a link to the tutorial files on my website. The tutorials were done by a brilliant german professor, he actually wrote a book on the tutorials, and he was in the process of translating it to english.. not sure what ever came of him or his english tutorial book on pasm.
I followed a few pasm tutorials when they were posted, imho, pasm seems fairly straight forward, and even makes more sense than spin to me in some instances.
as promised, i found the archive aforementioned. the manuals are posted in the attatchments. one is a modified version. hope these help. theres also a link on the assembly lang links within the software section on the propeller wiki.
Comments
Methods in Spin can have local variable like i, f and p here: They ARE ephemeral in the same way as in C. They live on the stack and are gone when the method returns. so it is probably not a good idea to pass the addresses of them to cognew and such.
Be aware that:
1) Variable defined in a VAR section get replicated if you have multiple instances of the object. i.e. it is used in multiple OBJ statement in your program. In this way they are like members of a class in C++.
2) Variables defined in a DAT section only exist once for all instances of the object. All instances of the object will share them. In this way they are like "static" members of a C++ class.
3) BYTEs, WORDs, and LONGs in a VAR section get rearranged in memory by the compiler, all LONGS first then all WORD's then all BYTES. This is not so for DAT variables.
Recently I have been coding in both Spin and C on the Prop, like you I get myself in the "wrong mode" from time to time. For example I might find myself writing in Spin:
repeat for i = 1 to 10 { 'Do something here }And will take me 10 minutes to realize why nothing happens:)
Suggestion:
As you said already, keep a copy of all the little things that trip you up as you go along. Keep a copy of all the advice you get in responses here.
You are in the ideal position to collect a lot of "gotchas" that the more experienced don't think much about any more. Perfect material to an introduction to Prop and PASM document or even just as additional material for such existing documents.
The C in SPIN mistake was the funniest thing I've come across in a while. LOL doesn't do it justice, and ROFL isn't true - I stayed in my chair. But I'm still smiling over it.
I'll take your suggestion, and I'm very grateful for your help!
Three years? I'm already ashamed of what I wrote three *days* ago.
As an example, there is nothing wrong with page 178 in the Propeller Manual. In fact, if I had any criticism of the manual at all it would be that it attempts to separate SPIN from ASM. They are intertwined on the Prop.
The sole ASM coding example in the book (pg. 339) completely ignores the involvement of SPIN that exists in virtually every ASM application in the real world. Where are the documented examples to help the hapless student? Instead of selecting an example that excludes all SPIN content possible, imho they should have chosen an example that specifically illustrates and documents several forms of interaction between SPIN and ASM.
I wish they would make available such an example, with appropriate comments and description, Monday!!! Honestly, how many man-hours would it take? One?
I say 'Monday' simply because it makes no sense to wait until Tuesday. Or next year. Or 'someday'.
That's how I see it today.
It's a simple task, done in SPIN, using DAT storage for variables, where a PASM program picks those up, and does the same task on a different pin, if desired. Most of the key ideas are there, and can be expanded on, or one could go look at other code and understand what's happening. That's the plan anyway.
This is needed, and will be incorporated into my beginner document, and maybe will fill the gap between that, and the more advanced examples that are laying around all over the place.
I won't promise the best form, but if one can have that argument, the problem has moved past the initial barrier of learning, IMHO.
It's true that there are more advanced examples laying around all over the place. Some of them would be excellent objects of study along the path to learning. Mostly what they are missing are the comments and the explanations. Understandably so. When Cam Thompson wrote Float32, it wasn't for the purpose of instructing initiates in the fine art of PASM programming.
Yet a detailed explanation of each step of what Cam is doing - at least in CON, VAR, the first three PUBS, and the relevant lines in DAT - might indeed be the Rosetta Stone for a newcomer to PASM.
The various interactions of SPIN and ASM are subtle. There's no blinking neon sign announcing what's going on. At first glance, there's no apparent interaction whatsoever. I guess that's what threw me - the quiet unannounced subtleties. The legerdemain. A neon sign here and there might have been just the ticket. Your proposed example sounds like a perfect addition to the beginners guide.
EDIT: Belated realization... PASM, per se, never was the problem. For those who have seen assembly language before, the Prop is no big deal. It has its share of quirks, but every processor does. I had little trouble converting C algorithms to PASM, right off the bat, with the only problem being one of inconsistency in the nomenclature, which kuroneko pointed out could have been avoided if I'd just looked at the data sheet instead of the prop manual.
The problem all along, it turns out, was the invisible SPIN/PASM interface. I've been fighting a war of major misunderstandings. There's still some sporadic gunfire but most of the commotion has died down.
Yes! That is a difficult area. It turns out, the chip is full of these things. When you reach a point where you might be interested in the LMM efforts, the ways in which SPIN + PASM can be mixed are pretty amazing. LMM itself is very cool, and something I think we as a user community are still getting to the top of. I'm happy in just PASM land, and am watching with great interest. We've some real talent here, that's for sure! I think that kind of thing rubs off, and so it's all good.
Where I found I have trouble is dealing with pointers, synchronizing tasks, and knowing that something is actually doing what I think it is. When doing SPIN + PASM, it's hard sometimes because several things must align before the good stuff happens, or one even gets feed back.
That's particularly true of video, which I've been jamming on since I found the chip.
A scope for debug, along with factoring the project into small pieces, each to be vetted and encapsulated, so that others can be built on top of, or around them is essential.
In that example, that is what I am doing right now. Got the SPIN running nicely. On the way through to translating to PASM, I've a few bumps, one being math, the other being whether or not the core task (making simple sounds by toggling a pin) is actually doing what I think it is.
So, I'll use the SPIN to setup everything but that task, then hand it all off to a COG running PASM. Then, one by one, I'll peel back the onion, until PASM is doing all of it.
BTW: That example has a metric ton of comments. I've seen what Kye is doing, and have read the feed back you and others have tossed in, and am commenting big.
Honestly, that helps me as much as it might anyone else. Good call there.
When it's working and the docs are done, I'll post it up here. Might not be on your time line, but know I was influenced by your comments here. It's great feed back.
A big amen to your comments about the talent here and the positive influence it is. Sometimes, all I can do is just shake my head in wonder...wondering among other things whether I'll ever know half as much.
"...it's hard sometimes because several things must align before the good stuff happens, or one even gets feed back... A scope for debug, along with factoring the project into small pieces, each to be vetted and encapsulated, so that others can be built on top of, or around them is essential."
I excerpted that piece simply because I believe it completely. It's true of complex embedded projects with conventional chips, and it must especially be true of the Prop. With eight processors, two languages, who-knows-how-many threads - and no JTAG - you've got a recipe for disaster otherwise.
Thanks for the mention of LMM. It sounds like a great thing to grok eventually.
Edit: Do you mean to say that you would create a series of related examples, with Spin doing most things in the first example and ASM doing practically everything in the last? I think that is a FANTASTIC idea! To my knowledge, there's nothing like that in the whole Propeller world, and it seems like the perfect way to knock down perhaps the biggest barricade to Prop understanding.
I like your choice of sound, too. Maybe it's just my simmering odium for insipid Blinky (because of what it could have been but wasn't), but sound is a whole lot more attention-grabbing and intriguing to the beginner than a blinking LED, imho. And all it takes is any old speaker (w/possibly a resistor and capacitor) or a ubiquitous cheapy piezo transducer.
Brilliant!
I believe i have such tutorials from '07-'08 archived on my tower PC (on laptop @ the moment). I will post back later tonight with some attatchment files &/OR a link to the tutorial files on my website. The tutorials were done by a brilliant german professor, he actually wrote a book on the tutorials, and he was in the process of translating it to english.. not sure what ever came of him or his english tutorial book on pasm.
I followed a few pasm tutorials when they were posted, imho, pasm seems fairly straight forward, and even makes more sense than spin to me in some instances.
potatohead:
K2, I've been thinking about your problems here. I just realized that pretty much all systems have that "invisible" connection between high level languages and their assembly language.
For example, let's say you have some regular processor, Intel, ARM or whatever and you have written a program in C for it. Let's say that you have a function called from C that is actually written in assembler and it gets passed some parameters on the stack.
Well the problem is: When you write that assembler function where are you going to find those parameters, in registers, on the stack(what offsets)? Which order will they be in? Do they comply to some memory alignment rules? How should you access them? How/where should you return the results, push to stack or in a register, which register?
At this point you have to know how your C compiler is passing parameters to functions so that you find them on the stack and how it returns results. When you compile, assemble and link all this there will be no errors or warnings that you are using the wrong stack offsets in your assembler code. It will just fail at run time.
I have had this problem many times, in CORAL 66, PL/M, ADA, C, C++ and others.
Often the advice in the manuals is to write you assembler function in C, say, first. Compile it and then inspect the assembler code produced. Use that compiler generated code as the calling interface when creating your assembler function.
Now with Spin and a Cog task in PASM we actually have the advantage here. They are sharing data through memory. The position and layout of that data is entirely under our control.
Whatever scheme one thinks of, is the scheme by which the two interact. Of course, that's good and bad. It's good, because the number of things one needs to know goes down, but it's bad in that a bad scheme is ...well just bad, and will cause other problems later on, where something pre-cooked is simply there, but one has to know about it.
@K2 --> It's actually the exact same task done by both.
Where I'm at right now, is I have a little SPIN program that makes sounds, based on some pitch and time delays found in a table. It reads the table, loops to make the sounds, and it does the basic pin setup. No counters or waitvid, just a simple loop. It's nothing fancy either. It just makes beeps that have numbers associated with them, and units of time.
In the same file, there is a PASM program that reads the same values, then does the same work, with many of the SPIN statements appearing in the PASM comments. When it's all done, I may present it as two files as well. I don't know.
Interestingly, I set to work on completing it yesterday, and the PASM blorked. (I think the PASM math I've attempted is at fault actually --thought I had dealt with that) So, I will be peeling back the onlon, starting with a very small PASM loop that just makes a sound, hard coded. Then I'll have it make sounds based on values in HUB, working up to where the trouble is.
Not sure how to put the text together yet. That comes after building some examples. That I know is absolutely true. Build the code, built it again, break it in to pieces, break it, then write the text
The other thing done is some additional pieces. Right now, the primer takes one through all the very core things needed for PASM. It's really basic. A few things, such as accessing hub memory with a index, addressing COG memory, and test, branch loop, code fragments are needed to support the sound player piece. That's the highlight of where the next revision will go.
What I did originally, was take a classic LED blinker, or pin toggle program, and expand it just slightly, then document all the supporting info needed. My approach is to generally sort the info, being careful to avoid invoking something that references something else, not communicated to the reader. That worked well, but wasn't inclusive enough. The jump from that to other resources isn't user friendly, so I'll go one more layer up.
re: Sound. Yeah, I like bleeps and noises too.
And this: Sometimes, all I can do is just shake my head in wonder...wondering among other things whether I'll ever know half as much.
Well, I have come to a point in my life where this is a binary thing. One either knows enough, or they don't. And one is either smart enough to enjoy this, or not. So, that's only 4 cases, three of which are positive for the hobby, and that's as good as it gets.
And I think having them is a good idea. I also think they are not necessary to learn PASM.
Here's what I've seen in my limited experience:
On one path, we've got the simulator / debugger approach. That person makes the investment in both the core tech (the Propeller), and the add-on sim / debug kits, whatever they are. Having done both of those, they can write code, then pick through it with those tools, fixing things along the way, eventually seeing success.
There is absolutely nothing wrong with this.
On the other path, we've got people who make the investments in the core tech, and in simple understanding of what the instructions do, and how things link together. They write code a bit differently. Instead of just writing it, only to start re-writing it, as they get input from the tools, they learn to factor things into small pieces, and they learn how to manage the number of unknowns they are working with at any one time. Things tend to get built incrementally, and in nice chunks, each chunk sort of making sense. (because it has to)
There is nothing wrong with this either.
For me personally, I don't generally favor tech dependence. That is required enabling technology being a part of using technology. The leaner the better. Why? Because the skills learned are useful no matter what one's particular scenario is. Really, all that is needed is the Propeller, and a suitable computer to interact with it.
The primary reason for this is I've mapped skills onto enabling technology before, only to see it go away, or cost more, or be changed in some way that just chaps my ***. None of those things are good things, because when they occur (and they do occur), the productivity of those skills is put at risk, due to factors not under my control.
So, that's just me. Others vary, of course.
I've watched people, who can consume data about a CPU, think through the problem and generate code, and what I observe is they understand all the elements of the problem completely. Those people, who use other means and methods often don't, and will often use empirical means to get stuff done.
I'm a purist at heart, and so that just breaks down for me on a lot of levels, mostly because I value reason over those other things, because we always have reason. We don't always have other enabling things available to us.
So there you go. That's just how I see things, and what my preferences are.
as promised, i found the archive aforementioned. the manuals are posted in the attatchments. one is a modified version. hope these help. theres also a link on the assembly lang links within the software section on the propeller wiki.