knowledge-database (beta)

Current group: comp.compilers

Embeddable and Extensible Languages

Embeddable and Extensible Languages  
PlayDough
 Re: Embeddable and Extensible Languages  
Thant Tessman
 Re: Embeddable and Extensible Languages  
Ken Rose
 Re: Embeddable and Extensible Languages  
Jürgen_Kahrs
 Re: Embeddable and Extensible Languages  
Jean-Marc Bourguet
 Re: Embeddable and Extensible Languages  
Georgios Petasis
 Re: Embeddable and Extensible Languages  
Tom Verbeure
 Re: Embeddable and Extensible Languages  
Jean-Christophe Le Lann
 Re: Embeddable and Extensible Languages  
PlayDough
 Re: Embeddable and Extensible Languages  
Thant Tessman
 Re: Embeddable and Extensible Languages  
Luiz Henrique de Figueiredo
From:PlayDough
Subject:Embeddable and Extensible Languages
Date:12 Jan 2005 23:00:41 -0500
I've spent quite a bit of time over the last couple of months
evaluating several embeddable and extensible languages. However, I've
yet to find one that really strikes my fancy for our project.

I'm working on a project that would embed a language into our
simulation system for FPGA and ASIC design. This language would be
used to control a testbench through the PLI/FLI provided by the
simulator. Preferrably, it would be C (or C like) since our end users
are most familiar with C. Also, we would like the ability to have
multiple source files or packages that would allow our tools team to
develop support tools.

I've looked at Lua, Python, Pike, Ici, Eic, Ch, Cint, S-Lang, Small,
elastiC, Simkin, and even some small, homegrown projects. However,
they all have one problem or another. I really like Ch, but it is
quite expensive (~$2k). Or Small, but it doesn't provide basic I/O and
support is sparse. Or S-Lang and issues with syntax for our customers
(internal).

So far, I've narrowed it down to Lua and Python. I like the Lua
syntax, but the support base isn't as big as Python. But with Python,
I fear that the syntax could be problem for the customers of our
project. Both have the problem of not being capable of running
multiple contexts (outside of the interpreter).

I often think a virtual machine approach is the best because it allows
me to have several contexts (realized in separate virtual machines).
At worst, I can get by with a single context but it limits the
generality I'm looking for. On the virtual machine tack, I looked into
Java or the CLR, but interfacing such a beast with our simulator
doesn't seem feasible. I've even thought of writing our own virtual
machine to execute code, but then we'd have to invest in a compiler.
Years ago I created an interpreted version using lex and yacc, but that
was for a different company and I don't have it anymore. And
re-creating it doesn't sound like fun, nor was it feature rich.

So, given this huge lead-in, I'm wondering if anyone has tackled a
similar problem and what did they do? Or, can anyone recommend a
language that is embeddable, extensible, has a good set of features
(file and console I/O, math operations, even if through
packages/add-ons). Perferably it has a reasonable footprint, it
portable across platforms (Linux and Win32), and support for multiple
contexts.

I know this is probably a tall order, but before I settle with either
Lua or Python, I'd like to get more opinions. Over the years I've
found the newsgroups an indispensible source and I'd appreciate any
responses.

Pete
From:Thant Tessman
Subject:Re: Embeddable and Extensible Languages
Date:14 Jan 2005 00:43:58 -0500
PlayDough wrote:

> I've spent quite a bit of time over the last couple of months
> evaluating several embeddable and extensible languages. However, I've
> yet to find one that really strikes my fancy for our project.

[...]

Have you looked at Scheme? Its syntax is as far from C as you can get,
but if you can get beyond that, I'm pretty sure at least one
implementation (Chez) will do exactly what you need. There might be
others.

-thant
From:Ken Rose
Subject:Re: Embeddable and Extensible Languages
Date:15 Jan 2005 20:57:03 -0500
Thant Tessman wrote:
> There might be others.

Maybe xlisp?

http://www.mv.com/ipusers/xlisper/

