How to learn Assembly
crgwbr
Posts: 614
Now that I have a break from a couple projects at work, I would like to start learning Assembly. Does anyone know of a good place to start? Currently, I am rather lost, since I am used to high level languages only (python, BASIC, spin, etc). Any help would be appreciated.
Thanks,
Craig
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I would love to change the world, but they won't give me the source code
People say that if you play Microsoft CD's backwards, you hear satanic things, but that's nothing, because if you play them forwards, they install Windows.
I spent a minute looking at my own code by accident. I was thinking "What the heck is this guy doing?"
Thanks,
Craig
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I would love to change the world, but they won't give me the source code
People say that if you play Microsoft CD's backwards, you hear satanic things, but that's nothing, because if you play them forwards, they install Windows.
I spent a minute looking at my own code by accident. I was thinking "What the heck is this guy doing?"
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Parallax Forums - If you're ready to learn, we're ready to help.
1) Go to the Object Exchange, and grab a whole pile of other peoples code.
2) Look at it, and try to understand every single instruction.
3) Write variations of the code you've examined, and see if you can get it working.
... and finally ...
4) Start with a blank page, and write your own program from scratch.
SX/B also spits out a .lst file that shows all your SX/B code and side by side comparison to the compiled SASM code. This really makes it easier to understand the relationship of what·is entailed in a·"High-level" language command and how many lines of SASM code it takes to do the same job.
That way you don't have to start from scratch,·in assembly until your ready too. Then move on to asm with the Propeller with a greater chance of success.
This is one of the reasons I picked the SX, before the Prop.
If you want to explore this a bit further, Download the SX/B compiler and my Test.SXB file. Open it up and then compile it by using·CTRL + A, then launch SXSim and·scroll thru the .lst file and set break points in the check boxes #183 and the next line·in between 202 and·203.
In the "Commands" box hit run. When it stops, then hit "Next BP" (break point) @ the bottom row of SX-Sim. AT the bottom center of the SX Sim use the "CLR" button beside the "Time/us" box, use it and then go back to the "Commands" box and hit Run.
SX-Sim will output exactly how many cycles and the time spent executing the SX/B Shiftin command (140.25us, 561 Cycles @ 4Mhz). Thru SX/B and SXSim you can predict your codes timming.
If you want to see the direct output of your program, look here: SX-Key v3.2.3\Compilers\SXB\Output Files\test.SRC
For trouble shooting: Use CTRL + L to show the .lst file use the .lst file and or SX-Sim or the SX-Key.
Post Edited (Capt. Quirk) : 4/24/2007 5:54:17 AM GMT
Capt. Quirk,
There is a lot of good material on programming the SX, but the SX, like the PICs, is a bit quirky. The Propeller has a much more regular instruction set and few special cases. Even though there's less material on it, I believe it ought to be much easier to learn than the SX.
Can you program in SX/B and SASM?
When I moved to the SX, the learning curve was steep to say the least. Learning an actual microprocessor vrs the a stamp microcomputer is a big step. The lack of SX/B documentation hasn't made it any easier, but at least there is good information for learning assembly.
Regardless of what language you learn, the part books that seem to leave out,·is what are·the·quirks·of the processor?, or what are the programming limitations of the chip? and how to get around them in some sort of plain english.
My impression of the Propeller is that it's 8 SX's strung together on 1 chip, with the same variable limitations, with less documentation, with·up to·4 columns of assembly code.·It all seems a bit daunting. But I do like what I have seen with Spin, except for the lack of documentation.
I brought up these points or my experiences?, because I respect your opinion. Like I said, there are many others on the same path and it makes me wonder if I am on the right path or if it's time for a suit change(lol).
Post Edited (Capt. Quirk) : 4/24/2007 7:13:48 AM GMT
2. Look at how to control which leds flash
3. Look at how to change the flash rate by modifying hub ram values and using rlong in the assembly.
4. Look at how to write data to hub ram with wrlong
The rest comes down to having a go, reading the assembly section of the manual, looking at example programs and brushing up on your binary so you know what a carry bit is!
Assembly is actually very simple when you look at the commands, non of them do very much you just need to learn the slightly perverse way you have to do certain tasks.
A simple but fun project is a great motivator.
Graham
My first major assy routine was an SPI engine. I found that a great place to start, since SPI is well documented, and pretty straightforward. That set the foundation for futher education. I'm now using strictly assembly for all my coding, other than human interfacing (displays, switches, etc...) where I use Spin.
-Parsko
Thanks,
Craig
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I would love to change the world, but they won't give me the source code
People say that if you play Microsoft CD's backwards, you hear satanic things, but that's nothing, because if you play them forwards, they install Windows.
I spent a minute looking at my own code by accident. I was thinking "What the heck is this guy doing?"
The fast track.
1. Use a tutorial, preferably Guenther's
It is thorough and provides complete reference with index.
At one point, I thought I actually found something that was overlooked because I couldn't find it in the Index.
Guenther patiently pointed out that it was listed as a topic in the Table of Contents.
I really don't think I could fathom the Propeller's 32bit·assemby with 8 processors·without having mastered the SX's 8-bit one processor.· Each to his own; passion will get a lot done. After all how many duds did Edison make before he got it right?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"If you want more fiber, eat the package.· Not enough?· Eat the manual."········
Post Edited (Kramer) : 4/24/2007 1:44:42 PM GMT
The multiprocessor part is there in spin as well as assembly and you only really need to know a few things, how to get data in and out of the hub and that this can also be used to signal between cogs. I tried to get parallax to knock up a simple video on these subjects demonstrating program flow but they seem too busy or don't get the idea.
I had never really done any assembly before the propeller although I did look at pics for a while and the actual code seems much more straight forward and the manual more down to earth IF YOU READ IT!
A final thought, even if you don't use gear it is really handy to have a cog running the TV so you can pass variables to the hub ram and display them all nicely formatted for testing, I found that very helpful.
Graham
1. The variable that assembly uses- do you define them in the VAR section, or in the DAT section?
2. Can you call another object from the assembly code? For example, if I put FullDuplexSerial in the OBJ section, can I call the tx, rx, DEC, etc routines from my assembly code?
Thanks,
Craig
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I would love to change the world, but they won't give me the source code
People say that if you play Microsoft CD's backwards, you hear satanic things, but that's nothing, because if you play them forwards, they install Windows.
I spent a minute looking at my own code by accident. I was thinking "What the heck is this guy doing?"
2. no, those routines are all spin
to me, assembly is more useful for drivers than whole applications due to the lack of compile-time absolute address computation
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Parallax Forums - If you're ready to learn, we're ready to help.
It's true that the Propeller has 8 essentially identical processors. For the purpose of learning assembly language, it's best to completely ignore this and just write programs for a single processor. Multi-processor programming requires a whole other set of concepts on top of whatever you're using for programming. It's probably best to start with multiple processors using Spin and extend that to assembly language as you become comfortable with assembly language on a single processor.
''**************************************************************************************** '' Full Blast pin recorder, resolution 150ns (6.66 MHz) ''**************************************************************************************** org GetFast test ftrigger, #1 wz 'test if we have start condition if_nz waitpeq fsstate, fsmask 'wait for start condition :storeloop mov fbufstart, ina 'store pins state add :storeloop, :d_inc 'inc dest in instruction above djnz :i, #:storeloop 'go for next transition :hptr mov :hptr, par 'use this loc as ptr to hub mem mov :i, #CogBufSz2 'reinit counter wrlong :d_inc, :hptr 'write non-zero to signal start add :hptr, #4 'inc hub pointer :writeloop wrlong fbufstart, :hptr 'write long to main memory add :writeloop, :d_inc 'inc buffer pointer add :hptr, #4 'inc hub pointer 1 long djnz :i, #:writeloop 'empty entire buffer cogid :i cogstop :i 'die :d_inc LONG $0000_0200 :i LONG CogBufSz2 fit $1F0 - CogBufSz2 fbufstart 'start of buffer, following variables used before recording ftrigger LONG $0000_0000 'flag for start condition fsmask LONG $0000_0000 'pin mask for start condition fsstate LONG $0000_0000 'pin state for start condition·Ive used a few tricks but we can walk through them. In this installment I will explain the program through the aquisition process (upto the djnz before :hptr).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Post Edited (Paul Baker (Parallax)) : 4/25/2007 6:03:15 AM GMT
I agree with everything above... except of course there is no perfect way to learn assembly... that depends on your learning style. There are a lot of us guys at the same basic level... so ask bunches of simple questions.
I particularly like the advice above, which suggests limiting yourself to one cog at a time... but I personally think you should try to always segment your assembly code into a new cog.
Assembly seems like it was made to run in it's own cog... and when you run it with a bunch of spin code ... the rules change a little. And if you start out segmenting your code in this way, you won't find yourself having to rewrite any code once it is working.
I would suggest studying the forum... using search by Author. Mike Green is very productive... and frequently corrects the mistatements of others. Graham stabler never asks a stupid question and if he makes a statement... you can take it to the bank. But...Graham is an advanced thinker... So, it is sometimes difficult to understand his questions. Chip never wastes a line... same for most of the other Parallax guys.
Rich
I've been looking at the Assembly language for beginners thread, I've also been reading the assembly language reference from the manual and the downloadable book from Parallax (Beginning Assembly for the SX or something like that). I tried using GEAR, I guess I don't really understand how. It's basically a prop simulator, right? CJ, I agree, with your statement that assembly is better for drivers than whole programs. If you could call spin routines from assembly I might think differently. I just don't want to rewrite every spin object I use.
Craig
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I would love to change the world, but they won't give me the source code
People say that if you play Microsoft CD's backwards, you hear satanic things, but that's nothing, because if you play them forwards, they install Windows.
I spent a minute looking at my own code by accident. I was thinking "What the heck is this guy doing?"
I've been doing pretty much the same thing...
I'm convinced that you can call spin routines from assembly... and across a network of props. Exactly what the limitations are and what that might do to performance is beyond me right now...
But if you can pass parameters...which you can... then you use those parameters to call Spin routines. I haven't done it yet... because I have too many other things that I need learn to do first.
Rich
To really learn Assembly, you have to commit to completely learning a particular microprocessor with all its quirks.
Currently, not enough is really published about the Propeller.
The beauty of learning with the SXes is that they are extremely adaptible [noparse][[/noparse]with virtual peripherals], thoroughly presented in a good tutorial and learner's kit, and similar to the Propeller in architecture.
PICs are not very good because there are so many different kinds, AVRs have hardware peripherals, 8051's are quite different in memory management, and older microprocessor require an array of support chips that are hard to find.
Once, you have mastered Assembly in depth on one platform, the knowledge is transferable and you can infer a lot.
But, since the Propeller currently lacks a full rigourous tutorial - you run the risk of getting completely lost. We really don't want you to be disappointed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"If you want more fiber, eat the package.· Not enough?· Eat the manual."········
Post Edited (Kramer) : 4/25/2007 9:58:28 AM GMT
I see your hesitation, and that you seem to be intimidated. I promise you that these feelings will go away once you perform step one of Grahams suggestion, blinking an LED.
I started with ucontrollers only 2 years ago. I only had a small class in basic before that. Until I bought a Propeller last year, I didn't have ANY assembly experience. I too, was EXTREMELY intimidated, and I mean EXTREMELY!!! I thought that assembly was like trying to learn Dutch (and trust me on this one, it's the hardest spoken language to learn!!!)
I approached it with baby steps in mind, knowing that my knowledge and experience would build upon itself. If you start with a project that simply resides within one cog, that does not rely on passing parameters to a SPIN cog (this simple project being a blinking LED, for instance), you will be rewarded with extreme amounts of confidence that will give you the courage to try something more complex.
As I suggested before, pick a simple driver to code (SPI, I would not reccomend I2C, it has too many "what if this fault occurs" types of requirements) and have at it. Make sure you do it YOUR way, don't try to rewrite someone elses code. Think through it, and learn the commands.
In only the last week have I grasped the MUX commands!!! After a year of avoiding them, I finally told myself to think about them and how to implement them. I ended up chopping my original Assembly project (the same SPI driver mentioned above!) down to, what appears to me, to be some lean mean code that I can call from any spin or assy cog. This only happened because I started with a goal ("you're gonna write an SPI driver, Luke!") and had this forum to help. Man, I think back at the STUPID questions I asked this forum less than a year ago...
-Parsko
PS - An example of one of my "stupid" questions I had about a year ago[noparse][[/noparse]url]
Post Edited (parsko) : 4/25/2007 10:06:20 AM GMT
Assembly is used when you need speed, generally the cog will be doing one thing really fast. The assembly won't be calling the spin the spin will and it will be feeding data from and to the assembly. Think of the mouse driver, your main program may be in spin allowing full access to all the functions required but the mouse is running in assembly in its own cog.
That does not mean that the two cannot talk to each other, if the assembly wants the main program to do something it could set a variable in the hub ram to a certain value, the main spin program might monitor that value and on seeing that do something by running a spin function, that might calculate something and write the answer to the main ram. The spin program could then reset the variable originally used to communicate to tell the assembly that the operation is complete and the data is available in hub ram.
Please follow my 4 step plan, don't worry about gear until you get going and don't worry about the specifics of the programs you eventually hope to write, once you get some basic skills all will fall into place.
Graham
p.s. I nearly said I would write some real beginners examples just then but I might not have time, though I may try. I think the assembly for beginners thread starts a little too high up the food chain.
Craig
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I would love to change the world, but they won't give me the source code
People say that if you play Microsoft CD's backwards, you hear satanic things, but that's nothing, because if you play them forwards, they install Windows.
I spent a minute looking at my own code by accident. I was thinking "What the heck is this guy doing?"
But seriously you have to get to a point where you know what you don't know before more sensible questions emerge.
Graham
On the 4 step plan to Assembly Language enlightenment, I strongly agree with this. It's worked with every micro I've ever written assembly for. This one is really different though. I'm finding myself going back to the basics! (and that's just fun) Have the block diagram out in front of you, nice blank sheet of paper, etc...
Print out the listing, grab all the docs and follow the data flow for each instruction. IMHO, this is very important on the prop as differentiating COG memory from HUB memory is key. Everything runs on the COG, but it all starts from HUB memory. When a COG is started from either SPIN or assembly, it's memory is filled from from the HUB. Once that is all done, then the thing starts with your instructions.
I find it very helpful to track the flow of data. On every micro, there is a sequence that happens at boot time that gets you to the program you are looking at understanding, or writing. Groking this in simple terms, helps put things into context, which in turn, helps give the addressing in the instructions meaning.
In simple terms, visualize all your data loaded into the prop from the prop tool, or the EEPROM, on power up or F10. The 32K contains everything and the COGs are empty. Cog 0 then gets loaded with the SPIN interpeter and begins interpeting the SPIN program in HUB memory. At some point, that SPIN program will launch a COG, that's gonna be running assembly language instructions. These instructions exist in the HUB memory, in sequence ready to be copied into the 2K of COG memory. That's your DAT statement in SPIN!
At launch, the whole COG is filled from the HUB, then it starts running on it's own. Nothing runs in the HUB. It's just storage. SPIN programs exist there, but are interpeted by an assembly language program running on a COG, or COGs.
That's where your assembly program begins.
At that point, everything is in the COG, but for the HUB memory access instructions!
Within that COG, every instruction is 4 bytes long, meaning a COG can hold 512 longs worth of instructions and or data. The difference between the two really comes down to how the program is written. And that's where a lot of the study is, for this micro. Some instructions change others, to index tables of data, or change branch points!
IMHO, the example Paul posted is a really good one. It features access to the hub, has nice simple loops and shows off the addressing and how that impacts the code.
Post Edited (potatohead) : 4/25/2007 4:55:00 PM GMT
Below is the portion of code that hasn't been walked through yet:
:hptr mov :hptr, par 'use this loc as ptr to hub mem mov :i, #CogBufSz2 'reinit counter wrlong :d_inc, :hptr 'write non-zero to signal start add :hptr, #4 'inc hub pointer :writeloop wrlong fbufstart, :hptr 'write long to main memory add :writeloop, :d_inc 'inc buffer pointer add :hptr, #4 'inc hub pointer 1 long djnz :i, #:writeloop 'empty entire buffer cogid :i cogstop :i 'die :d_inc LONG $0000_0200 :i LONG CogBufSz2 fit $1F0 - CogBufSz2 fbufstart 'start of buffer, following variables used before recording▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
I don't normally spend any time in this forum and have no experience with the Prop. Other than Mikes explanation of uC's I think most of us are just pitching for our favorites. I would really like to·here something more definitve from·Paul, since he used to be a major contributor to the SX Forums.
I'm ending up at a similar model.· When figuring out what goes where, it's excellent.· Breaks down a little with the pins though...
·