PicoC is a very small C interpreter for scripting. It was originally written as a script language for a UAV’s on-board flight system. It’s also very suitable for other robotic, embedded and non-embedded applications.
The core C source code is around 3500 lines of code. It’s not intended to be a complete implementation of ISO C but it has all the essentials. When compiled it only takes a few k of code space and is also very sparing of data space. This means it can work well in small embedded devices. It’s also a fun example of how to create a very small language implementation while still keeping the code readable.
3.5K lines?
That’s nothing compared to what Bellard accomplished…
http://bellard.org/otcc/
Of course, he has two brains, so any comparison is unfair.
Also one is an interpreter and one is a compiler…
Yes. The compiler generates x86 code so things run reasonably fast, and it is ~1/10’th the size of the interpreter. Which one is more impressive?
Edited 2015-06-02 00:04 UTC
adrienz,
They are both impressive for what they are.
I downloaded tinycc from here
http://download.savannah.gnu.org/releases/tinycc/
After removing the test/example/win32 directories and then counting the number of lines in the c and h files (I did not count the assembly files), I got a total of 36k lines. This included comments, but even so I’m pretty sure PicoC is the “smaller lines of code winner” by a large margin.
It should be pointed out that this is all meaningless given that we’re comparing apples and oranges here. Also I don’t place much significance on lines of code (quality & clarity matter more in real life).
It also produce ARM code, so that may explain the added size.
TCC was Febrice Bellards – which then went on to become the code above. Which is still called TCC. (Although, oddly, the webpage http://bellard.org/tcc/ does have a link for “TinyCC mailing list”, all the rest of the references on the page are to TCC)
TinyCC is the fork that Rob Landley was working on until he got fed up of getting bug reports from the “lurching zombie” that was TCC.
TCC was based on this: http://www.bellard.org/otcc/
This is what the person you are responding to was comparing to PicoC. (It was an IOCCC entry)
xslogic,
The unobfuscated version of otcc weighs in at ~632 lines, but
because of how incomplete it is it isn’t remotely in the same class as PicoC or TinyCC, which is why it makes more sense to use TinyCC for comparison.
I think otcc is neat too, but it’s small size is proportional it’s it’s small functionality. It does not support typed parameters, hard codes alloc sizes, no proper support for include files, no linking, no arrays, incomplete pointer support, incomplete C statements, etc. It would be pretty difficult to use this outside of the obfuscated c contest
http://bellard.org/otcc/otccn.c
Edited 2015-06-02 14:57 UTC
While looking for other examples of similar things, I found this.
https://code.google.com/p/awib/source/browse/builds/awib-1.0rc4.b
Oh the crazy stuff people do to challenge themselves
Yes, he could have used ArnoldC, and it would have been easier to read 🙂
https://gist.github.com/georg/9224355
True, true. I didn’t realise quite how limited it was, to be honest. Even just reading the first limitation, “Types: only signed integer variables and functions can be declared”, is a bit… uhhhh… too limited for my taste. (Then again, it was an IOCCC entry and it’s still impressive. As an aside, TCCBoot is also impressive – then again, most of Fabrice Bellards projects are)
I’ve glanced at PicoC in the past – didn’t go deeply into it – but was thinking of using it in a project.
There are also other ones out there – there’s Ch (Which is proprietary and paid for) and Cint (A Cern creation that is quite a bit bigger at 400,000 lines of C++ – but does, supposedly, also include C++)
The compiler links against existing libraries, the interpreter has to implement its own. They aren’t simply apples to apples.
No, but the level of impressiveness is comparable, which is what I did.
Interesting project.
But if you’re going to write C, why not just compile it so it gets to be smaller and faster? I get the idea of code portability, but the interpreter itself still needs to be compiled for the particular platform, so if you’re talking embedded, you might as well compile your ‘scripts’.
Rapid testing on live-hardware, perhaps? It’s a lot easier to test scripts and make adjustments in them than going through the recompile-process every time. One could still compile the scripts into actual executables once the testing-phase is over.
It depends perhaps how stretched for space you are. The (ELF) Tiny C Compiler is 14kB, this interpreter is “a few” kB (350k when I compiled it).
But in terms of easy, it’s only 1 extra step that can’t take many seconds, even on severely underpowered hardware.
Edited 2015-06-02 06:14 UTC
I have been implementing a fairly feature complete version of forth. I got it down to under 500 lines of commented C for compiler and virtual machine.
http://chiselapp.com/user/tehologist/repository/compc/index
tehologist,
First, nice to meet you!
There’s something very appealing with languages like forth, striking a balance between minimalism and functionality that many complex languages never really mastered. What a joy, forth is simple to implement and simple to use!
It’s just in prototype phase, but I’m also working on my own pseudo programming language where I’m going for built in transactional/database/clustering features (really more of a back end compilation target rather than something I’d intend for humans to program in, but that will come later). The goal is for execution units to be oblivious to where they’re running and get redistributed on the fly, similar to migrating a virtual machine but at a fine grained level instead of a VM level.
Erlang-esque
I was inspired by Jonesforth https://rwmj.wordpress.com/2010/08/07/jonesforth-git-repository/ and was curious how I would implement something similar in C. Down the rabbit hole I went. It is fully rommable which is great as I managed to get it running on an arduino. The ultimate target is to use it as an OS for http://propellerpowered.com/shop/?page_id=1946 as I am completely obsessed with 1980’s micros.
Cool idea, I have been wanting to potentially do some work with DGD (Dworkins Game Driver). It is a programming environment that allows full persistance and upgrading of live objects. It is pretty small and written in C. Was open sourced a few years back.