LCD library

[Mike K]

I've been using the LCD library lately and noticed that each additional lcd_write_char() call adds to the data area used.  The library shows that the functions are all declared as "pragma inline".  Do we need to do this?  It seems to defeat the purpose of reusable code.  When I remove the pragmas the code and data areas used drops dramatically and still functions as expected.

Regards,
Mike

[mattschinkel]

Is there much difference in speed with and without pragma inline?

 

Matt.

[Rob Hamerling]

Hello Mike,

I've experimented with 'pragma inline' in my programs and several
libraries, but I did not find THE best optimisation for all situations.
In general inline has advantage for short procedures with few arguments.
It'll save code memory and improve speed.
Without 'inline' instructions are needed to pass arguments and for
call/return (although the compiler optimizes returns frequently).
But it may not work out positively in all situations.

It would be nice to have a compiler option '-no-inline' which would
neutralize/switch-off all pragma inline directives.
It would even be nicer when the compiler would determine the best result.

BTW: I suspect that growth of data-memory is caused by using
-no-variable-reuse

Regards, Rob.

--
R. Hamerling, Netherlands --- http://www.robh.nl

[Mike K]

Hi guys,

I'm updating the LCD in a loop about 10x/sec.  I don't notice any performance difference.  I wouldn't expect any either, since the only thing that gets added by removing the "inline" is the call and return for the subroutine and the stack use for the parameters...which in this case is a single byte.

And isn't this the point to having a library?...to have blocks of code that get called over and over without taking up additional space?  Seems odd to me to have blocks of code that get repeated, especially since they aren't time sensitive.

Rob, you have a keen eye.  I am using "no-variable-reuse", but the code and data memory used is smallest with no "inline"s:

regular compile, with inlines: 866 program, 36 data
regular compile, w/o inlines: 483 program, 35 data
compile no-reuse, with inlines: 873 program, 88 data
compile no-reuse, w/oinlines: 483 program, 43 data

I favor removing the "inline"s.

Mike

[Sunish Issac]

I've already started enabling variable reuse and the effect is significant, many programs that hit out of memory on compilation would easily get space with variable reuse. Looks like the latest version of the compiler has no issue in the time taken for compilation even with variable reuse.

Also the best and greatest feature that I enjoy is passing strings to procedures, like printstring(serial_hw_data, "Hello world") without variable declaration.

Regards,
Sunish

Mike

--
You received this message because you are subscribed to the Google Groups "jallib" group.

To view this discussion on the web visit https://groups.google.com/d/msg/jallib/-/kDV1ddBgbowJ.

To post to this group, send email to jal...@googlegroups.com.
To unsubscribe from this group, send email to jallib+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jallib?hl=en.

[Rob Hamerling]

Hi Mike,

On 29-12-12 18:03, Mike K wrote:

> And isn't this the point to having a library?...to have blocks of code
> that get called over and over without taking up additional space? Seems
> odd to me to have blocks of code that get repeated, especially since
> they aren't time sensitive.

Depends! True when the expanded code of an inline block is larger than
of call/return + parameter passing. Parameter passing is different for
constants and variables, so inline can be fine in one situation but not
in another.


> .. the code and data memory used is smallest with no "inline"s:

>
> regular compile, with inlines: 866 program, 36 data
> regular compile, w/o inlines: 483 program, 35 data
> compile no-reuse, with inlines: 873 program, 88 data
> compile no-reuse, w/oinlines: 483 program, 43 data
>
> I favor removing the "inline"s.

The difference is much bigger than I expected! Would you mind to send
me your program (by personal mail) for analysis?

[Mike K]

Hi Rob,

Okay, I sent it to you.  I'm still trying to understand why the "inline"s are there, though.  Most of the other libraries don't have them.  I would say there needs to be a reason to have them, not a reason to remove them.

Regards,
Mike

[Rob Hamerling]

Hi Mike,

On 30-12-12 03:56, Mike K wrote:

> Okay, I sent it to you. I'm still trying to understand why the "inline"s
> are there, though. Most of the other libraries don't have them. I would
> say there needs to be a reason to have them, not a reason to remove them.

Thanks for sending me your program. I've analysed it, but first:

A compare with other libraries, written by other people, at another
point in time, with a different version of the compiler, won't give a
clue why the inlines are in the lcd libraries....

