Propeller Assembler vs. the TI MSP430

kt88seamp

I want to start learning Prop assembler.

Im my microcomputers class my professor is teaching us how to program the MSP430 series of microcontrollers. I find that unit neat. Only 27 native instructions and 24 emulated. Does the prop have emulated or are they all native?

What about general purpose registers? The MSP430 has 16 of them R0-R3 are reserved. R0 for the program counter, R1 for the stack pointer, R2 for the status register, and R3 for the constant generator. R4 - R15 are for general purpose use. How is the propeller in respect related?

What about initialization? In the MSP430 you need to specify with ORG directives to specify the beginning of ram, the reset vector, and the beginning of the code, etc. Are there templates for beginners like my teacher provides us?

Finally, what about the stack and the stack pointer. Does the prop use one?

BradC

Quick answer
- All native instructions
- 496 usable user registers (that also contain the program code)
- No stack

It's a good idea to specify ORG. All assembly programs run in their own separate cog and all start from location 0.

Plenty of code examples in the forum, obex and accompanying the Propeller Tool.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.

kt88seamp

Its generally good practice to push data onto the stack with the TI·when passing data between subroutines to save your registers. With 496 of them its pretty easy to get confused.

potatohead

The Propeller has no emulated instructions. All are native.

IMHO, the set of core Propeller instructions necessary to write effective programs is not all that large. There are quite a number of permutations, due to the conditional execution bits and instruction effect bits. Each can be executed on a variety of cases, if_Z, if_NZ, etc... and each can either write the result and or flags as needed. This makes for some dense code, when properly applied. It is possible to ease into this aspect of the chip however.

Propellers do not have many addressing modes. There is basically implied addressing (where value in instruction is used directly), direct addressing, and indirect addressing.

One unique element is the two memory spaces. Propeller assembly language executes on a COG, and there are 8 of them. The COG addressing is really simple, with each 9 bit address being either an instruction to execute or data, as determined by the programmer. There is no addressing other than LONG (32 bit addressing)

When a COG interacts with the HUB (shared memory), addressing is on a byte, word, or long basis, with alignment being the least significant bits set to 0.

You will find "registers" to be an interesting topic!!

Propellers are not a load, operate, store design. There are NO designated general purpose registers that are directly addressable, other than the PC. All operations are memory to memory direct, meaning the entire 9 bit address space of the COG is either registers or program memory as you the programmer deem appropriate. The upper COG memory addresses are shared with shadow registers that control the on-chip facilities provided by each COG, and manage the pin directional states, which are all "or"ed together electrically. The pins are shared among all COGs, meaning programs can run on the different COGs, directly interacting with the state of the pins set by themselves, or other programs.

There are no vectors, as there are no interrupts.

Initialization is simple. Propeller powers up, finds EEPROM, loads it's shared memory with the program image, then starts executing SPIN code in COG 0. All propeller assembly programs start with a minimum of one SPIN instruction, which can simply be a call to start running assembly language. If that's confusing, know that Propellers contain an on-chip high level, tokenized SPIN language intrepeter, that can be used to run lower speed, non-assembly language programs in tandem with lower level assembly programs.

These can be mixed and matched on any of the 8 COG's, meaning they can be running SPIN code, or assembly code. A common example would be a video driver running on one COG, where a SPIN program running on another one can write to the frame buffer to display something, not having to interact directly with the video driver, which would look like hardware to the SPIN program being discussed.

There is no stack. Programmers are free to create one, and calling subroutines involves self-modifying code. On that note, indexing within the COG memory space also involves self-modify code as well. This isn't as bad as one would think, and in fact ends up making a lot of sense after you've coded a bit, and this is why:

When a COG is directed to run assembly language code, it's own 2K of memory is loaded from the shared 32K HUB memory, then program execution begins. COGs run in their own memory space, not related to the HUB. The program is copied from the HUB, which can be over-written, or not, depending on the programmer intent. The result of this is the self-modify code ends up being an ordinary and easy to do thing.

You will have a lot of fun on this chip, if you are willing to give up a few things that we all would take for granted [noparse]:)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!

Phil Pilgrim (PhiPi)

The architecture of the Propeller is entirely different from that of the MSP430. You need to approach the Prop with an open, receptive mind, without reference to other architectures or their typical programming practices.

-Phil

BradC

kt88seamp said...
Its generally good practice to push data onto the stack with the TI when passing data between subroutines to save your registers. With 496 of them its pretty easy to get confused.

