PicoC: A very small C interpreter

#1

Post by adamnemecek » Mon, Jun 01, 2015, 8:19 PM UTC

PicoC: A very small C interpreter
github.com

Re: PicoC: A very small C interpreter

#2

Post by fapjacks » Mon, Jun 01, 2015, 8:36 PM UTC

Ah! This is very cool! Strangely enough, I was looking for something exactly like this and staring down having to write my own. Perfect!

Re: PicoC: A very small C interpreter

#3

Post by to3m » Mon, Jun 01, 2015, 9:05 PM UTC

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.

Re: PicoC: A very small C interpreter

#4

Post by PhantomGremlin » Mon, Jun 01, 2015, 9:17 PM UTC

When I read "very small C" I'm reminded of the BD Software C compiler I used about 35 years ago for the 8080/Z80 and CP/M.

It was relatively complete K&R C except for no floating point support. It comfortably ran in under 64K bytes of memory. That's 64 kilobytes, or as they now say kibibytes!

It was quite fast to compile. It was also quite fast to run, since it generated true object code, no run-time interpreter needed.

It's now open source and public domain. http://www.bdsoft.com/resources/bdsc.html

Re: PicoC: A very small C interpreter

#5

Post by tdoggette » Mon, Jun 01, 2015, 9:52 PM UTC

Do people who use this call it "peacock" or "pico see"?

Re: PicoC: A very small C interpreter

#6

Post by andrewchambers » Mon, Jun 01, 2015, 9:54 PM UTC

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.

Re: PicoC: A very small C interpreter

#7

Post by kjak » Mon, Jun 01, 2015, 9:56 PM UTC

tdoggette wrote: post #5

Do people who use this call it "peacock" or "pico see"?

When I first saw it I thought "pico see".

The "peacock" interpretation is funny and went unnoticed by me. Cheers!

Re: PicoC: A very small C interpreter

#8

Post by to3m » Mon, Jun 01, 2015, 10:01 PM UTC

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.

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 HEADER_6AFF21D71B5B43DEB079AA612E4118B4
    #define HEADER_6AFF21D71B5B43DEB079AA612E4118B4

    #endif//HEADER_6AFF21D71B5B43DEB079AA612E4118B4

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.

Re: PicoC: A very small C interpreter

#9

Post by pikzen » Mon, Jun 01, 2015, 10:08 PM UTC

to3m wrote: post #8

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.

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…

Unless you're working on embedded hardware with proprietary compilers, #pragma once is supported by all compilers (see https://en.wikipedia.org/wiki/Pragma_once). You can safely assume it'll be available on your platform.

Re: PicoC: A very small C interpreter

#10

Post by JoshTriplett » Mon, Jun 01, 2015, 10:09 PM UTC

to3m wrote: post #8

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.

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 library with support for various platforms, or a system call interface, or some other interface to a real system. Once you do that, universal portability no longer applies, so you might as well think about which specific target platforms you care about.