String() Vs DAT

Ray0665

I have been using DAT statements for all my strings rather than the inline string() statement for some time now. And tonight with some idle time on my hands I was wondering if using the DAT statement had any advantage over the inline. My gut was saying yes but then there is this matter of hub ram access so I just wasn't sure. Only one way to find out.... Two identical loops so the only difference is string() vs DAT
test it... Now I know for sure.

CON
  _clkmode = xtal1 + pll16x
  _xinfreq = 5_000_000
  count = 10000
obj
  pst: "Parallax serial Terminal"
dat
  msg byte "text",0

pub main| t,t1,t2,s
pst.start(115200)
repeat 50
   pst.str(string(13,"first "))
   t := cnt
   repeat count
'     s := string("text")
     s := @msg
   t1 := cnt - t
   pst.dec(t1)

   pst.str(string("   second "))
   t := cnt
   repeat count
     s := string("text")
'     s := @msg
   t2 := cnt - t
   pst.dec(t2)
pst.str(string(13,"Avg Difference (in clock cycles):"))
pst.dec((t2-t1)/count)
pst.newline

Mike Green

There's no advantage in terms of speed since it all gets put into hub memory eventually. The main advantage of STRING() is convenience since you only need a few characters added to the source program right at the point of usage of the address. The main disadvantage is that there's no constant pool where duplicates are detected and removed (by using the existing copy). If you have two string constants of the form STRING("hello"), you'll have two copies of the string. If you put the strings into a DAT section, hopefully you'll notice if it's already there and will use the existing string label for all additional uses.

Ray0665

Mike
Normally I would defer to what you say because of all the good advice you have given, however in this case I have the program as evidence and it shows a difference of 16 clocks between the two. I did two repeat loops with nothing but the assignment of the strings address to a variable in the loop and recorded the elapsed time in clocks of the loop. One used DAT the other STRING(). The conclusion is that dat is faster than String. If I missed something here please point it out so that I may learn from it.

Mike Green

You may be right. I'd have to look at the generated code and then look at how the Spin interpreter handles it. 16 clocks is only 200ns at 80MHz. You would need a tight loop or a lot of string references for that to matter much, particularly where you're not keeping a very close eye on other optimizations.

kuroneko

It's just down to encoding. @msg can be encoded in 2 bytes, string() - following the method code - requires 3. If you put some padding before @msg (for example long -1[64]) then both methods consume the same amount of cycles.

Dave Hein

The difference is in the number of bytes used to address the strings. The address for msg requires only one byte if it is located within the first 128 bytes of the object. Otherwise, it needs two bytes. The Prop tool always uses two bytes for string() even if the string is stored within the first 128 bytes. The Prop tool could use one byte for the string() address if it's within the first 128 bytes, but it doesn't use that optimization.

Ray0665

See this is what happens when smart folk have too much time on their hands.
I was just curious and had nothing to do. So now we know all about different encoding methods and the inner workings of the compiler - good stuff.
As Mike said 16 clocks is insignificant in light of other wasted cycles in any practical application.
And I thank you for the great info.