Learning PASM, Where to start?
lardom
Posts: 1,659
I've learned enough about Pbasic and Spin to be comfortable. I want to learn asm but it will be my biggest step by far. I am a little nervous because are no labs for assembly. I started programming micros in 2009 and I want to know how far I can go . I really surprised myself with what I've been able to do. That said, the thrill doesn't last long so I have to push further.
Where do you start when you want to learn assembly?
Where do you start when you want to learn assembly?
Comments
He is doing an update on it and should soon post
an improved version.
I don't have the link but a search of this forum should find it.
Assembly Language Primer for the Absolute Beginner.pdf by
Doug Dingus (potatohead)
I have an asm blog but not too much is up there just now.
I am waiting for some free time to work on it some more.
http://justasm.blogspot.com/
1. Learning PASM specifically
2. Learning to think creatively in Assembly languge in general.
If you just learn the first without the second, you really are not using the power of assembly language to its fullest.
Regretably, a lot of good texts about assembly language are about using specific processors, like the 8086 and its later generations. These are rather huge books. One begins to feel they will never achieve anything.
I turned ot Gunther's text on using the SXes and was delighted to find it a much shorter course. Though the architecture specific side of his text also hampers creativity in some ways, he provides an excellent presentation and foundation to being an explorer with your own creativity.
The Propeller is unlike the SXes in that it doesn't have storage divided into EEPROM and limited RAM registers. It is actually an easier to manage bit of hardware in that sense (you don't have to switch pages in EEPROM and you don't have to switch banks of RAM addresses - both constants and varibales go into ram), but if you want to be adept at more than the Propeller - just maybe you should learn how to do those things too.
Regardless of the architecture......
Writing things like a generic 'shift in' or 'shift out' in Assembler are very helpful. Creating your own SPI interface (not the more complex and proprietary I2C). Or adding parity to an RS-232 serial interface is a useful exercise. Generating PWM is useful too.
SO I GUESS....
What we need is a list of 'creative exercises' that transfer to any micro-controller. If you can solve all those puzzles, you begin to delve into the power and glory of assembly language programing.
Bean did a lot of creative thinking when he mastered video generation on an SX28. I still haven't done so, but maybe one day soon. ALL things are only complex when you don't understand them\.
Instead, find an existing simple assembly program which already works, run it and see that it works. Then modify just one thing at a time in that program - see what happens!
Start with something simple which blinks an LED or whatever. Try moving the LED to another pin. Get it to blink at a different rate. Try using a binary number like this...
mov dira, #%0_0000_0001
But how does one really get into 'mastering' assembler on any device?
I suspect that when you can recreate all the comands in PBasic, but as assembly language you will be well on your way.
Later when you can writing assembly language in two very different processors, you will pretty much have it all.
In the past, the processors seemed to get more and more complicated as big and better computers came out. Instruction set kept getting larger and larger until people were ignoring 80% of assembler instructions and using the core of 20% for most of the work. Then there was a shift back to small instruction sets, called RISC.
So the Propeller has rather simple, though fast and powerful, processors with a reasonably small instruction set (maybe 70 or so - the SXes have about 40).
Resources are limited, so one can't get too crazy. All you really have is 496 lines of code before you run out of COGram. So thinking 'big' is not very useful (try Linux for that).
But the truth is that a heck of a lot can get done in 496 longs of RAM (combined program code and RAM space). Most tasks get done in under 10 lines of code, some might reach 20.
I was looking at code for a unipolar stepper motor recently and it is just basically a loop of three lines, maybe a fourth line to jump into a delay sub-routine as no stepper can handle over 6Mhz of stepping (80Mhz/(4 clocks per command x 4 commands). But it seems rather silly to devote one whole cog to a stepper motor when maybe only 20 or so long are required.
And so, it becomes quite clear that one can expand features to that stepper routine and still have space left over. Obvious ones are speed control, single step, pause rotation and hold, reverse rotation, led indicators, and so on. Each of these is a tiny little task on its own. Creating the equivalent of If statements is not that hard. One uses tests to fork the program to one of two choices.
But is all goes back to being organized from the start and knowing what you want out of a project.
http://forums.parallax.com/showthread.php?t=122575&highlight=assembly
The SXes have about 40 assembler instructions in their RISC set, the Propeller has nearly 80 instructions.
I suspect that to really master assembly language, you need to learned to use it on two different microcontrollers. At that point, the comparison and contrasts begin to show you how to think in binary logic.
I always thought the coolest thing about programming in assembly was I could use the by-product of an instruction to make my program smaller and faster
asm instructions in a cog.
In asm you can use all kinds of quirky code
to do things. It's expected that asm coders
use as many tricks as possible to gain speed
and make the code smaller. That sort of thing
is really frowned upon in C for instance. I enjoy
playing with asm by writing the strangest code
I can to perform a task. You would never do such
a thing when coding a serious project but the
exercise really advances your asm skill set.
I love self modifying code and with the Prop you
sometimes have to write self modifying code to get
the job done.
I always start a project by creating a very detailed
flow chart. I just can't code without a flowchart. I
can't understand how some people just start writing
asm code without one.
Assembly language is entirely the opposite. To optimize code you really need to master every quirk of the hardware finding ways to exploit the hardware for optimal code. It certainly is NOT about being creatively weird so much as it is about being efficient with limited resource or getting the fastest time.
With assembly, it is likely that the application as much as the micro-controller will dictate the approach and the final project, but I am enjoying thinking in binary as opposed to C or Basic or......
And furthermore, microcontrollers really need to be optimized due to limitations.
More importantly, from the learning standpoint of a beginner I was particularly attracted to the smallest instruction set I could get. I still believe it is best to start off with RISC and about 40 instructions. That means that PASM to me is not optimal for a beginner as it may offer more distractions. But as I said above, you really aren't proficient until you get involved in two different architectures. That really expands your creative thinking about what binary can and does do.
Assembly is a bit like learning juggling - anybody can do one ball, most can do two' but beyond that the real fun begins. I am studying more and more of the Propeller architecture to really see how to fully use PASM. I am looking at the video drivers - both the TV and Graphic. But also I am trying to comprehend exactly where 32bits truly exists and 8bit is used for storage. I am not quite sure the MainRAM is 8 bit or 32bit. By the clocks being equivalent for bytes, words, and longs; it seems to be 32bit. (The implication is that writing a byte, occupies a whole long). Of course the Cog is all 32bit. But the EEPROM is 8bit in format.
Why so much thought about 8bit versus 32bit? It all affects timing and every clock counts in Assembly. The fundamental processor wants everything in its own size (be it 8bit, 16bit, 32bit, 64bit), there is always a trade off if you want bigger or smaller.
What's this "free time" thing you're talking about? (and where do we buy some?)
John R.
I have a diagram or picture of this in my mind. So no need to write it down on paper.
Same with circuit diagrams. They are pictures in my mind. So I will just start wiring things with no written diagram if it is my own design.
As far as PASM is concerned, it doesn't matter whether hub accesses are byte, word, or long. The instructions take the same amount of time and the values in the cog are all 32 bit. Hub (main) memory is byte addressable, but the low order address bit is ignored for word accesses and the low order two address bits are ignored for long accesses. As is true for most memories these days, the actual width of the memory is wider than a byte and there's extra logic to access the pieces.
EEPROM is generally byte addressable and the I2C protocol (and the I/O driver) is designed to transfer a byte at a time in blocks of one or more bytes.
Completely Revised
\\\ I am a bit confused about how the MainRAM packs bytes and then later locates them when the op code has merely 9 bits of destination and 9 bits of source, But you do indeed mention 'extra hardware' and I must guess that the opcode itself tells the MainRAM how to handle the length, be it Byte, Word, or Long.
I just can't quite reconcile 'literal addresses' or 32K of bytes or 8K of longs into 9 bits of code. 32K would seem to require 15 bits of address, 8K of longs would seem to require 13bits of address.
I need to think about this and ask you for more clarification -- in the Propeller Forum \\\