Lookup Tables in Assembler
Robert Schade
Posts: 27
Hi guys
I've been trawling through the forum and can't find anything regarding lookup tables.
Any suggestions would be very helpful.
I've tried the following code to point to labels in the RES section but with no success.· The label acc_x_val is the first one in the list
of data I want to point to and the variable tel_data is the info I want to transmit via Manchester encoding (that works fine).
······················· mov···· table_pntr, #acc_x_val
······················· mov···· tel_data, table_pntr
Any help would be appreciated.
Thanks
Rob
I've been trawling through the forum and can't find anything regarding lookup tables.
Any suggestions would be very helpful.
I've tried the following code to point to labels in the RES section but with no success.· The label acc_x_val is the first one in the list
of data I want to point to and the variable tel_data is the info I want to transmit via Manchester encoding (that works fine).
······················· mov···· table_pntr, #acc_x_val
······················· mov···· tel_data, table_pntr
Any help would be appreciated.
Thanks
Rob
Comments
mov table_pntr, #acc_x_val
add table_pntr,someoffset 'offset into the table
mov tel_data, table_pntr
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
With a propeller you have to use self-modifying code to do table lookup.
Offset·keeps the·number of the element in your lookup table that you want to access.
The NOP is needed in this case, as the propeller prefetches the next instruction in the execution pipeline before execution step of the previous instruction. Of course in most programs you can put a useful instruction there instead.
Have a look at the sticky threads. There are some links to documents that describe PASM programming very good.
Post Edited (MagIO2) : 12/4/2009 2:01:35 PM GMT
Rob
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObEx Forum
OnePinTVText driver: ObEx Forum
Something like this:
By the way "lookup" is a reserved word and will not compile here.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Ah ... thanks heater.
This will gonna be a funny thread, if we continue to point to others mistakes and do corrections here and there ;o)
I know that you only gave an excerpt of code, but newbies might think it's OK to simply end a PASM program by not adding instructions any more. But what happens after the lukup mov result, 0-0 instruction in your case? Well it depends on the data that's stored in the lookup table, so anything can happen. Maybe some pins are switched to output which could cause shortcuts.
...
In PASM you should stay in a loop or execute the cogstop instruction if you are done.
Should you have further questions please don't hesitate to ask. There are a lot of people here able to help.
MagIO: Yes, you are correct in the point that the 3rd line only moves a pointer to the data. However, it is not clear that that is not what is required by Rob as he states that it works. From a 2 line piece of code quoted I pointed out the missing offset.
Heaters excerpt was originally from a lookup I use. It was not given as a complete example as it was not called for in the original question. I have also used hub lookups (see my Faster Spin Interpreter).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
What will happen after lukup then?
1) It executes the instruction at "result" which in this case is the number 51 because the looked up offset was zero and the first entry of the table was replaced with 51. This is a NOP so no harm done, yet.
2) It executes the instruction at "offset" which is zero and also a NOP. No harm done, yet.
3) It executes whatever is next in the COG. That will be whatever followed this DAT data in HUB memory from where it was loaded when the COG started. Unknown result.
We should be able to write some seriously obfuscated code using that feature of HUB loading. For example I write code for 2 COGS one after the other in a DAT section. The first COG ends up executing the second COGs code after it has done its own.
Skip any comments in the code and let people work out what it does [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Sorry, yes, welcome. I also missed that you are such a recently new member here.
Hope we haven't over complicated the issue for you.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
MagIO is providing a good service to visitors by pointing out things that are questionable.
There are many ways to interpret questions and solutions.
A debugger can help track how code works. I took the liberty of rewriting cluso99's table lookup for demo.
Note how each output of the debugger corresponds to the state of the PASM. Some dumps are mixed for clarity.
Edit: The first example was not a good one. This one is better since it does not violate pipeline issues.
A limit of single stepping debugger like this is that pipeline problems can not be correctly detected.
Setting a breakpoint and letting the COG run freely would show the problem though.
The given example can be further optimized.
Post Edited (jazzed) : 12/4/2009 5:50:18 PM GMT
Graham
this is amazing, I really didn't think I would get much of a response!
The program is for a logger which interrogates several peripherals via I2C or 1wire interface and also digitises a full frame of video. The video is sent while the telemetry cog gets the data after which the data is sent during the frame capture period (40mS minimum), I need to write the data values to the table and then send them all together in a bit stream along a 30,000 feet cable at about 12Kbaud (non standard value).
Hope that explains a bit more about the application.
Thanks again for the help.
Rob
PS @jazzed how is the propalyser update going??
Post Edited (Robert Schade) : 12/4/2009 10:47:53 PM GMT
Cheers.
The FullDuplexSerial (from the OBEX) has an example of cyclic buffers in hub which may be useful to look at. They are fixed at 16 bytes, but I have a modified version which allows up to 512 bytes (in powers of 2). It's called FullDuplexSerial_rr00x (x maybe 4?). It is in the latest ZiCog thread (link in my signature) and is part of the ZiCog code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
@Cluso99 One cog should be able to do it all without using the Hub at all because I have so much time to get the data and then I have to send 20 12bit values in a continuous MAnchester Encoded bit stream. If I got all the data in using the hub I would still have to use a cog to send it Manchester encoded. The cable is little more than a "wet piece of string" electrically speaking and is horrendous on the signal.
Thinking on it, using spin in the Hub to get the data would probably work okay but I would then have to synchronize with the cog doing the video transmission so I didn't corrupt that data and only transmitted when the video cog was capturing a frame.
Options, options, so many options! Props are great for this kind of thing!
Thanks
Rob
I don't understand your statement here. Perhaps you are misunderstanding the props capabilities here. There are multiple cogs, so the timing should not be an issue if the data is not being shared. Each cog gets it's own access time to the hub. The buffer can either be in cog or you could place it in hub even if the same cog transmitted it. This depends on whether you have enough cog space for your pasm code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Graham
I only need 20 longs although I could combine data and halve that as the values are 12bits
Rob
I'm assuming you are putting a grabbed frame in to 20longs?
Graham
The "pixel clock" reading from the ram runs at 10MHz which gives me 520 x 288 of proper video. There's only 288 lines as that is all there is for composite video when all the blank lines are removed so I don't bother to send them as it's a waste of bandwidth.
Rob
Sounds a really interesting project, may I ask for some specifics about the camera and ram chip?
Cheers,
Graham
Rob
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
Rob
Post Edited (Robert Schade) : 12/8/2009 12:03:06 PM GMT