This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Simple install hook


On Tue, 2014-02-11 at 16:51 +0000, Philip Herron wrote:
[adding the jit@gcc.gnu.org ML to the CC]

> Added install hook:

Thanks!

I don't know that this is needed for a 3-line patch, but have you done
the copyright assignment paperwork for GCC contribution?  (I hope to
merge my branch into gcc trunk at some point).  [Also, I'd love to have
more, larger, patches from you for the jit branch!]

> /opt/gjit/bin/gcc -g -O2 -Wall t.c -o test -I/opt/gjit/include
> -lgccjit -L/opt/gjit/lib
> 
> Compiles the helloworld examples correctly and it runs instead of
> pointing to my gcc build dir. Am working on getting more involved with
> this and started:
> 
> https://github.com/redbrain/spy
> 
> Its only just starting to parse stuff but a kind of C/Python kind of
> language using gcc as a JIT might be interesting kind of dynamic
> language for C that can call C libs safely and easily is the idea.
> Mostly just so i can see where to help out in the jit front-end.

Excellent!  Looks promising - though it looks like the backend is all
stubbed out at the moment.

Note that the JIT API isn't frozen yet.  I try to remember to add "API
change" to the subject line when posting my commits, but I don't always
remember.

Let me know if you have any questions on how the JIT API works - or
input on how it *should* work.

FWIW I've been experimentally porting GNU Octave's LLVM-based JIT to
using libgccjit, and finding and fixing various issues in the latter on
the way - that's been driving a lot of the patches to the jit branch
lately.

> Was also considering some kind of libopcodes work to assemble the code
> in memory instead of creating a .so in /tmp. Not sure if i know what i
> am doing enough there but it might be more elegant for stuff using
> this front-end.

My thinking here was that the core code of the GNU assembler could gain
the option of being built as a shared library, and having to isolate
state in a "context" object, and we could try to hack the two projects
into meeting in the middle.  Large amount of work though (and a
different mailing list), hence the crude .so hack for now.

> Am so impressed how well this works.

Cheers!
Dave


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]