Not really. Registers are kinda a hybrid of global variables and code. Incredibly versatile. It can get a little unwieldy if you want to write re-entrant code, but it can be done. Once you get your head around it, it's an absolute pleasure to write for.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.

potatohead

I'll second this, and when I wrote "give up", it's really about what Phil said. Just have an open mind, and jump in.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!

kt88seamp

In some ways I feel the architecture of the propeller is dumbed down compared to others, no offense. It seems to me, at least at this point that the prop would be a more powerful MCU if it was on par with most units, like supporting interrupts, vectors, stacks, etc.

BradC

kt88seamp said...
In some ways I feel the architecture of the propeller is dumbed down compared to others, no offense. It seems to me, at least at this point that the prop would be a more powerful MCU if it was on par with most units, like supporting interrupts, vectors, stacks, etc.

The thing is, those _device_ (interrupts, vectors, stacks...) are all hacks put in place to work around limitations in traditional architectures. Have a closer look into the multi-processing aspect and you will see the requirement for most of those things just falls away.

Simple, fast, powerful.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.

kt88seamp

One thing I like about the MSP430 is its low power modes. I understand the prop cogs go into low power state when there not in use. How power hungry is the prop in comparison?

Mike Green

The Propeller datasheet has a variety of graphs that describe the power consumption of the chip based on what it's doing. As with any microprocessor, the power consumption depends on how fast it's running and how much of the chip is active or inactive. Each cog takes a certain amount of power when it's running and the shared hub takes a certain amount of power. There is an instruction that will power down a cog for a user specified amount of time (WAITCNT) and two others that will power down the cog until a user specified I/O pin state occurs (WAITPEQ / WAITPNE). If only one cog is running and that one uses one of these instructions, the power consumption of the chip drops way down. In addition, the Propeller can change its clock speed and, by slowing down, can drop the power consumption markedly. Look at the graphs for specific values.

JonnyMac

You know, maybe the Propeller isn't for you.... Seriously, would you you go on a date and instead of learning about the person right in front of you speak only of the wonders of past relationships? As Phil points out, learning the Propeller -- anything, for that matter -- is best approached with an open mind. And the ability to crack open a document and read it. The Propeller specifications are posted online and you might find reading them pleasantly surprising.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon McPhalen
Hollywood, CA

kt88seamp

All im saying is that there are other solutions like the MSP430 that can consume so little power that the battery powering them can last 10 years or more. My current prop project is powered from the mains so power consumption is really not an issue. However, if I were designing a circuit where battery life were critical, I probably would use an MSP430 and no props. If multasking were an issue, I would have to live with the shortcomings of the MSP430. With what I am doing right now a prop really helps matters, if it were not for it, I probably would be using multiple MCU's in my circuit. Definately a date worth remembering.

potatohead

(deleted)

Most of us here have programmed a variety of CPUs. The Propeller is highly distinctive. The design elements you consider "dumbed down" actually present you many new options, not available on the CPU you are using, that is what we are telling you really.

Either those are worth learning, or not.

The only real comparisons are those ordinary computing operations common in assembly language. Those carry forward, as do other basic things. Beyond that, it's a new CPU. Comparing instruction sets, features, lack of, etc... doesn't mean much, until you've worked through some projects.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!

Post Edited (potatohead) : 1/28/2010 6:03:42 AM GMT

Mike Green

You have to use the devices that you're comfortable with. Based on the charts in the datasheet (which are based on test results), a Propeller running off the RCSLOW internal clock (around 20KHz) with all cogs waiting for a particular pattern of I/O pin states, the current consumption of the chip is on the order of 5uA. That's perfectly adequate for a low-power mode. You can do better with simpler microcontrollers, but you won't have the power of the Propeller as an alternative. The Propeller can switch back and forth between full speed and this very low power mode within a few milliseconds.

Phil Pilgrim (PhiPi)

kt88seamp,

I don't think anyone here would claim that the Propeller is the be-all, end-all solution to every problem. And you're right: the MSP430 (a 16-bit controller) enjoys a well-deserved reputation for its energy sipping performance. Every micro has its niche. You just have to select the one that's right for the app a hand. And the more micros you have under your belt, the more valuable you will be as a developer. I'm glad that you're trying the Propeller. I know you'll like it. And I've got a little MSP430 RF-enabled wristwatch I'd like to get more acquainted with, from a developer's standpoint.

-Phil

ErNa