By browsing the old sources we might find when the inlines were
introduced and by whom (probably me!), but I don't expect that will be
of much help too.

The reason for the growth of the hex file by using pragma inline is
caused by its propagation to called procedures, even when these don't
have the pragma inline. I expected that a procedure like

> procedure __lcd_write(byte in value) is
> pragma inline
> __lcd_write_nibble(value >> 4)
> __lcd_write_nibble(value)
> end procedure

would expand in two inline calls to __lcd_write_nibble() in stead of a
single call to __lcd_write() of which the body would have the expansion
of the two calls to __lcd_write_nibble(). This would save some code
memory when __lcd_write_nibble() is not called frequently.

But it appears that the __lcd_write_nibble is expanded inline too!
This propagation to called procedures is not explicitely mentioned in
the compiler documentation. We must inform Kyle.

It could be that his behaviour of the compiler has changed after the
pragma inlines were added to the library. A check with 2.4o and 2.4n
showed no difference and I don't have older versions ready available.

Provisional conclusion: the use of 'pragma inline' in the libraries must
be re-evaluated! Would you be so kind to open an issue at googlecode?

[Joep Suijs]

Hi guys,

Just saw this tread today and did not have a chance to study it in detail.

So just fyi: i have fiddled with inline in the lcd lib to reduce stack useage, which was so high the lib was hardly usable on an 16f chip.

Speed is not an issue; it is a balance between flash, ram and stack use. 

Joep.

Op zondag 30 december 2012 schreef Rob Hamerling (robham...@gmail.com) het volgende:

--
You received this message because you are subscribed to the Google Groups "jallib" group.

[Mike K]

Hi Joep,

Perhaps this was an issue with a previous version of the compiler?  The program that I'm using, that prompted this thread, uses the same amount of stack whether with or without the "inline"s.

Mike

[Joep Suijs]

Hi Mike,

It was without doubt a previous compiler version but I don't recall any recent compiler changes that would have influenced this.

The result do vary depending on the functions you call. At the time I spend quite some time balancing code and save two stack levels ( which is lot on an 16f chip). I used the sample files fot this, so the optimisations might be slightly biased to those.

IMHO it is a bad idea to forbid the use of pragma inline statements in libraries. Its use would probably be limited to internal function or very small api functions.

In this particular case my message is: change the lib if there is a serious is, but be carefull. Use at least the samples to verify the effect and avoid any increase of stack useage.

Joep.

Op zondag 30 december 2012 schreef Mike K (upand_...@yahoo.com) het volgende:

--
You received this message because you are subscribed to the Google Groups "jallib" group.

To view this discussion on the web visit https://groups.google.com/d/msg/jallib/-/D2UI8LVZiBgJ.

[mattschinkel]

I assume you are speaking of this procedure in lcd_hd44780_common.jal:

 

procedure lcd_write_char(byte in data) is
   pragma inline
   _lcd_write_data(data)
end procedure

What I remember from past compiler versions is that using inline here would be a good thing, and save 1 byte of data and some code. This would have used the same amount of space as if you were only using _lcd_write_data directly. If this is not the case, maybe kyle can fix it. A solution for you now may be to use _lcd_write_data instead of lcd_write_char.

 

A solution to deminish the affect of inline is to wrap lcd_write_char into a new procedure without inline. Put this in your code of course, not the lib.

 

procedure lcd_write_char_no_inline(byte in data) is
   lcd_write_char(data)
end procedure

Rob, procedures like lcd_write_data or lcd_write_nibble sound like they should use inline for speed purposes.

 

When I was working with my color GLCD, i noticed a huge visible difference in speed since my glcd had a lot of pixels to write to. The size of my screen is 320x240, so that is 76800 writes to clear the screen with a loop. I suppose the same issue may not occur on hd44780 due to less pixels.

 

It would be interesting to know the speed difference clearing the screen using the stopwatch library.

 

Matt.

On Friday, December 28, 2012 10:34:56 PM UTC-5, Mike K wrote:

[Sebastien Lelong]

Hi guys
Maybe I miss something but isn't a procedure alias enough in this case ?
Cheers
Seb

--
You received this message because you are subscribed to the Google Groups "jallib" group.

To view this discussion on the web visit https://groups.google.com/d/msg/jallib/-/nRZulHBiufEJ.