Linked by Thom Holwerda on Mon 1st Jun 2015 23:32 UTC
General Development

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.

Order by: Score:
That's huge!
by adrienz on Mon 1st Jun 2015 23:45 UTC
adrienz
Member since:
2015-06-01

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.

Reply Score: 1

RE: That's huge!
by jockm on Mon 1st Jun 2015 23:54 UTC in reply to "That's huge!"
jockm Member since:
2012-12-22

Also one is an interpreter and one is a compiler...

Reply Score: 2

RE[2]: That's huge!
by adrienz on Tue 2nd Jun 2015 00:03 UTC in reply to "RE: That's huge!"
adrienz Member since:
2015-06-01

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

Reply Score: 1

RE[3]: That's huge!
by Alfman on Tue 2nd Jun 2015 00:46 UTC in reply to "RE[2]: That's huge!"
Alfman Member since:
2011-01-28

adrienz,

3.5K lines?

That's nothing compared to what Bellard accomplished...


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?


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).

Reply Score: 2

RE[4]: That's huge!
by Kochise on Tue 2nd Jun 2015 05:04 UTC in reply to "RE[3]: That's huge!"
Kochise Member since:
2006-03-03

It also produce ARM code, so that may explain the added size.

Reply Score: 2

RE[4]: That's huge!
by xslogic on Tue 2nd Jun 2015 12:12 UTC in reply to "RE[3]: That's huge!"
xslogic Member since:
2011-03-09

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.


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)

Reply Score: 1

RE[5]: That's huge!
by Alfman on Tue 2nd Jun 2015 14:45 UTC in reply to "RE[4]: That's huge!"
Alfman Member since:
2011-01-28

xslogic,

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.


Although Rob Landley created another fork, TinyCC was Bellard's as well:
NOTE: My other project TinyCC which is a fully featured ISOC99 C compiler was written by starting from the source code of OTCC !


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

Reply Score: 3

RE[6]: That's huge!
by Alfman on Tue 2nd Jun 2015 16:40 UTC in reply to "RE[5]: That's huge!"
Alfman Member since:
2011-01-28

While looking for other examples of similar things, I found this.

An optimizing brainfuck compiler written in brainfuck for Linux on i386
by Mats Linander

This program takes brainfuck source code as input, compiles it into machine
code and outputs it as an elf binary.


https://code.google.com/p/awib/source/browse/builds/awib-1.0rc4.b

Oh the crazy stuff people do to challenge themselves ;)

Reply Score: 2

RE[7]: That's huge!
by Nth_Man on Tue 2nd Jun 2015 18:57 UTC in reply to "RE[6]: That's huge!"
Nth_Man Member since:
2010-05-16

Yes, he could have used ArnoldC, and it would have been easier to read :-)
https://gist.github.com/georg/9224355

Reply Score: 2

RE[6]: That's huge!
by xslogic on Wed 3rd Jun 2015 10:32 UTC in reply to "RE[5]: That's huge!"
xslogic Member since:
2011-03-09

Although Rob Landley created another fork, TinyCC was Bellard's as well:
"NOTE: My other project TinyCC which is a fully featured ISOC99 C compiler was written by starting from the source code of OTCC !
"

I suppose. The majority of the webpage called it TCC - which, to be fair, is short for "Tiny C Compiler"

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.


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++)

Reply Score: 1

RE[3]: That's huge!
by jockm on Tue 2nd Jun 2015 01:15 UTC in reply to "RE[2]: That's huge!"
jockm Member since:
2012-12-22

The compiler links against existing libraries, the interpreter has to implement its own. They aren't simply apples to apples.

Reply Score: 2

RE[4]: That's huge!
by adrienz on Tue 2nd Jun 2015 09:09 UTC in reply to "RE[3]: That's huge!"
adrienz Member since:
2015-06-01

No, but the level of impressiveness is comparable, which is what I did.

Reply Score: 1

Why not compile it?
by pepa on Tue 2nd Jun 2015 01:54 UTC
pepa
Member since:
2005-07-08

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'.

Reply Score: 4

RE: Why not compile it?
by WereCatf on Tue 2nd Jun 2015 02:34 UTC in reply to "Why not compile it?"
WereCatf Member since:
2006-02-15

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.

Reply Score: 4

RE[2]: Why not compile it?
by pepa on Tue 2nd Jun 2015 06:02 UTC in reply to "RE: Why not compile it?"
pepa Member since:
2005-07-08

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

Reply Score: 3

Very Cool
by tehologist on Wed 3rd Jun 2015 01:00 UTC
tehologist
Member since:
2015-06-03

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

Reply Score: 1

RE: Very Cool
by Alfman on Wed 3rd Jun 2015 03:14 UTC in reply to "Very Cool"
Alfman Member since:
2011-01-28

tehologist,

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.


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.

Reply Score: 2

RE[2]: Very Cool
by Kochise on Wed 3rd Jun 2015 05:19 UTC in reply to "RE: Very Cool"
Kochise Member since:
2006-03-03

Erlang-esque ;)

Reply Score: 2

RE[2]: Very Cool
by tehologist on Wed 3rd Jun 2015 17:44 UTC in reply to "RE: Very Cool"
tehologist Member since:
2015-06-03

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.

Reply Score: 2