Very basic questions about Propeller assembly`
Carl Hayes
Posts: 841
I've been attempting some very simple work in Propeller Assembler Language, and have found that some utterly basic information is not given in the Propeller manual (or not findable by me, anyway).
(1)· What is the smallest addressable unit of·Cog storage?· I infer that there is no way to address a word or a·byte of storage.· If true, this is an unfortunate circumstance, for (a) it means I have to·waste a lot of storage, 32 bits per 8-bit operand, and (b) it makes many things confoundedly difficult when they ought to be very easy.· I fault the manual writer for referring only to "registers" (they're storage locations, not registers), which is very nonspecific in an instructiional discourse in which specificity is absolutely essential.· Anyway, do the instructions address, and manipulate, only "longs"?
(2)· In statements like LONG, if there are no operands, is any storage allocated?· For example:
·······Long1·· LONG····· 3········ ' Clearly allocates one LONG and sets its value to 3
······ Long2·· LONG····· 4,5,6··· ' Allocates three LONGS and sets their values as indicated
······ Long3·· LONG·············· ·' What the Sam Hill does this do?
I think I've determined by experiment that my third example allocates nothing.· I expected it to allocate one LONG but leave it uninitialized.· Not saying so in the book, if it actually allocates nothing, is a disservice that has cost me several days of head-scratching.· Am I right, it does nothing?
I'm sure I'll have other questions.· And why isn't stuff like that in the book?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net
(1)· What is the smallest addressable unit of·Cog storage?· I infer that there is no way to address a word or a·byte of storage.· If true, this is an unfortunate circumstance, for (a) it means I have to·waste a lot of storage, 32 bits per 8-bit operand, and (b) it makes many things confoundedly difficult when they ought to be very easy.· I fault the manual writer for referring only to "registers" (they're storage locations, not registers), which is very nonspecific in an instructiional discourse in which specificity is absolutely essential.· Anyway, do the instructions address, and manipulate, only "longs"?
(2)· In statements like LONG, if there are no operands, is any storage allocated?· For example:
·······Long1·· LONG····· 3········ ' Clearly allocates one LONG and sets its value to 3
······ Long2·· LONG····· 4,5,6··· ' Allocates three LONGS and sets their values as indicated
······ Long3·· LONG·············· ·' What the Sam Hill does this do?
I think I've determined by experiment that my third example allocates nothing.· I expected it to allocate one LONG but leave it uninitialized.· Not saying so in the book, if it actually allocates nothing, is a disservice that has cost me several days of head-scratching.· Am I right, it does nothing?
I'm sure I'll have other questions.· And why isn't stuff like that in the book?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net
Comments
CON
·_clkmode = xtal1 + pll16x
·_xinfreq = 5_000_000
PUB Main
·cognew (@Degree,0)
DAT
··············· ORG·········· 0
Degree
··············· OR··········· DirA,:Allones
:Start
··············· NOP
··············· XOR·········· OutA,:Allones
··············· JMP·········· :Start
:Allones······· LONG········· $FFFFFFFF···
This does what I wanted to do -- sets all pins to output and toggles them fast.· It works fine.· My purpose was to see how fast it would go.
If, however, I remove that NOP and make no other changes, none of the pins toggle.· This passeth understanding.· Why?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net
I have no objection to the use of "registers" to describe cog storage. It's particualrly apt in the Propeller, which has no accumulator, index registers, or the like, and whose few special purpose registers mapped into the same address space as code. In fact, the most useful paradigm might be to think of it as a processor with no specially-designated program storage at all, but one which can execute code from its 496+ registers!
-Phil
Regarding your program, the jump should be JMP #:Start. With the NOP ($00000000), you're jumping back to Degree.
-Phil
But even jumping back to Degree ought still to result in toggling of the outputs.· Hmmm?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net
Thanks, though -- I appreciate the answer.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net
-Phil
Not saying these things are not absolutely determinable and solvable·-- only that the documentation gives no clue.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net
Whoever designed the Assembler Language·designed that particular syntax exactly backward compared with other assemblers I've used·for machines that had indirect addressing.· Wacky.· Typically, direct addressing is the norm, and indirect addressing has to be indicated.
But, at least, there's a place to ask these things.· That's a great help.· Thanks again.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net
Post Edited (Carl Hayes) : 2/10/2009 12:41:17 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
DISslow········ MOV·········· DISslowlong,DISslowvalue···
DISslowlong and DISslowvalue are LONGs in cog storage.
Will this copy to DISslowlong the address, or the contents, of DISslowvalue?· I intended to copy the contents.
Incidentally, I have now placed octothorpes in a great many JMPs in that program, and it is nearer to working.· Does that addressing scheme for JMP apply also to DJNZ, for example?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net
Post Edited (Carl Hayes) : 2/10/2009 1:04:00 AM GMT
Addendum: I missed Paul's post and, sure enough, it's there on page 312. But that's in the Spin chapter; I was looking in the assembly chapter. Silly me!
Carl, you're a little late to the party on that one! But we all feel your pain. For me, it's responsible for more head-scratching program bugs than any other single issue. Yet, in Parallax's defense, I'd have to say they got it right, if "right" means "self-consistent" with the rest of the assembler. It's just not consistent with history. Or maybe it's the other way around!
A lot of confusion may have to do with our terminology. A mov a,#b is an "immediate" load, whereas a mov a,b is a "direct" load. But our terminology changes when the same syntax is applied to jumps. Here a jmp #target is called a "direct" jump, even though the operand that gets loaded into the PC is immediate; and a jmp target is called "indirect", even though the PC gets loaded directly from the target location.
-Phil
Post Edited (Phil Pilgrim (PhiPi)) : 2/10/2009 1:37:07 AM GMT
mov a,b copies the contents of the long at address b to a.
mov a,#b copies the address of b to a.
-Phil
The explanation on page 312 is meaningless, for branches anyway.· One doesn't branch to a literal.· One branches to a storage location.· If the branch is indirect, one branches to the address contained in the stated location.·
Some machines specify the indirection in the target, rather than in the instruction.· In these machines, any address that has the sign bit set is an indirect address.· These machines can use multi-level indirect addressing.· You say jump to A, and can get something like this:
·· You say jump to A
·· A contains the address of B, with a sign bit attached
·· B contains the address of C, with a sign bit attached
·· C contains the address of D, with a sign bit attached
·· D contains an instruction without a sign bit.· Your program branches to D.
Multiple levels of indirection are not terribly useful, but once in a while two levels can be useful in decision-making within a program.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net
Yes, that's consistent.· Consistently wacky, one might say.· Bless their hearts, they did their best, didn't they.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net
I feel your pain (as I'm sure many others here do, or did) however once you overcome some of the quirks of the hardware it really isn't bad. A lot of the things that seem like arbitrary design choices start to make a bizarre sort of sense after you understand a little more about the architecture of the machine. That's not an excuse for the manual (or lack thereof in the case of assembly) but Parallax is a relatively small company doing something pretty ambitious, so the omissions are forgivable.
If you haven't read it already, deSilva's machine language tutorial may help clear some things up for you:
http://forums.parallax.com/showthread.php?p=668559
There are other useful resources in the 'sticky' topics for programming the Prop: http://forums.parallax.com/showthread.php?p=663640
Hang in there - It gets easier.
Jason
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net
[noparse][[/noparse] # = octothorpe.· I was not aware.· I never liked·"pound-sign" or 'the uh tic-tac-toe thing'. ]
Given true execution only happens in the COG, the implication then is that program flow addresses are in terms of COG address space.
A branch then will have a long as it's target, as there are no alternatives.
There then are only a few addressing possibilities. A given long may contain an instruction, or be data. It is simply storage.
The only place a branch target address value can exist is within an instruction, or is the contents of a long.
Propeller is a memory to memory design, meaning there is no load, compute, write process that is addressable in the sense that registers on most other CPU's are addressable. Therefore each instruction then contains it's source and destination targets as part of it's definition. There is simply no where else to put them, without adding some additional construct to the processor model.
Additionally, there are only two options for the values so embodied in an instruction:
1. The values indicate an address LITERALLY, and that is the case with the octothorpe character
,or
2. The values represent the address of the long that contains the address.
On the Propeller, that's really it!
So then, jmp #5 is a literal form, and therefore will load the PC with the value 5, thus changing program control to whatever instruction exists at cog memory address 5.
Jmp 5 is an indirect form, in that the actual target address for the jmp instruction is contained in the long at cog memory address 5.
A similar exercise is possible for the other addressing forms, where we address the hub, move bits and do math. It's one or the other. Either the value in the source or destination IS the address, or is the address of the LONG that contains the address.
Because of this simplest case design, there are instructions specifically designed to modify the source and destination bit fields of an instruction long. They are movd movs and movi.
With these three, it then is possible to use a COG long to index, either source or destination, and or represent an instruction based on a value or table.
That sums up the addressing modes avaliable on the Propeller. It's either indirect, or literal (and some use the word implied here). Additionally, the data to be written can be addressed in terms of instruction bit fields, specifically for the purpose of self-modifying code to perform most functions normally performed with additional registers, like index registers.
Frankly, this is the simplest programming model I've ever encountered. Most of the problems I have boil down to carrying forward my expectations set from experience on more complex processors.
Perhaps it's a good idea to present this in some fashion where other CPU instruction set references include a programming model. Having those key ideas in one place would resolve this confusion in a large number of cases.
As things stand now, these things are inferred, when they probably better served by being explicity stated. I know this caused me some grief. Being the rank amateur I am, I just followed the discussion and did trial and error with small code examples until it became clear. This programming model is different enough to warrant such an exercise, IMHO.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 2/10/2009 4:30:37 AM GMT
LONG without a value is simply a "Long align" command. The next Label or data allocation will have a long aligned address.
This is usefull in datasections with mixed byte, word and long data.
Andy
If the tool would produce assembly listings showing the assembled code, with addresses, this would have been easy for me to discover the easy way -- instead of discovering it the hard way and seeking confirmation.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net
A literal is an element in an assembler-language statement that causes allocation of storage somewhere else in the program, in what is called a·literal pool.
Example, from IBM 370 assembler:
···········LABEL1·· L······ 11,=F'44'
This loads general register 11 with the contents of a fullword somewhere else, which the assembler is thereby instructed to create and fill with·the·decimal value 44.· It's the "=" that tells the assembler to do this.· The 370 assembler (in its various versions IEUASM, IEV90, etc.)·is very smart -- it won't create multiple literals with the same value·unless you tell it to.· Literals can be of any of the many data types available in System/370.· That meaning of literal is pretty uniform on IBM, Control Data, RCA (I'm showing my age), DEC, and other platforms.
Well, OK, if it isn't a literal and shouldn't be called a literal, is there some other standard term for data that is included in the instruction itself?· Yes, and many machines allow this.· The standard term is immediate data.· In PASM, what the # specifies (everywhere except in branches) is immediate data.
But technical jargons are often idiosyncratic, and if the documentation were as complete as it ought to be, and defined its terms adequately, there would be no harm in referring to immediate data by a nonstandard use of "literal", for it's a special use in a patois limited to this community alone.·
Still --
This thread, and the answers in it, have been very helpful to me.· I now have some code running that I've been scratching my head over for several days.· That octothorpe was the cause of it all.· I'm very grateful to the literate and articulate folks here who have helped me today.
Thank you.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net
Post Edited (Carl Hayes) : 2/10/2009 6:13:27 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net
I figure a little affirmation never hurts.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Frankly, I see no harm in using "literal" and "immediate" interchangeably. Even if the assembler created a literal pool automatically, it would have to be from "immediate" operands that were too large to fit nine bits, viz:
mov a,#7000would assemble as
mov a,_00001b58 ... _00001b58 long $00001b58-Phil
The word "literal" is has often been used at a higher level than that of the details of instructions and generally conveys the idea of defined constants. Fortran for example used a literal pool as you describe such that if you used the same constant value many times in your program it was stored only once somewhere rather than being spread throughout the compiled code. The compiled code had to pick that literal up from some known address when required presumably using an address field at that point in the code. So I'm not sure there was any saving in memory space by having a literal pool.
Which brings us to "immediate" values. These are also defined constants, using EQU or such, and often also called "literals". In 8080 assembler one would have something like:
FOO EQU 42
.
.
MVI A, FOO
as opposed to the "literal pool" method:
FOO DB 42
.
.
LDA FOO
Note the latter uses a 16 bit address field for every reference to FOO instead of the actual value as an immediate byte and so uses more code memory.
Both of these are conceptually the same and FOO would be called a "literal" by many even when not "immediate". Of course in PASM if your "literal" is bigger than 9 bits you have to put it in a literal pool and refer to it by address.
The "octothorpe" is more commonly know as the "number sign". So its use of "#5" to mean "this actual number 5" seems quite reasonable if perhaps at odds with assembler history.
I might take issue with your statement "In PASM, what the # specifies (everywhere except in branches) is immediate data."
Whilst you cannot jump to a constant, writing "JMP #5" does mean "move the number 5 to the program counter" so the # indeed always specifies immediate data.
Actually if one uses a literal pool it turns out you can jump to a constant. Consider putting "JMP FOO" in the above code.
All in all, the Propeller and PASM are very simple, logical and consistent. I love it for that. Perhaps if sometimes at odds with history in places.
If you want to something to complain about try and work out what @ does in different code sections (PUB,VAR,DAT). That will make you nuts[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Heater: Being at odds with history is probably why the Prop is the way it is! Agreed on logical and consistent too. The assembly language has very few exceptions to the rule, and I really like that.
Carl: Thanks for the enlightenment on literal. I do now remember seeing that term used in that context from when I was into 8 bit 6809 6502 assembly. It's very easy to use it, not like the technical term, but just as an ordinary element of descriptive language. IMHO, that's where some ambiguity exists, at least for me. Heater does have an interesting observation on that as well! And a similar combination of descriptive language -vs- technical term exists in his example: constant and literal. This stuff exists all over the place. Having the discussion then is good as it clarifies things and we move on.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
As for making me nuts -- my friends are unanimous that it's too late, and has been too late for decades.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net
By the way I seem to remember that PL/M written for Intel 8080s by Gary Kildal in the seventies based on PL/1 and used also on x86 had literals:
DECLARE TEMP_LIMIT LITERALLY '150';
or some such. Of course these literals ended up in immediate bytes in the instructions rather than in a literal pool as in Fortran. So I'm not sure tha history was consistent with itself[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.