Simple array question...
Kye
Posts: 2,200
Hello, I've been trying to figure out how to access an array in asm for some time now and I can't seem to find out how to do so.
I know how to acess an array in the main memory, but how do I access an array within a cog's ram.
I've been·using this code so far.
The idea is that I intialize a counter to the number of longs in the array (26) minus 1 (25).
Then I add the index of the array to a storage buffer.
And then I add the the value of the counter to the buffer, which will give me the memory location within the ram of the cog I am running the code on where the element I want in the array exist.
But how do I use the value in buffer,·which is now a pointer to the element in the array I want, to get that element?
I think I'm just missing something. There should be a simple command to do this.·The write and read operation to the main memory are the only aviable operators that do what I want...except that they don't operate on cog ram...
Thank you for your help.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
I know how to acess an array in the main memory, but how do I access an array within a cog's ram.
I've been·using this code so far.
mov counter, #25
checkKeyArray mov buffer, #keyArray
add buffer, counter
mov buffer, ??????????????
' More code here.
djnz counter, #checkKeyArray
The idea is that I intialize a counter to the number of longs in the array (26) minus 1 (25).
Then I add the index of the array to a storage buffer.
And then I add the the value of the counter to the buffer, which will give me the memory location within the ram of the cog I am running the code on where the element I want in the array exist.
But how do I use the value in buffer,·which is now a pointer to the element in the array I want, to get that element?
I think I'm just missing something. There should be a simple command to do this.·The write and read operation to the main memory are the only aviable operators that do what I want...except that they don't operate on cog ram...
Thank you for your help.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
Comments
mov counter, #25 checkKeyArray movs arrayPointer, #keyArray add arrayPointer, counter arrayPointer mov buffer, 0 ' More code here.. djnz counter, #checkKeyArrayI'm not sure if this type of self modifying code is safe to use...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
Post Edited (Kye) : 12/26/2008 11:40:05 PM GMT
VAR long cog, delay long cmd, chnl, nsamples, data '7 longs (3 longs, 8 words) PUB in(channel) '' Read the current sample from an ADC channel (0..7) chnl := channel do_cmd(_single, @chnl) ' get single sample from channel return data.word[noparse][[/noparse]channel] PRI do_cmd(adc_command, argptr) cmd := adc_command << 16 + argptr 'write command and pointer to shared memory loc repeat while cmd 'wait for command to be cleared, signifying completion ' ... mov t3, arg0 'load channel number, 0..7 shl t3, #1 'mult by 2 for word offset in data[noparse][[/noparse] ] add t3, #12 'add 12 for 3 long offset (cmd + chnl + nsamples) mov t1,par 'reset sample pointer add t1, t3 'add offset, t1 now points to data[noparse][[/noparse]channel] wrword t2,t1 'write sample to data[noparse][[/noparse]channel]Note the "data" variable in the VAR statement should be an array of 4 longs. For some reason, the insert code directive dropped this[noparse]:([/noparse]
Let me know if you need more info, these are only code snippets...
Jim
movs checkKeyArray, #keyArray mov counter, #25 checkKeyArray mov buffer, 0-0 add checkKeyArray, #1 ' ... djnz counter, #checkKeyArrayFor storing into the array, you need to use the destination field like
movd checkKeyArray, #keyArray mov counter, #25 checkKeyArray mov 0-0, buffer add checkKeyArray, incrByOne ' ... djnz counter, #checkKeyArray ' ... incrByOne long %1_000000000 ' A one in the destination fieldMaybe there should be an instruction that does just this though?...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
Do I read the book correctly?· I find these things very difficult to believe.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net
These are very simple RISC (reduced instruction set) computers these cogs are. They have very limited storage (512 32-bit words of which 16 are special purpose). Their main purpose is to provide software defined peripherals that can do "bit bang" I/O at pretty high speed which they do. Most of the access to anything like an array is to shared (hub) memory where there is a level of indirection using what is functionally an I/O instruction (RDxxxx/WRxxxx).
Maybe I'm jaded having programmed pretty much every kind of computer from the 1960's to the present and used all kinds of programming languages as well, but I don't find the Propeller at all strange or deficient for the kind of applications it seemed to have been developed for.
If this is a RISC machine, then apparently the Propeller Assembly Language is an interpreted language too, in the same sense that the System/360 instruction set was implemented by interpretation in microcode.· That, if true, would have made indirection even easier to implement.
Happy New Year anyway.·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net
How are you doing? Did your question get answered?
Mike, I don't like the term "self-modifying code."... what you are actually doing is synthesizing an instruction, using information not available at compile time... I'm not going to start a protest over it... but the verbiage implies a level of complexity that is way beyond what is actually happening... (it is kind of scary and misleading to hear that you have to use self-modifying code to address an array). What you are actually doing is "synthesizing an instruction" ... "creating a routine" ... "using the Prop-wise approach to array manipulation" ... anything but "self-modifying code" [noparse]:)[/noparse]
Carl... you were programming when I was born. I took one computer course in college... fortran... and quickly decided that computers would never be very useful because "who in their right mind would use punch cards and then wait a week to see any output?" I have really only been exposed to 2 assembly languages... the 68000 and PASM.
So my track record on the op/ed issues isn't perfect...And my computing experience is nothing to crow about.
Like you, I initially rebelled at the idea that I had to use self-modifying code just to access an array. The mistake I was making was that I was looking at the Prop as a microprocessor... which it is of course... but more than that it is a micro-controller. It is built to address a very specific set of design constraints as efficiently as possible.
It takes a while to see the absolute beauty and some of the reasons for the design decisions.
As you know, every instruction you add to an assembly language adds some latency to the responsiveness of the chip... at least under some circumstances of usage. And any strategy you use to cope with this fact also imposes penalties... make too many compromises and there goes your usable bandwidth.
I personally think there are too many instructions.
Rich
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Post Edited (Paul Baker) : 1/8/2009 7:47:48 PM GMT
For a good example of array acess also check out my keyboard driver. It acess a 2D array made up of bytes... stored in longs (that's why its 2D). Its a bit hard to follow but it's a very good example.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker