Live data from Hacker News

PicoC: a very small C interpreter for scripting

code.google.com

21–30 of 47 posts

Re: PicoC: a very small C interpreter for scripting

#21
post #17

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.

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

Re: PicoC: a very small C interpreter for scripting

#22
post #15
post #8

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

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.

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

Re: PicoC: a very small C interpreter for scripting

#23
post #15
post #8

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

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.

Lua can and is used in robotics, embedded system and alike. Take a look at: * pbLua, for Lego Mindstorm (http://www.hempeldesigngroup.com/lego/pblua/) * eLua for small MCU (http://www.eluaproject.net/)

Re: PicoC: a very small C interpreter for scripting

#24

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

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

Sure, but still. It's rare to see a program that does not require at least another 10 fold its own size in super structure. And the fact that it is targeted to embedded use means that in its destined environment there is none of that stuff available anyway.

Re: PicoC: a very small C interpreter for scripting

#25
post #21
post #17

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.

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…

How would you like to have a REPL for kernel development, like on the Lisp Machines? (Yes, that's a rhetorical question!)

Take TCC with your point 1 above. Mix it with the ideas from Schemix ( http://abstractnonsense.com/schemix/ ). Now you can iteratively development a kernel driver!

I hacked on Schemix a while back, updating it to 2.6 module system (unfortunately lost the source code before it got uploaded). It's a seemingly great idea but what good is scheme code if you have to rewrite in a different language for the final version?

Re: PicoC: a very small C interpreter for scripting

#26

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

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

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.

Re: PicoC: a very small C interpreter for scripting

#27
post #21
post #17

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.

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…

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

DOS weenie pride!

Re: PicoC: a very small C interpreter for scripting

#28

Earlier quoted context omitted.

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

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 th…

I don't find it refreshing to see people writing the same code over and over and over and over again. Does it have a point? Yes. Does it refresh me? No.

(Libraries and dependencies don't necessarily mean "dynamic relinking at runtime". It can mean "link that standard code from ../lets-not-write-a-hashtable-again/hashtable.o".)

Re: PicoC: a very small C interpreter for scripting

#29
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?

Re: PicoC: a very small C interpreter for scripting

#30
post #17

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.

One thing that was sad was to see how ugly the forking situation got: http://www.landley.net/code/tinycc/

When I was using tcc a lot I used the tinycc fork as it had fixed bugs I was encountering. It's a shame that things didn't work out amicably.

Post reply on HN