A pre-processor for Ravi

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

A pre-processor for Ravi

Dibyendu Majumdar
Hi

One of the problems I have is how to improve the performance of  small
Lua functions that don't do much but are there for convenience. The
overhead of a Lua function call is quite high - so what I need is a
way to inline the functions. Not being a compiler guru this is
somewhat beyond my capabilities right now. So as a cheaper alternative
I am thinking of introducing is support for macros as in C - allow
user to define macros which are preprocessed textually before the
parser runs. So I am looking for a small and fast opensource
implementation of a macro preprocessor - the main capability I need is
the equivalent of #define in C.

The license needs to be liberal so that it is compatible with MIT
license. It should be written in C so that I can integrate it in Ravi.

If anyone here knows of an implementation that I should look at please
let me know.

Thanks and Regards
Dibyendu

Reply | Threaded
Open this post in threaded view
|

Re: A pre-processor for Ravi

Nagaev Boris
On Sat, Aug 1, 2015 at 2:48 PM, Dibyendu Majumdar
<[hidden email]> wrote:

> Hi
>
> One of the problems I have is how to improve the performance of  small
> Lua functions that don't do much but are there for convenience. The
> overhead of a Lua function call is quite high - so what I need is a
> way to inline the functions. Not being a compiler guru this is
> somewhat beyond my capabilities right now. So as a cheaper alternative
> I am thinking of introducing is support for macros as in C - allow
> user to define macros which are preprocessed textually before the
> parser runs. So I am looking for a small and fast opensource
> implementation of a macro preprocessor - the main capability I need is
> the equivalent of #define in C.
>
> The license needs to be liberal so that it is compatible with MIT
> license. It should be written in C so that I can integrate it in Ravi.
>
> If anyone here knows of an implementation that I should look at please
> let me know.
>
> Thanks and Regards
> Dibyendu
>

Hi,

I think it is not an ideal direction to evolve Ravi. C macros have
many disadvantages. And you make the language more complicated.
Optimizing inlinable functions is more interesting direction and it
doesn't require any changes in the language. And you should be a
compiler guru to develop a good language.

Here is some simple approach you can try. I am not a compiler guru, so
this approach may not work.

Find a function similar to macro definition and replace it with a
"macro" internally:

local function xxx(aaa)
  return bbb
end

->

#define xxx(aaa) bbb

where aaa is a list of arguments and bbb is an expression.

The following is required:
 * a set of xxx's upvalues must belong to the set of upvalues of a
code where xxx is inlined. It is satisfied if xxx is used in same
scope where it is defined
 * value of xxx must not change. If it is changed, it must be
de-inlined (and maybe reinlined) in all code using it. So you have to
track all such code.

--


Best regards,
Boris Nagaev

Reply | Threaded
Open this post in threaded view
|

Re: A pre-processor for Ravi

Christian Thaeter
In reply to this post by Dibyendu Majumdar


On 2015-08-01 12:48, Dibyendu Majumdar wrote:

> Hi
>
> One of the problems I have is how to improve the performance of  small
> Lua functions that don't do much but are there for convenience. The
> overhead of a Lua function call is quite high - so what I need is a
> way to inline the functions. Not being a compiler guru this is
> somewhat beyond my capabilities right now. So as a cheaper alternative
> I am thinking of introducing is support for macros as in C - allow
> user to define macros which are preprocessed textually before the
> parser runs. So I am looking for a small and fast opensource
> implementation of a macro preprocessor - the main capability I need is
> the equivalent of #define in C.
>
> The license needs to be liberal so that it is compatible with MIT
> license. It should be written in C so that I can integrate it in Ravi.
>
> If anyone here knows of an implementation that I should look at please
> let me know.

If you want it simple, why not just use 'cpp' as is. the only change
required there would be to allow '#' at the start of the line, which
afaik will not conflict with existing lua syntax, except for multiline
strings and comments. But since legacy code won't use preprocessor
directives, again you can just make this switchable by a commandline
switch or a #pragma and default it to off.

Sidenote: I am already using 'cpp' for some offline processing
(generate different source flavors from one input file) by:

  sed -e 's/--#/#/g' | cpp -w -

with this I can use
 --#define foo bar
like pp directives
 

Otherwise, in the long run I would prefer a much saner
macro/metaprogramming solution, Think about metalua, maybe a 'little'
less features but some way to hook into the parse tree and manipulate
it at compile-time with lua code itself would be close to awesome.
possibly ravi's type system and some optimizers could be implemented
in this way already.


        Christian



>
> Thanks and Regards
> Dibyendu
>


Reply | Threaded
Open this post in threaded view
|

Re: A pre-processor for Ravi

Luiz Henrique de Figueiredo
In reply to this post by Dibyendu Majumdar
> So I am looking for a small and fast opensource
> implementation of a macro preprocessor

Try mcpp at http://mcpp.sourceforge.net/

Reply | Threaded
Open this post in threaded view
|

Re: A pre-processor for Ravi

Dibyendu Majumdar
On 1 August 2015 at 14:27, Luiz Henrique de Figueiredo
<[hidden email]> wrote:
>> So I am looking for a small and fast opensource
>> implementation of a macro preprocessor
>
> Try mcpp at http://mcpp.sourceforge.net/
>

Excellent - thanks very much for the link!

Regards

Reply | Threaded
Open this post in threaded view
|

Re: A pre-processor for Ravi

Dibyendu Majumdar
In reply to this post by Nagaev Boris
On 1 August 2015 at 13:16, Nagaev Boris <[hidden email]> wrote:
> I think it is not an ideal direction to evolve Ravi. C macros have
> many disadvantages. And you make the language more complicated.
> Optimizing inlinable functions is more interesting direction and it
> doesn't require any changes in the language. And you should be a
> compiler guru to develop a good language.

Agreed but it is not certain that I will ever be a compiler guru (the
kind of stuff I do in my day job is completely unrelated to Lua, Ravi
or writing compilers!)

Regards

Reply | Threaded
Open this post in threaded view
|

Re: A pre-processor for Ravi

Dibyendu Majumdar
In reply to this post by Christian Thaeter
On 1 August 2015 at 13:46, Christian Thaeter <[hidden email]> wrote:
> Otherwise, in the long run I would prefer a much saner
> macro/metaprogramming solution, Think about metalua, maybe a 'little'
> less features but some way to hook into the parse tree and manipulate
> it at compile-time with lua code itself would be close to awesome.
> possibly ravi's type system and some optimizers could be implemented
> in this way already.
>

It is my hope that one day I will have new (alternative) parser /
compiler infrastructure for Lua that generates ASTs and allows all
kinds of tooling & optimizations. Lua's existing parser is designed
for speed and memory efficiency - so it is harder to extend it. In
fact I have not yet seen an independently implemented parser / byte
code generator for Lua - everyone seems to just port and enhance the
official versions. In my case I did the same for 2 reasons: a) I can't
beat the current implementation when it comes to speed and memory
efficiency, and b) the code generation is quite hard to follow, so I
am not yet sure I understand how it works even after 6 months (but
then maybe writing my own will solve this!).


Regards
Dibyendu