
PicoC: a very small C interpreter for scripting - rw-
http://code.google.com/p/picoc/
======
jakevoytko
Language interpreters are great for experimenting with new or buggy pieces of
code - just experiment at the prompt and copy what works into a file for
posterity. I've started looking through the parsing code for PicoC, and its
all nice and readable. But I'm surprised this was used in an actual system,
embedded or not. C is an absolutely miserable language whose saving graces are
executable size and speed. It lacks reasonable features to use for scripting,
like code-as-data in Bash or the dynamism of Python and Ruby. There are even
embedded scripting languages like LUA. What does C offer as a scripting
language, except perhaps familiarity?

~~~
listic
As you suggested, it offers the possibility to switch from interpreted to
compiled code at no extra effort.

------
mahmud
I used Ch[1] in a commercial product and I would highly dis-recommend C as a
scripting language. Something has to be said for high-level semantics,
dynamism and syntax designed for interactive work. I find Lisp, Lua and Groovy
to be joy to work with, but C is not an ideal extension/embedded/scripting
language. Use something easier.

<http://en.wikipedia.org/wiki/Ch_interpreter>

------
igravious
The links for these should read (code.google.com)

~~~
shrikant
Yep, time to add google.com to the "long domain" list . (See
<http://github.com/nex3/arc/blob/arc3.1/news.arc#L1556>)

------
imurray
See also: <http://bellard.org/tcc/> a compiler, but small and #!tcc can be put
at the top of .c files to make them scripts.

Also see: <http://root.cern.ch/drupal/content/cint> — an interpretor, but
large.

~~~
Erwin
TCC has two even more cool things:

1) a library that lets you compile C code within a process, relocate it and
execute it. This is rather faster than shelling out to run gcc to create a
shared object and open it using dlopen.

2) an awesome 2004 demonstration where TCC was used as a boot loader. Take the
Linux kernel source (slightly modified to remove some of the gccisms), add
TCCBOOT and reboot the machine: as part of the boot process TCC recompiles the
kernel and the continue to execute the freshly compiled kernel -- all in 15
seconds: <http://bellard.org/tcc/tccboot.html>

~~~
mahmud
I really love Fabrice, but "TCC" will, forever, remain Turbo C, not Tiny C.

DOS weenie pride!

~~~
dugmartin
Ctrl+F9 ftw.

------
jacquesm
How refreshing to see something that only has 'readline' as a dependency and
otherwise just requires a working C compiler and 'make'.

~~~
jrockway
Yeah. Why reuse something when you can write it yourself!

~~~
RiderOfGiraffes
I was wondering if you really meant that, given that this is intended to be
useful in embedded applications. To try to get a feel for the sort of
programming you do and the sort of opinions you hold, I checked your profile -
Bang - there's the answer right there:

    
    
      > I'm not trolling:
      > I actually think that.
    

Is it really the case that you don't see the point in writing a minimal,
small, clean, self-contained system that has no external dependences and is
directly applicable and useful for embedded systems.

~~~
euroclydon
Just curious: Is it trolling, if I write out a strong opinion, that I don't
necessarily believe, but that sounds reasonable to me, on a topic I'm trying
to figure out what to believe, and then, when my sentiments get refuted, I say
to myself, "Okay, now there's a reasonable way to think."

~~~
scott_s
No, because you're interested in honest communication. But it would be more
honest to phrase the strong opinion as "I don't necessarily believe _X_ , but
it sounds reasonable to me. Is there anything wrong with that reasoning?"

------
davidw
I wonder how it compares to other small systems like Lua, or, say Antirez' Jim
interpreter, in terms of speed and features.

~~~
antirez
Hey David, what I think it's cool about picoC is that you can use it in places
where you need to script at "hardware" level, like in robotics, embedded
systems, and alike.

Otherwise it is probably better to use Lua for instance, since I bet it is
much faster (I just read part of the PicoC implementation and it is a pretty
straightforward interpreter, very cool to read but hardly the faster) and
safer.

~~~
davidw
Presumably, it wouldn't be _that_ hard to create some Lua functions to
interface with memory addresses, I would think.

~~~
antirez
Yes but it's a pain to write complex code accessing memory when you need high
level functions, can't simply cast pointers to C structures and alike.

------
antirez
Very cool, there is even an interactive prompt. I wonder how hard is to make
this interpreter "safe".

~~~
rw-
define "safe". :)

~~~
antirez
Running every kind of script will never corrupt the application memory :)

------
sgt
Personally I would use Forth for this. PicoC looks interesting but if I were
to weigh my options (i.e. PicoC vs Forth in his example app UAV-onboard
system, I would definitely go Forth).

~~~
listic
Care to explain your reasoning behind this?

As I understand, the main appeal of using C as a scripting language is the
fact that you use _the same_ language in compiled and interpreted part of your
application.

Drawbacks of using C interpreter for scripting could include large footprint
and external dependencies, but as far as I can understand, they are not the
case here.

So what is your reasoning for Forth?

~~~
sgt
In the case of embedded programming, Forth is often made for the job. C is
great for embedded programming too, and you can always mix the two languages.
C isn't made for scripting, and hacks like PicoC don't appeal to me since it
will always remain a hack.

While not exactly a scripting language per se, Forth does have amazing
interactive capabilities. It's extremely light-weight and it's easy to
implement a new Forth on a new hardware architecture. Footprint issues aside,
development time in Forth is usually shorter, and the ability to connect
directly to a device's Forth "shell" and try out Forth words (functions),
create new words, play around with hardware in real-time is invaluable.

Forth code is less readable if you don't know Forth, and occasionally Forth
programmers write ugly code, but that is definitely the case for embedded C
programmers too.

------
nitrogen
Would this be allowed in an iPhone application, since it's all C?

~~~
rw-
AFAIK no programs are allowed which interpret code.

~~~
brownleej
Actually, Apple allows interpreted code under certain circumstances. Link
provides more details. I'm not sure how helpful it would be in this case,
though. My understanding is that the main motivation for having scripted
languages as a small part of an app, as this rule allows, is for game engines
which have high-performance graphics stuff in C, and some of the application
logic in a language like Lua. The use of a scripting language can reduce
development time, but if you were using C, you might as well compile it.

[http://arstechnica.com/apple/news/2010/06/devs-cautiously-
op...](http://arstechnica.com/apple/news/2010/06/devs-cautiously-optimistic-
about-ios-4-nonnative-code-change.ars)

