Shop OBEX P1 Docs P2 Docs Learn Events
Spin: what is the meaning of @scan{0} — Parallax Forums

Spin: what is the meaning of @scan{0}

as reading kuroneko scanline driver, there this code, and i don't know what is the meaning of the {0} ?

VAR
  long  frame, scan[quads]

PUB selftest : n

  driver.init(-1, @scan{0})

Comments

  • Dave HeinDave Hein Posts: 6,347
    edited 2018-11-11 14:28
    @scan{0} is identical to @scan, which is the starting address of the scan array. The code could have also used @scan[0], but this would generate additional byte codes to add a zero offset. The use of {0} is just a way to add a comment that indicates that element zero is being addressed.
  • Mark_TMark_T Posts: 1,981
    edited 2018-11-11 22:25
    Hmm, Why not comment at end of line,
      driver.init(-1, @scan)  ' equiv. to @scan[0]
    
    less confusing
  • yetiyeti Posts: 818
    edited 2018-11-11 23:05
    Hmm, Why not comment at end of line,
    Why not comment inline?

    Probably a matter of taste. I prefer inline. That way the eyes don't need to jump between code and comment. The comment is exactly where it matters.
      driver.init(-1, @scan)  ' equiv. to @scan[0]
    
    "equiv to @scan[0]"?
    Who? The whole line? Or which part?
    "@scan is equiv to @scan[0]" would be exact but really would repeat too much.
  • laurent974 wrote: »
    as reading kuroneko scanline driver, there this code, and i don't know what is the meaning of the {0} ?
    
    VAR
      long  frame, scan[quads]
    
    PUB selftest : n
    
      driver.init(-1, @scan{0})
    
    That syntax confused me at first too until I realized that "{0}" is just a comment. The expression is really just "@scan".

  • Dave HeinDave Hein Posts: 6,347
    edited 2018-11-12 00:06
    I think I'm guilty of introducing the {0} notation. I thought it made code like that clear. So instead of writing something like
      x := buffer;
      y := buffer[1];
      z := buffer[2];
    
    I thought it was more clear to write
      x := buffer{0};
      y := buffer[1];
      z := buffer[2];
    
    Of course, "x := buffer[0]" would make it obvious that x is the first element of the buffer array, but it generates more code and requires more cycles than "x := buffer{0}".

    In retrospect it's better to just write "x := buffer".

    EDIT: I actually first used the {} notation in my malloc code, where each malloc'ed chunk contained a header with the chunk size and a pointer to the next chunk. The code looked something like this.
    CON
      HDR_NEXT = 0
      HDR_SIZE = 1
    
    PUB func(chunk_ptr) : next, size
      next := LONG[chunk_ptr]{HDR_NEXT}
      size := LONG[chunk_ptr][HDR_SIZE]
      ...
    
    It sort of makes sense in this context.
  • Dave Hein wrote: »
    I think I'm guilty of introducing the {0} notation. I thought it made code like that clear. So instead of writing something like
      x := buffer;
      y := buffer[1];
      z := buffer[2];
    
    I thought it was more clear to write
      x := buffer{0};
      y := buffer[1];
      z := buffer[2];
    
    Of course, "x := buffer[0]" would make it obvious that x is the first element of the buffer array, but it generates more code and requires more cycles than "x := buffer{0}".

    In retrospect it's better to just write "x := buffer".

    EDIT: I actually first used the {} notation in my malloc code, where each malloc'ed chunk contained a header with the chunk size and a pointer to the next chunk. The code looked something like this.
    CON
      HDR_NEXT = 0
      HDR_SIZE = 1
    
    PUB func(chunk_ptr) : next, size
      next := LONG[chunk_ptr]{HDR_NEXT}
      size := LONG[chunk_ptr][HDR_SIZE]
      ...
    
    It sort of makes sense in this context.
    Yes, there it makes it clear that you're accessing a "struct" field.

  • Dave Hein wrote: »
    Of course, "x := buffer[0]" would make it obvious that x is the first element of the buffer array, but it generates more code and requires more cycles than "x := buffer{0}".

    In an optimizing compiler the two expressions would be the same -- PropGCC and fastspin, for example, would both generate the same code for these. It'd be nice if the "official" Spin2 compiler had some simple peephole optimizations to do really obvious optimizations like this.


  • GenetixGenetix Posts: 1,739
    edited 2018-11-12 20:21
    I know it's a matter of style but I prefer to put little comments like that indented under the line.
    PUB selftest : n
    
      driver.init(-1, @scan)
         ' An array will default to element 0 if an element number is not given
    
  • Genetix wrote: »
    I know it's a matter of style but I prefer to put little comments like that indented under the line.
    Diversity rocks! \o/
Sign In or Register to comment.