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

Cling: Running C++ in an interpreter

blog.coldflake.com

Post reply on HN
Print view View original

21–30 of 49 posts

Re: Cling: Running C++ in an interpreter

#21

Post by rcfox »

fferen wrote: post #11

I just keep a fixed .cpp file with a bunch of common includes and directives, and alias the g++ command to link to common libraries, so my workflow goes: > vim temp.cpp > g++ temp.cpp > ./a.out Very similar to my process with Python, actually. Every time I use the REPL for some experimenting, the code ends up outgrowing it and I have to stuff it in a file anyway, so I may as well cut out the middleman to begin with.…

If you don't need any special compiler flags, it's even simpler:

    make temp
    ./temp

Re: Cling: Running C++ in an interpreter

#22

Post by voltagex_ »

sanxiyn wrote: post #18
fferen wrote: post #11

I just keep a fixed .cpp file with a bunch of common includes and directives, and alias the g++ command to link to common libraries, so my workflow goes: > vim temp.cpp > g++ temp.cpp > ./a.out Very similar to my process with Python, actually. Every time I use the REPL for some experimenting, the code ends up outgrowing it and I have to stuff it in a file anyway, so I may as well cut out the middleman to begin with.…

I too put the code in a file even in Python, but REPL is still valuable. I use "python -i" which runs your code (defines functions, classes, etc.) and then stop, and put you in that environment. This is very useful. It seems Cling could be used the same way: .x command.

I must be reading the wrong Python tutorials. Thank you for this

Re: Cling: Running C++ in an interpreter

#23

Post by sedachv »

To provide more precedents and a little history:

