Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PicoC: A very small C interpreter

github.com

Post reply on HN
Print view View original

11–20 of 51 posts

Re: PicoC: A very small C interpreter

#11

Post by gbl08ma »

I have used this to bring a form of scripting to the graphic calculator I used and hacked on during my high school years. I think this really shines on embedded systems: it's quite easy to map existing syscalls and functions to PicoC functions with minimal overhead, more complex things like struct passing are supported, and memory addresses can be accessed directly just like with "real" compiled C (something that has upsides and downsides, but I like this kind of freedom a lot, and as far I know, other scripting languages like Lua don't support it).

Unfortunately, function pointers aren't supported, and it's 10x slower than equivalent compiled C, if not more, and perhaps slower than Lua (and we aren't even talking about LuaJIT). There also appear to be some issues yet to be dealt with, as can be seen on the previous project page at Google Code: https://code.google.com/p/picoc/issues/list

Re: PicoC: A very small C interpreter

#14

Post by beagle3 »

andrewchambers wrote: post #6

Shameless self promotion of my work in progress C compiler https://github.com/andrewchambers/cc which is attempting to create a modern cross platform C compiler. One of my goals is to make the entire toolchain rapid to port and hack on. I am pretty sick of gcc and llvm taking 20 mins just to build from source. I would love to find serious collaborators.

I am all in favor of hacking for studying and fun. But for practical reasons - are you familiar with Bellard's tcc?

Re: PicoC: A very small C interpreter

#15

Post by to3m »

JoshTriplett wrote: post #10
to3m wrote: post #8

Earlier quoted context omitted.

While I'm on the subject the same also goes for header include guards - when you get a conflict, it's actually quite annoying to track down. (Not least because it's such a rare occurrence that you probably won't expect it and will likely end up on a wild goose chase at some inconvenient moment.) I stopped using the file name at all in my include guards a few years ago, and use a GUID instead. For example: #ifndef HEA…

> Also consider the use of #pragma once - though as far as I can tell, this (still) isn't ISO, so I've decided to avoid it. Depends on your target platform. GCC, clang/LLVM, Visual C++, and many proprietary compilers all support it. What platform are you targeting that doesn't support it? Because if you're writing any non-trivial useful code, it's highly likely that your code is not pure ISO C; you're using some libr…

Good question - probably the main reason (and you don't have to agree that it's a good one) is that I'd never have to think about it again ;)

Re: PicoC: A very small C interpreter

#16

Post by zik »

Hi, author here. When I started writing PicoC it was mostly because I was thinking about how small AppleSoft BASIC was back in the day and I was curious how small you could make a C implementation. I also had in mind to use it for robotics/drone scripting on STM32 processors which have about 64KB of RAM.

PicoC runs ok in 64KB although it is a bit cramped. I like that you can write scripts in C on the actual device without needing a host computer of any kind. It's also been fairly popular for embedding as a scripting language in desktop applications, mostly because it's small and easy to integrate. It's really designed for scripting so don't expect it to be fast though.

Re: PicoC: A very small C interpreter

#17

Post by andrewchambers »

beagle3 wrote: post #14
andrewchambers wrote: post #6

Shameless self promotion of my work in progress C compiler https://github.com/andrewchambers/cc which is attempting to create a modern cross platform C compiler. One of my goals is to make the entire toolchain rapid to port and hack on. I am pretty sick of gcc and llvm taking 20 mins just to build from source. I would love to find serious collaborators.

I am all in favor of hacking for studying and fun. But for practical reasons - are you familiar with Bellard's tcc?

I am, it is referenced in the readme. Tcc's code is not really so readable in my opinion, which is something I want to address. Tcc also has no desire to become an optimizing compiler in the future. Personally I think 8cc is far superior to tcc in many important ways, but is not as mature as tcc.

I love C so considered using 8cc as a base for expansion, but there is a reason llvm and gcc are in C++ and not C. I dislike C++ for many logical and illogical reasons, and think Go is a fair compromise with keeping close to C roots.

Re: PicoC: A very small C interpreter

#19

Post by zik »

to3m wrote: post #3

Obligatory nitpick: C libraries should be careful to prefix all exposed identifiers, to minimize the risk of collision. But when you include picoc.h, which is careful to do this, you also get interpreter.h, which... is not.

You make a good point. To some extent this reflects that PicoC wasn't originally a library at all. It was a standalone interpreter that I later converted to library form.

The other factor is that the code as it stands is designed to be as readable as possible. I'm conscious that prefixing every identifier with "PicoC" will make the whole thing a bit less easy to read. I'm not sure if maximising readability is something that people really care about though. I'd be interested in hearing people's opinions on whether they'd prefer "struct ValueType" or "struct PicoCValueType" in a thousand places throughout the code.

Post reply on HN