Shop OBEX P1 Docs P2 Docs Learn Events
Lookup Tables in Assembler — Parallax Forums

Lookup Tables in Assembler

Robert SchadeRobert Schade Posts: 27
edited 2009-12-08 11:58 in Propeller 1
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
«1

Comments

  • Cluso99Cluso99 Posts: 18,069
    edited 2009-12-04 13:37
    I think this might be what you are after

    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
  • MagIO2MagIO2 Posts: 2,243
    edited 2009-12-04 13:52
    @cluso99: wanna confuse newbies??? You add something to the variable table_pntr and then you copy just that value to tel_data ... that's not what we call a table lookup.

    With a propeller you have to use self-modifying code to do table lookup.
         mov table_pntr, #acc_x_val
         add table_pntr, offset
    
         movs lookup, table_pntr
         nop
    lookup:
         mov tel_data, 0-0
    


    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
  • Robert SchadeRobert Schade Posts: 27
    edited 2009-12-04 14:10
    thanks for a very quick response, very helpful.

    Rob
  • kwinnkwinn Posts: 8,697
    edited 2009-12-04 14:20
    @MagIO2, Seems to me cluso's way would also work and is actually shorter.
  • MagIO2MagIO2 Posts: 2,243
    edited 2009-12-04 14:44
    No, it won't. He has the content of table_pntr in tel_data afterwards. But table_pntr is only pointing to the adress that actually has to be read. To access the data at that place you have to inject the address into the mov statement by movs.
  • ericballericball Posts: 774
    edited 2009-12-04 15:10
    Note: You also may want to investigate keeping tables in HUB RAM instead of COG RAM. In some scenarios it takes fewers instructions and less cycles (if you can synchronize your code to HUB accesses)!

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Composite NTSC sprite driver: Forum
    NTSC & PAL driver templates: ObEx Forum
    OnePinTVText driver: ObEx Forum
  • heaterheater Posts: 3,370
    edited 2009-12-04 15:46
    You may also want to put a look up table at address 0 in the COG such that no pointer loading or offset addition is required, saves 2 instructions for each look up. Of course the first LONG of the table must be a JMP to the start of your code, at which point the JMP is overwritten with the correct table value:

    Something like this:

    DAT
            org   0
    enter
    table   jmp   #begin
            long  32
            long  45
            long  88
    '        .
    '        .
    begin   mov   table, #51        'Replace the jump in the first entry of table with the correct value.
    '        .
    '        .
            mov   result, 4         'Get table value at offset 4
    '        .
    '        .
            movs  lukup, someoffset 'Set offset (source) of lookup instruction
            nop                     'Wait for pipeline
    lukup   mov   result, 0-0       'Get tabe value at someoffset
    
    result     long  0
    someoffset long 0
    
    



    By the way "lookup" is a reserved word and will not compile here.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • MagIO2MagIO2 Posts: 2,243
    edited 2009-12-04 16:09
    @heater:
    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.
  • Cluso99Cluso99 Posts: 18,069
    edited 2009-12-04 16:31
    Rob: Firstly, welcome to the forum. I had not realised you were new. Secondly let me apologise for the tone in the replies. This is not normal in most threads.

    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
  • heaterheater Posts: 3,370
    edited 2009-12-04 16:35
    Quite so, not a complete PASM program.

    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.
  • heaterheater Posts: 3,370
    edited 2009-12-04 16:43
    Robert,
    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.
  • jazzedjazzed Posts: 11,803
    edited 2009-12-04 16:43
    Rob only looks like a new member because of his post count [noparse]:)[/noparse]

    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.

    {{
    Table test.
    }}
    
    con
      _CLKMODE      = XTAL1 + PLL16x
      _XINFREQ      = 5_000_000
       
    obj
      s : "FullDuplexSingleton"
      b : "BMAutility"
      
    pub start
      
        s.start(31,30,0,115200)       ' start the default serial interface
        waitcnt(clkfreq+cnt)          ' wait for user
        b.debug(@entry,0)             ' start debugger
    
    dat
    entry   org 0
    long    0 [noparse][[/noparse]8] ' debugger stub
    
                  jmp       #readtable
                  
    table_pntr    long 0            ' address 8
    tel_data      long 0            ' address 9
    someoffset    long 4            ' address 10
    
    wrdata        mov       tel_data, 0-0           ' 1 read content to tel_data
    readtable     movs      wrdata, #acc_x_val      ' 2 get the address into table_ptr
                  add       wrdata, someoffset      ' 3 add offset of item int the table
                  djnz      someoffset, #wrdata
                  jmp       #$
                  
    acc_x_val     long 0,   $11111111, $22222222, $33333333, $44444444
    
    



    Starting BMA Debugger ...
    
    BMA Debugger Started.
    PC 008 Ok>
    ?
    bx     : toggles breakpoint at COG address x
    c      : clears all breakpoints
    D      : dumps all COG values
    dx n   : dumps n COG values from x
    ftx n v: fill n HUB addresses with v from x with t type = b,w,l
    g      : run COG
    htx n  : dumps n HUB values from x with t type = b,w,l
    L      : lists/disassembles all COG values/instructions
    l      : lists/disassembles 16 instructions at current PC
    lx n   : list n instructions s starting at x
    pr     : prints special register values PAR, etc...
    px     : prints content of COG register number <hex>
    r      : resets pc back to starting position
    R      : restarts COG
    sx v   : sets value at COG address x = v
    z      : shows flags
    Enter  : single-step
    ?      : show this help screen
    
    PC 008 Ok>
    d 8 10
    
    008: 5C7C000D 00000000 00000000 00000004 A0BC1400 50FC1811 80BC180B E4FC160C
    010: 5C7C0010 00000000 11111111 22222222 33333333 44444444 923D0A38 37011A0B
    PC 008 Ok>
    PC 008 .      : jmp     5C7C000D   N D:000  083C01F3 S#00D           D=000  083C01F3
    PC 00D Ok>
    PC 00D .      : movs    50FC1811     D:00C  A0BC1400 S#011           D=00C  A0BC1411
    PC 00E Ok>
    PC 00E .      : add     80BC180B     D:00C  A0BC1411 S:00B  00000004 D=00C  A0BC1415
    PC 00F Ok>
    PC 00F .      : djnz    E4FC160C     D:00B  00000004 S#00C           D=00B  00000003
    PC 00C Ok>
    PC 00C .      : mov     A0BC1415     D:00A  00000000 S:015  44444444 D=00A  44444444
    PC 00D Ok>
    d 8 10
    
    008: 5C7C000D 00000000 44444444 00000003 A0BC1415 50FC1811 80BC180B E4FC160C
    010: 5C7C0010 00000000 11111111 22222222 33333333 44444444 923D0A38 37011A0B
    PC 00D Ok>
    PC 00D .      : movs    50FC1811     D:00C  A0BC1415 S#011           D=00C  A0BC1411
    PC 00E Ok>
    PC 00E .      : add     80BC180B     D:00C  A0BC1411 S:00B  00000003 D=00C  A0BC1414
    PC 00F Ok>
    PC 00F .      : djnz    E4FC160C     D:00B  00000003 S#00C           D=00B  00000002
    PC 00C Ok>
    PC 00C .      : mov     A0BC1414     D:00A  44444444 S:014  33333333 D=00A  33333333
    PC 00D Ok>
    PC 00D .      : movs    50FC1811     D:00C  A0BC1414 S#011           D=00C  A0BC1411
    PC 00E Ok>
    PC 00E .      : add     80BC180B     D:00C  A0BC1411 S:00B  00000002 D=00C  A0BC1413
    PC 00F Ok>
    PC 00F .      : djnz    E4FC160C     D:00B  00000002 S#00C           D=00B  00000001
    PC 00C Ok>
    PC 00C .      : mov     A0BC1413     D:00A  33333333 S:013  22222222 D=00A  22222222
    PC 00D Ok>
    PC 00D .      : movs    50FC1811     D:00C  A0BC1413 S#011           D=00C  A0BC1411
    PC 00E Ok>
    PC 00E .      : add     80BC180B     D:00C  A0BC1411 S:00B  00000001 D=00C  A0BC1412
    PC 00F Ok>
    PC 00F .      : djnz    E4FC160C     D:00B  00000001 S#00C           D=00B  00000000
    PC 00C Ok>
    PC 00C .      : mov     A0BC1412     D:00A  22222222 S:012  11111111 D=00A  11111111
    PC 00D Ok>
    PC 00D .      : movs    50FC1811     D:00C  A0BC1412 S#011           D=00C  A0BC1411
    PC 00E Ok>
    PC 00E .      : add     80BC180B     D:00C  A0BC1411 S:00B  00000000 D=00C  A0BC1411
    PC 00F Ok>
    PC 00F .      : djnz    E4FC160C     D:00B  00000000 S#00C           D=00B  00000000
    PC 010 Ok>
    d 8 10
    
    008: 5C7C000D 00000000 11111111 00000000 A0BC1411 50FC1811 80BC180B E4FC160C
    010: 5C7C0010 00000000 11111111 22222222 33333333 44444444 923D0A38 37011A0B
    PC 010 Ok>
    
    



    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
  • kwinnkwinn Posts: 8,697
    edited 2009-12-04 17:06
    @MagIO2, You are correct. I was thinking of tables in hub ram using rdlongs.
  • Graham StablerGraham Stabler Posts: 2,510
    edited 2009-12-04 17:29
    Didn't someone start a table of examples like this? I seem to remember writing one for look up tables. Lost in the myst probably.

    Graham
  • Robert SchadeRobert Schade Posts: 27
    edited 2009-12-04 22:40
    Hi guys

    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
  • jazzedjazzed Posts: 11,803
    edited 2009-12-04 23:28
    Robert Schade said...
    PS @jazzed how is the propalyser update going??
    I posted an update with time base corrections. I like the old one better though and may revisit that. If you have feedback, email me or post on the forum. Everyone here is eager to help and generally have good intentions. Sometimes patience is necessary [noparse]:)[/noparse]
    Cheers.
  • Cluso99Cluso99 Posts: 18,069
    edited 2009-12-04 23:39
    Rob: Much better description. Sounds like you want to just have a buffer that you can fill. As the data will no doubt be shifted to hub for another cog to send it, you may as well place it there in the first place.

    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
  • Robert SchadeRobert Schade Posts: 27
    edited 2009-12-05 07:31
    @jazzed thanks, will take a look

    @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
  • Cluso99Cluso99 Posts: 18,069
    edited 2009-12-05 07:58
    Robert: "I would then have to synchronize with the cog doing the video transmission"

    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
  • Robert SchadeRobert Schade Posts: 27
    edited 2009-12-05 08:27
    @Clusso99 Sorry, I didn't explain myself clearly. I meant synchronizing with the video transmission not the hub. I have one cog doing the frame capture and storing in ram as well as transmitting it up the 30,000 feet of cable and another cog getting the telemetry data and transmitting that up the cable. It's these two cogs that I have to synchronize because the data transmissions are mutually exclusive.
  • Cluso99Cluso99 Posts: 18,069
    edited 2009-12-05 08:33
  • Graham StablerGraham Stabler Posts: 2,510
    edited 2009-12-05 11:52
    How big is the frame? Cog ram is a little limited.

    Graham
  • Robert SchadeRobert Schade Posts: 27
    edited 2009-12-05 12:39
    Hi Graham

    I only need 20 longs although I could combine data and halve that as the values are 12bits

    Rob
  • Graham StablerGraham Stabler Posts: 2,510
    edited 2009-12-05 13:23
    I think the cog array is the way to go then.

    I'm assuming you are putting a grabbed frame in to 20longs?

    Graham
  • Robert SchadeRobert Schade Posts: 27
    edited 2009-12-05 18:40
    The frame is stored in a high speed dual-port ram chip and sent in about 5.6 seconds to the receiver so no storage needed in the cog. While that is being transmitted I interrogate the peripherals with the telemetry cog and when the video transmission cog has finished sending the cable is "free" so I can read from the telemetry buffer (20 longs) and send that on the cable.

    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
  • Graham StablerGraham Stabler Posts: 2,510
    edited 2009-12-05 21:13
    Sorry I meant to say it was not being stored in the 20 longs.

    Sounds a really interesting project, may I ask for some specifics about the camera and ram chip?

    Cheers,

    Graham
  • Robert SchadeRobert Schade Posts: 27
    edited 2009-12-05 22:13
    The camera is just a standard composite video out unit similar to those used in security systems and the ram is from Averlogic. The part number is AL422B and it's a 3Mbit unit specifically for video buffering. It only needs a clock to increment the address so no address lines needed. There's a read section and a write section with totally seperate controls making it ideal for the propeller.

    Rob
  • RaymanRayman Posts: 14,876
    edited 2009-12-06 13:35
    That AL422B looks very interesting!

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
  • Robert SchadeRobert Schade Posts: 27
    edited 2009-12-08 11:12
    See below for the post as I changed it to put the code in a box for clarity



    Rob

    Post Edited (Robert Schade) : 12/8/2009 12:03:06 PM GMT
  • Robert SchadeRobert Schade Posts: 27
    edited 2009-12-08 11:15
    Out of interest, how do you insert a program into a posting so it looks like the one Steve (jazzed) did?
Sign In or Register to comment.