- ken
From:Jürgen_Kahrs
Subject:Re: Embeddable and Extensible Languages
Date:14 Jan 2005 00:43:44 -0500
PlayDough wrote:

> So, given this huge lead-in, I'm wondering if anyone has tackled a
> similar problem and what did they do? Or, can anyone recommend a
> language that is embeddable, extensible, has a good set of features
> (file and console I/O, math operations, even if through
> packages/add-ons). Perferably it has a reasonable footprint, it
> portable across platforms (Linux and Win32), and support for
> multiple contexts.

Tcl
http://www.tcl.tk/customers/success/edacad.html
http://www.tcl.tk/customers/success/testautomation.html

Guile
http://www.gnu.org/software/guile/docs/docs.html
From:Jean-Marc Bourguet
Subject:Re: Embeddable and Extensible Languages
Date:14 Jan 2005 00:40:43 -0500
"PlayDough" writes:

> I'm working on a project that would embed a language into our
> simulation system for FPGA and ASIC design. This language would be
> used to control a testbench through the PLI/FLI provided by the
> simulator. Preferrably, it would be C (or C like) since our end
> users are most familiar with C. Also, we would like the ability to
> have multiple source files or packages that would allow our tools
> team to develop support tools.
>
> I've looked at Lua, Python, Pike, Ici, Eic, Ch, Cint, S-Lang, Small,
> elastiC, Simkin, and even some small, homegrown projects.

Considering your target domain, I'd consider TCL as it is more or less
a de-facto standard extension langage used by EDA applications and so
there is a good chance that your users are already familiar with it.

> So far, I've narrowed it down to Lua and Python. I like the Lua
> syntax, but the support base isn't as big as Python. But with
> Python, I fear that the syntax could be problem for the customers of
> our project. Both have the problem of not being capable of running
> multiple contexts (outside of the interpreter).

I'm not sure what you want but multiple TCL interpreters can be run in
the same executable.

Another language you didn't name but which seems to have a signigicant
user base is Ruby.

Yours,
--
Jean-Marc
From:Georgios Petasis
Subject:Re: Embeddable and Extensible Languages
Date:14 Jan 2005 00:41:15 -0500
It seems odd that you haven't look Tcl (http://www.tcl.tk). For me its
by far the most advanced language when it comes to portability &
maturity of code (stable, easy to understand & extend).

It has also a graphical toolkit, its easy to extend through packages
(either in Tcl or C/C++), it has good I/O capabilities, but it can be
quite expensive. I know that exist version that even run in handheld
devices, but hou may have to investigate the details yourself.

I think that the best approach is to repeat this post in
comp.lang.tcl, where you can get answers from people who can better
understand you post (I am not sure what "multiple contexts" means :-))

George

"PlayDough" wrote in message
> I've spent quite a bit of time over the last couple of months
> evaluating several embeddable and extensible languages. However, I've
> yet to find one that really strikes my fancy for our project.
From:Tom Verbeure
Subject:Re: Embeddable and Extensible Languages
Date:15 Jan 2005 20:53:34 -0500
> It seems odd that you haven't look Tcl (http://www.tcl.tk). For me
> its by far the most advanced language when it comes to portability &
> maturity of code (stable, easy to understand & extend).

From what I understand of the original email, the intention is to use
have language to write behavioral models that interact with the
simulator cycle-by-cycle.

(Disclaimer: Despite my intense distaste for Tcl,) I agree that Tcl is
the best choice for a *command* language, that is, to control
simulator, set breakpoints etc. But I don't think it's a good language
to write functional hardware models. Python has a number of
constructs, like generators, that make it much easier to model a
cycle-based environment. (You may have a look at
http://jandecaluwe.com/Tools/MyHDL/Overview.html for some
inspiration.)

I know of a company that linked Python to a VHDL simulator and used
the python environment to mimic an external or internal processor.
(Basically, the python environment was driving an AHB bus.) I don't
know if they used multiple, concurrent, threads though.