The first C "interpreters" I know of were for Lisp machines: Symbolics' C compiler (http://www.bitsavers.org/pdf/symbolics/software/genera_8/Use...) and Scott Burson's (hn user ScottBurson) ZetaC for TI Explorers/LMIs and Symbolics 3600s (now available under the public domain: http://www.bitsavers.org/bits/TI/Explorer/zeta-c/). Neither of them are interpreters, just "interactive" compilers like Lisp ones are.

I am writing a C to Common Lisp translator right now (https://github.com/vsedach/Vacietis). This is surprisingly easy because C is largely a small subset of Common Lisp. Pointers are trivial to implement with closures (Oleg explains how: http://okmij.org/ftp/Scheme/pointer-as-closure.txt but I discovered the technique independently around 2004). The only problem is how to deal with casting arrays of integers (or whatever) to arrays of bytes. But that's a problem for portable C software anyway. I think I'll also need a little source fudging magic for setjmp/longjmp. Otherwise the project is now where you can compile-file/load a C file just like you do a Lisp file by setting the readtable. There's a few things I need to finish with #includes, enums, stdlib and the variable-length struct hack, but that should be done in the next few weeks.

This should also extend to "compiling" C to other languages like JavaScript, without having to go through the whole "emulate LLVM or MIPS" garbage that other projects like that do. I think I figured out how to do gotos in JavaScript by using a trampoline with local CPS-rewriting, which is IMO the largest challenge for an interoperable C->JS translator.

As to how to do this for C++, don't ask me. According to the CERN people, CINT has "slightly less than 400,000 lines of code." (http://root.cern.ch/drupal/content/cint). What a joke.

Re: Cling: Running C++ in an interpreter

#24

Post by sedachv »

joebo wrote: post #15

I've used libtcc from tcc to do something similar on a prototype listening on a socket to do queries over a 2 gig memory mapped file. I'd pass over the query as a string of C that would be dynamically compiled and executed by libtcc. It worked really well but ultimately didn't go anywhere other than research. Here's an example from the distribution (first google result for the file): http://www.koders.com/c/fidC76C8B…

I am surprised more projects don't use TCC for that. It's an awesome little compiler and using it that way saves way more time over writing DSLs. Even projects that have to compile C all the time (like Lisp->C compilers such as ECL and Gambit Scheme) use GCC, which is stupid slow.

Re: Cling: Running C++ in an interpreter

#25

Post by gsnedders »

sedachv wrote: post #23

To provide more precedents and a little history: The first C "interpreters" I know of were for Lisp machines: Symbolics' C compiler ( http://www.bitsavers.org/pdf/symbolics/software/genera_8/Use... ) and Scott Burson's (hn user ScottBurson) ZetaC for TI Explorers/LMIs and Symbolics 3600s (now available under the public domain: http://www.bitsavers.org/bits/TI/Explorer/zeta-c/ ). Neither of them are interpreters, just…

Emscripten in no way emulates LLVM (as far as I know it's the only C-to-JS compiler that uses LLVM, and hence must be what you're referring to!) — it compiles LLVM to JS, with no emulation, and there's currently work going on to re-implement it as a LLVM backend (it currently is an entirely separate codebase that takes LLVM bitcode in and spits JS out).

Re: Cling: Running C++ in an interpreter

#28

Post by charliesome »

jeremiep wrote: post #14
pmr_ wrote: post #10

Earlier quoted context omitted.

I share your enthusiasm but there are limits. C++ compilation speed (and thus interpretation speed) will make it quite impossible to use it as an extension language. And while I like and use C++ a lot I don't think it is the right language for this purpose. It can do quite a lot of things, but working in a homogeneous language in your extensions as well as your core product doesn't have enough benefits compared to us…

Well if it's possible for C++, it's definitely possible for D which is benchmarked to compile 100 times faster and has close-to-ruby's productivity in a close-to-metal language like C. An added benefit is that D already has most of the C++11 features and more. I would very much like to use D as an extension language.

D has `rdmd`

Re: Cling: Running C++ in an interpreter

#29

Post by sedachv »

gsnedders wrote: post #25
sedachv wrote: post #23

To provide more precedents and a little history: The first C "interpreters" I know of were for Lisp machines: Symbolics' C compiler ( http://www.bitsavers.org/pdf/symbolics/software/genera_8/Use... ) and Scott Burson's (hn user ScottBurson) ZetaC for TI Explorers/LMIs and Symbolics 3600s (now available under the public domain: http://www.bitsavers.org/bits/TI/Explorer/zeta-c/ ). Neither of them are interpreters, just…

Emscripten in no way emulates LLVM (as far as I know it's the only C-to-JS compiler that uses LLVM, and hence must be what you're referring to!) — it compiles LLVM to JS, with no emulation, and there's currently work going on to re-implement it as a LLVM backend (it currently is an entirely separate codebase that takes LLVM bitcode in and spits JS out).

My mistake, I thought Emscripten was an LLVM VM in JS. I'll take a look at it to see what the output actually does.

Re: Cling: Running C++ in an interpreter

#30

Post by mahmud »

sedachv wrote: post #23

To provide more precedents and a little history: The first C "interpreters" I know of were for Lisp machines: Symbolics' C compiler ( http://www.bitsavers.org/pdf/symbolics/software/genera_8/Use... ) and Scott Burson's (hn user ScottBurson) ZetaC for TI Explorers/LMIs and Symbolics 3600s (now available under the public domain: http://www.bitsavers.org/bits/TI/Explorer/zeta-c/ ). Neither of them are interpreters, just…

That Oleg link has me nerd-snipped.

What I can't wrap my head around is how one would implement pointer-arithmetic with these closures? C pointers are not just references to cells, but those cells are guaranteed to be contiguous (up to a certain limit, be it an VM allocation unit, say "page", or all available system unit in VM-less systems)

That is to say, C pointers are not like ML references. Along with SET and REF they also allow addition, subtraction, scaling, etc.

For closures to model C pointers, wouldn't they need to order the allocation of cells in some manner? say, big array? And if so, this could get expensive very quickly (worst-case being "modeling" of entire memory, i.e. emulation) without certifying compiler or at least some exhaustive pointer analysis.

Hope I'm wrong on this.

Post reply on HN