Propeller Datasheet Assembler MOV
microcontrolleruser
Posts: 1,194
Will paste instruction and datasheet link.
What is d and s?
What is a region?
How many bytes is this instruction?
https://www.parallax.com/sites/default/files/downloads/P8X32A-Propeller-Datasheet-v1.4.0_0.pdf
MOV instruction is on page 23
What is d and s?
What is a region?
How many bytes is this instruction?
https://www.parallax.com/sites/default/files/downloads/P8X32A-Propeller-Datasheet-v1.4.0_0.pdf
MOV instruction is on page 23
101000 001i 1111 ddddddddd sssssssss
MOV D,S
Set D to S
Result = 0
S[31]
1
4
This discussion has been closed.
Comments
https://parallax.com/sites/default/files/downloads/P8X32A-Web-PropellerManual-v1.2.pdf
In the manual mov is on page 311, but it is important to read the introduction that explain the makeup of the assembly language instructions.
mov is a 32 bit instruction which includes the s & d fields.
Thank you.
Roadmap for what I'm trying to do is this:
Load port register with all 1's to light up LED's.
Looks like it is going to take some doing.
Instructions are all 4 bytes.
D is destination register, or COG address.
S is source register, or COG address.
D and S, along with the instruction, condition codes and address mode bit are all bit fields within a 32 bit instruction. (Immediate vs register address)
Propellers are not load, store machines. They are memory to memory machines.
There are no big, multi byte type instruction values possible. There are no small, less than 32 bit instructions possible either.
Eg:
MOV OUTA, #$FFFFFFFF
What you do is put your large value somewhere and label it. Then reference that label in your MOV. Many programmers will put these at rhe end of their PASM program so they do not worry about executing them, or have to jump around them.
Consider this ultra simple two line program:
DAT org 0 MOV OUTA, all_ones all_ones long $FFFFFFFFThe source register "all_ones" will assemble to the address of the cog register associated with label "all_ones"
In this little example, that value is cog register 1. Cog register 0 contains the MOV instruction.
The destination register value assembles to the address of OUTA. That cog address is, $1f4.
We could just write:
MOV $1f4, 1
Why not MOV $1f4, #$FFFFFFFF ?
Because all instructions are 32 bits. The source bitfield you referenced has 9 bits, sufficient to address any COG register address to fetch a value, or the 9 bits can be the value, 0 to $1ff. There are not enough bits!
Also, why not MOV $1f4, #1 ?
Because the octothorpe (yes, that is actually the name!) "#" indicates the source value is to be used directly, or immediately. It will not be used as a source value address, just a source value. That would put $00000001 into OUTA, $1f4.
Now back to the two line program.
When the MOV instruction runs, the source value, 1, is used as the address of the value to be moved. COG register 1 contains $FFFFFFFF.
The destination value is used as the address for the contents of COG register one data to be moved to. That is the special purpose, COG memory mapped register at address #1f4, known as OUTA.
There is memory to memory right there! Only the MOV remains to happen. The propeller knows all it needs to and will do the MOV.
When the instruction is done, COG register 1 and COG register $1f4 will contain the same value.
Memory to memory direct, no load store type operation needed.
If you want big constants, you have to store them in the HUB and read them into the COG with RDBYTE, RDWORD, RDLONG.
, or
Just put them into a COG memory (register) location as a constant as shown above. You can do that when writing your program. It is done all the time. The examples that ship wirh the Propeller Tool and the manual contain many examples.
COG memory can hold an instruction, or data. The 32 bits get used either way. And it does not care. If program execution runs into data, that data will be processed as instructions. Always make sure you maintain control!
People will call that memory register memory, and may call it COG memory, or program memory. It is all the same to the Propeller COG
COG addresses are long, or 32 bit addresses. There is no byte, or word (8, or 16 bit) addressing in the COG.
Addresses and program execute start at 0. They proceed, in whole integer increments, ending at 9 bits, $1ff. That's it. A PASM program will run in that memory space only. That is the private COG memory unique to each COG, or core. There are 8 COGS. They can all run programs concurrently, and do so independently.
Both source (S) and destination (D) are 9 bit fields within a 32 bit instruction, and they point to the 9 bits of register address space available in the COG.
PASM programs only run in COG memory.
When a COG starts, it copies its program from the HUB, then starts at 0. That program can overwrite the original in the HUB, if desired.
The propeller boots, loads the SPIN intrepeter into COG 0, and that PASM program runs your SPIN program.
Your SPIN program can start a PASM program.
Your SPIN or PASM program can stop, and start COGS and when starting a COG, the HUB address of the PASM program for the COG to load a cooy of, is supplied at that time.
Thank you
I am still having issues with no HELP menu in compiler with little snippets of code for instructions.
Catching on that there is some learning curve with the Propeller.
Guess I am in denial about that.
Figured if it said Parallax on it it would be all spoon fed like the Stamp.
I will look at what you wrote in the morning.
Maybe get one thing done. Find that 32 bit register.
No load store? The stuff has to sit still somewhere.
I think it's done in the background.Reminds me of SX. Parallax's own assembler instuction set. PASM?
Anyhow. In the morning.
There are buses inside the COG. There is a d bus, and an S Bus.
When you do a move the data travels over those buses between the two registers. There is no accumulator.
Now, if you consider working with the Hub memory, there is a load store mechanism there. When you get HUB memory with a cog you will read it from The Hub and you will store it into a cog register. Just imagine the Cog as having 512 registers if you want to.
In any case if you want to modify memory in the hub you fetch it into a cog register, do the work, and then you write it back out to the hub. So when working with the Hub memories propeller is in fact a load store machine.
Edit: in my opinion, understanding that the Cog memory is an entirely separate, and private memory space to the Cog, is a real big part of understanding the propeller. It's not all one memory space. Your program actually gets copied into the Cog, from wherever it happened to be in the HUB, then it will execute from the private Cog memory.
I knocked this out with google voice quick please forgive typos.
The propeller is in fact entirely custom. Chip Gracey drew every polygon. It's his instruction set.
Unlike many CPUs, this one has some real differences from the Norms. You would really benefit by taking a look at the very basics.
It all will go pretty rapidly from there, for what it's worth.
Potatohead
Is it worth messing with the assembler?
In that the Spin sounds more native.
So you do not need to decide if either or the other.
Usually you should use Spin a language written for the Propeller. Spin can include assembler (PASM) in the Spin Source.
Spin is interpreted by a interpreter running in COG ram running Bytecodes in HUB ram. Much like the BASIC stamp.
There is also a program called fastspin. It compiles Spin directly into assembler, making it way faster but also way bigger, Spin bytecodes are very efficient memory wise.
But fastspin can also compile BASIC instead of SPIN, maybe more easy for you, since you used BASIC already.
If you install Propeller Tool then you will have a Library folder and a example folder selectable on the left side in a drop down.
There you can look how things usually get done. working with multiple cores is confusing sometimes until you get used to it.
Generally you write your program in spin and if you need more speed for something then you start using PASM.
Enjoy!
Mike
I think it was the first Basic for the Propeller, followed by PropBasic and now FastSpin(BASIC).
For the P1 with its 32K ram Spin is quite optimal in size and handling, but on the P2 size might not be as much a constrain. What I like on fastspin is that it
a) supports Spin, Basic and some C.
b) is very actively developed by @ersmith .
c) it can include Spin objects in C and Basic so the OBEX works for BASIC or C too. Actually you can also include objects written in C into Spin or Basic and objects written in Basic into Spin or C.
d) it allows inline Assembler in Spin/Basic/C something the original Spin does not support.
e) it also integrates features of the not yet finished Spin2 and does backport them to the P1, say multiple return values of methods and such.
f) it can compile for the P1 and the new upcoming P2, so once one gets used to it, it works on both chips.
g) it is cross platform and runs on windows, Linux and mac.
the only minus I see is that it creates pure assembler (LMM for the P1) so it will need more ram than any bytecode interpreter.
Enjoy!
Mike
'Whoa! I say woah there!'-Yosemite Sam
Slight case of 'Too much information'.
How big is a register?
32 bits
Thank you.
How about this for a glimmer of perception?
'Main Memory is located in the Hub and is accessible to each cog, one at a time, in a round-robin fashion'
'Main RAM is 32 KB, organized as 8192 32-bit longs. It holds your program,'
You have to take parts from each of those to make this.
Your program is in main memory. There is NO PROCESSOR that acts on main memory.
You have to 'start up' one of the eight processors (named as 'Cog's') to start processing instructions.
Would be clearer if Cogs were called Processor 1, Processor 2, etc.
'What we have here' is a case of Southern California Okie common sense collides with Northern California whatever they are doing
up there.
Why are all eight processors 'round robin accessing' all the time if you are not using them?
I think there are going to be 'many rivers to cross' before writing a couple lines of code to:
make some pins turn on some LED's
It is fun figuring this Propeller out though.
This is from Propeller Q&A. Darn good little article.
What is Main Memory?
Main Memory is located in the Hub and is accessible to each cog, one at a time, in a round-robin fashion. It is divided into two equal sections: Main RAM and Main ROM.
Main RAM is 32 KB, organized as 8192 32-bit longs. It holds your program, data, global variables, and stack space, which collectively make up your Propeller Application. Main RAM is byte, word, or long addressable and each location is usually referred to as an "address."
The 32 KB Main ROM holds read-only system resources: the Boot Loader and Spin Interpreter, character definitions, and log, antilog, and sine tables.
ALL programs begin as SPIN programs. PASM programs are part of SPIN programs, and begin when a COG is started, or directed to run one of those programs, and is given an address where the program exists in the HUB.
The very next thing that happens is the COG copies that program to it's private memory, and from there PASM instructions begin executing at address 0. Once this process starts, the program code in the HUB is no longer needed. It can be used with another COG, overwritten, whatever.
'It holds your program" ... sort of ... It holds your Spin program and holds PASM instructions pending transfer to cog memory for execution.
The start-up logic automatically forces a COGINIT instruction which initializes the first (#0) cog / processor and copies the bootstrap program along with Spin interpreter ... from on-chip ROM to the cog's memory where it begins execution.
'the COG copies that program to it's private memory'
That is where they are losing me. Why not just leave it there?
Looks like a mutation of 'bringing in program from EEPROM' Parallax habit.
'the program code in the HUB is no longer needed. It can be used with another COG, overwritten, whatever.'
That give me the heebie jeebies.
Seems like there is a lot of unnecessary 'flash and light' going on here.
I would have to see another multi processor scheme to see how this compares.
Anyhow.
On to next phase.The target. A port register. I live in fear of how that will be explained.
'The start-up logic automatically forces a COGINIT instruction which initializes the first (#0) cog / processor and copies the bootstrap program along with Spin interpreter ... from on-chip ROM to the cog's memory where it begins execution. '
This is what I mean.Way too much going on here.
Conventional micro example.
Power up chip.
Code executes.
Done.
Where is all this stuff coming from and why?
No response.
I am comfortable with leaving it there.
No response? No use Propeller hardware. Simple.We're talking quite a bit of it too.
I guess that is the trick.They got there money so why bother to explain how to use it.
Yep. That is our new position. No explanation? Then it can just sit here.
Explain so 'anybody can understand it'.
If I enrol in any course then there usually is a prerequisite. Why? Because otherwise anything they would try to teach me would go over my head, it would be a case not only of too much information, but also a case of lacking the fundamentals to allow me to make sense of that information.
Do you possibly think that this might be the case here?
If it were me I would be doing some basic research, starting with stuff that I could understand and then trying it out until I finally got to the level that I knew enough to know enough about what I didn't know enough about but knew enough to be able to ask the right person the right question at the right time, if you can grok what I'm saying.
By asking certain questions you are looking for answers that are beyond your ability to deal with, even when the answer is greatly simplified and broken up into little bite sized pieces. Any good student will go to class, listen, learn, and do their homework, to sound down the things that they learned, try them out, and understand them. Then they are able to step up to the next level.
Learn to walk before you try to run and fall flat on your face.
Splash in the shallow end until you learn to stay afloat and swim before venturing into the deep end otherwise it is not pretty.
BTW, please don't insult Chip by insinuating that "they got 'there' money" and can't be bothered. That is so far from the truth and you should refrain from judging just because you didn't receive a reply from someone who is dedicated to his work and family and spends way too much time helping everyone else.
Can you write a 4k program with the Propeller?
It is just that you have to stash it in 8 512 byte pieces in these 8 processors?
Then the 'bonus' is the 512 pieces can run concurrently?
I think I am on the right trail here.
But, to answer your question, using native PASM, no. There are no large PASM programs. You absolutely can make a program distributed across the COGS.
There are ways. But you must first begin with the basics.
To do that, you need to realize what it is, and it is not what you have worked with before.
Why can't you have a 512 byte program running on each processor?
Manual says each one has 512 bytes of memory.
512 bytes ain't much.
Check my math but that is a 16F57. Two pages of 256.
Propeller came out 12 years ago.2006.
512 is a little on the small side for running high level language.
Check my math again.
The complication happens when a CALL or JMP needs to be executed. However, this is implemented by routines in cog memory that just adjusts the pointer that is used to fetch hub instructions. This pointer is normally named PC, which stands for program counter. So when a program in hub memory wants to perform a CALL or JMP it just does a JMP to the routine in cog memory that adjusts the PC.
I hope this isn't too confusing for you. The program in cog memory that implements LMM is actually pretty simple. The main drawback is that it is significantly slower than running programs directly from cog memory. However, it is typically faster than an equivalent Spin program.
There is no byte addressing in the COG. Each address is 32 bits.
That is, in fact bytes times 4. 2k. Each COG has 2K of private RAM. 2, count them, one and then 2k.
Secondly, and let us just say 512 instruction programs for sanity here, I and others have and will easily agree with you, yes! You absolutely can make a program that fills all the COGS.
512 instructions is not much, but the nature of them does way more than you would think at first.
As for your other statements, I can only point you to the body of large programs out there today.
They are not written in the way you seek, however. And there are really great reasons why, expressed to you multiple times.
I am going away for a while now.
It is one thing to help people see how the thing works. It is another to argue and near constantly justify said works.
They simply are. You are left with understanding or not. Simple as that.
You cannot argue your way to something more to your liking here. It is just different. For realz. No joke.
Thank you Dave and Potatohead
I will try the Spin for a little while just to get the layout of all this back and forth stuff.
Spin info from Parallax seem a little more in their ballpark.