Tom
From:Jean-Christophe Le Lann
Subject:Re: Embeddable and Extensible Languages
Date:22 Jan 2005 18:28:29 -0500
Le Wed, 12 Jan 2005 23:00:41 -0500, PlayDough a écrit :


> I've looked at Lua, Python, Pike, Ici, Eic, Ch, Cint, S-Lang, Small,
> elastiC, Simkin, and even some small, homegrown projects. However,
> they all have one problem or another. I really like Ch, but it is
> quite expensive (~$2k).

As far as I know, there are 2 distinct versions of Ch (standard and
professional). Standard edition seems to be free for both
non-commercial and commercial applications. Let me know if I am wrong.

I don't know if it is reentrant, however.

Jean-Christophe Le Lann
From:PlayDough
Subject:Re: Embeddable and Extensible Languages
Date:15 Jan 2005 20:57:49 -0500
PlayDough wrote:
> packages/add-ons). Perferably it has a reasonable footprint, it
> portable across platforms (Linux and Win32), and support for
> multiple contexts.

I wasn't abundantly clear on the above point (others have asked "what
do I mean exactly"), so I want to clarify the above point.

I would like to find a language with a reentrant interpreter. But
even this isn't totally accurate. Perhaps a C++ example might clear
up what I'm trying to do.

For example, I create a class:

class X
{
public:
X(const std::string& script_file);
void Run(void);

private:
Interpreter_context ctx;
};

And in the constructor, I do something like:

X::X(const std::string& script_file)
{
interp_init();
interp_create_context(&ctx);

load_script(&ctx, script_file);
}

void X::Run(void)
{
run_script(&ctx);
}

Now in the application, I would instantiate class X several times,
however, in separate threads. I don't have control over the thread
creation mechanism, nor the instantiation of the classes. I only have
control over the class I create.

However, as an example, I can do the following:

void* thread1(void* arg)
{
X x1("script1");

x1.Run();
}

void* thread2(void* arg)
{
X x2("script1");

x2.Run():
}

int main(void)
{
pthread_t thr1, thr2;

pthread_create(&thr1, 0, thread1, 0);
pthread_create(&thr2, 0, thread2, 0);

pthread_join(thr1, 0);
pthread_join(thr2, 0);
}

Nearly all the languages I've looked at have some soft of global,
static storage that prevents this type of mechanism from working. For
example, Ruby has ruby_init(). Ignoring issues of callback (language
extensions that call class methods), is there a language that
guarantees that x1's interpreter and x2's interpreter will not collide
in threads?

This is why I'm leaning towards Lua. It seems well behaved in this
respect.

Thanks,
Pete
From:Thant Tessman
Subject:Re: Embeddable and Extensible Languages
Date:22 Jan 2005 18:26:48 -0500
PlayDough wrote:

[...]

> Nearly all the languages I've looked at have some soft of global,
> static storage that prevents this type of mechanism from working. For
> example, Ruby has ruby_init(). Ignoring issues of callback (language
> extensions that call class methods), is there a language that
> guarantees that x1's interpreter and x2's interpreter will not collide
> in threads?

See Chez Scheme's notion of 'waiters' and 'cafes'. Also see
"call-with-current-continuation." It's a little hard to get your head
around at first, but with it you can build whatever kind of threading
suits your application. Really powerful stuff.

-thant
--
"When fascism comes to America, it will be wrapped in the flag and
carrying the cross." -- Sinclair Lewis, "It Can't Happen Here" (1935)
From:Luiz Henrique de Figueiredo
Subject:Re: Embeddable and Extensible Languages
Date:14 Jan 2005 00:42:47 -0500
PlayDough wrote:
>So far, I've narrowed it down to Lua and Python. [...]
>Both have the problem of not being capable of running
>multiple contexts (outside of the interpreter).

I'm not sure what you mean by the last sentence, but Lua can run multiple
independent states and multiple related states, with support for coroutines.
--lhf
   

Copyright © 2006 knowledge-database   -   All rights reserved