Hi, just a short comment: when I've got the first LEGO bricks, there where just cuboids, but I had to build racing cars, fighters (star fighter), trucks, houses, and so on. And to make a wheel from cuboids helped me later to understand the en.wikipedia.org/wiki/Bresenham's_line_algorithm algorithm. So, the propeller gives you the unique chance to exercise communication in a very early stage. So you start, where others strand. The basic principle of everything is: there is an object and an operator and the object is in a state and the operator can change this state. Thats all. And all the processors in the world do nothing else. Every architecture is just a compromise, resulting for example from the fact, that an infinite address space needs an infinite number of address lines and the number of atoms in the universe is just limited. Invest time to understand the principles and remember: the propeller is like rock sugar. The crystallized envision of a young boy, who had a dream! Not just, to make money!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
cmapspublic3.ihmc.us:80/servlet/SBReadResourceServlet?rid=1181572927203_421963583_5511&partName=htmltext
Hello Rest Of The World
Hello Debris
Install a propeller and blow them away

hinv

If you want to compare it to something by Texas Instruments, a cog is more compable to the processor in the TI 99/4a

Peter Jakacki

Having programmed all manner of micros extensively including the MSP430 (even the old TMS9900 as in the TI 99) I can say that definitely that I would never ever even try to compare the MSP with the Prop. Yes, the MSP is very low power, very slow, but very low power, so are a handful of cmos logic gates. But I am not into coin cell powered devices anyway although I would always look at using the Prop for these for the reasons that others have mentioned.

Best not to compare no matter what, like learning a new language you have to immerse yourself into it and the culture to make it really click....n boy, has the Prop got some culture.

Thank goodness it doesn't have those traditional kludges that have burdened every processor since year dot such as interrupts, vectors, working register sets, machine stacks etc. On many manufacturer's datasheets these are called features, don't be fooled though, look at what the basic "V1.00" Prop has accomplished without all those features and the evidence is undeniable. It may not be mainstream but that has never been the measure of what is better anyway.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*

mctrivia

the only time I have ever wanted an interupt is when I am running out of cogs and want to interleave 2 things into 1 cog. The MSP430 is an amazing chip for low power options. But it can not do half the things the prop can. I liked the MSP430 until I got playing with the prop and since then it has just been collecting dust.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
24 bit LCD Breakout Board now in. $24.99 has backlight driver and touch sensitive decoder.

If you have not already. Add yourself to the prophead map

hinv

I don't look as the stack as a cludge either. It definitely has its advantages when going for a very small instruction word, like 5 bits on the seaforth chips. All you have to say is "add" once the operands are on the stack. For a 8 item sum, you can just push your 8 items on the stack and execute "add" 7 times, assuming you don't overflow. Analogy: The stack based systems remind me of the HP Reverse Polish Notation calculators. The orthogonal register space like the TMS9900 and the prop is more like a spreadsheet. I didn't want to give up my HP RPN calculator until I got the HP200LX which had both an RPN calculator, and a spreadsheet. I quickly learned how powerful the spreadsheet was. Now I only miss the rpn calculator when I want to do something quick, but usually have to resort to a conventional calculator instead.

Doug

Peter Jakacki

Well a postfix stack is certainly a different beast from a machine stack which is primarily used for return addresses and "saving" registers etc. Personally I love postfix operations that use a stack and it seems to me that this is what Spin is doing at the run-time interpreter level. Take a look at this snippet:

pub sum(n1,n2)
  result := n1+n2

Here is the resultant Spin byte code (using BST)

Local Parameter DBASE:0000 - Result
Local Parameter DBASE:0004 - n1
Local Parameter DBASE:0008 - n2
|===========================================================================|
2                        result := n1+n2
Addr : 0018:             64  : Variable Operation Local Offset - 1 Read
Addr : 0019:             68  : Variable Operation Local Offset - 2 Read
Addr : 001A:             EC  : Math Op +     
Addr : 001B:             61  : Variable Operation Local Offset - 0 Write
Addr : 001C:             32  : Return               

The read and write operations are single-ended in that they only have a source or destination which implies a stack is used and of course it is.
So really the Spin compiler generates Spin machine code and so you could have your own "assembler" that outputs this high-level "machine" code so:

      read     1      'read variable 1 and push onto data stack  ( n1 -- )
      read     2      'read variable 2 and push onto data stack ( n1 n2 -- )
      add              'pop and add the top two items of the data stack and push the result ( -- result )
      write    0      'pop the top item of the data stack and write to variable 0 (result)

Gee, that's almost like Forth using local variables!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*

BradC

That is precisely how it works. For interest sake and since you are already using bst you could actually do this with the same result..

PUB sum(n1,n2)
  bytecode($64, $68, $EC, $61)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.