This is the mail archive of the gcc@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: Using GCC for "real-time" compilation in audio enginedevelopment


> In other words, you're looking at dynamic synthesis of C code, to be
> compiled into .so's in the background, and then loaded into a running
> application.

Yes, only I was hoping to avoid going via C, and rather go directly to
the internal tree representation of GCC.

> FWIW, the front-end you referred to looks a lot like
> LabVIEW, a granddaddy of visual programming systems.

Sounds interesting, I'll have a look at that.

> Complications include designing the passing of
> data and control across the boundary between the core application and
> the synthesized code;

I was thinking about just calling the .so code with a pointer to some
allocated memory, and the size of it, then when it returns dump the
buffer to the soundcard (or other output). Doesn't sound complicated so
far, but I might be missing something.

> .so lifetime/version control;

Lifetime would be until the user alters something in the structure, or
quits the program I guess (very short anyway), so there shouldn't be any
version problems.

> overall gcc/gas/ld latencies;

That's one of the reasons I'd like to avoid going via C. To first
generate a code tree based on the graphical structure, convert it to C
and hand it to GCC, which will convert it back to a code tree again,
sounds like it will be slower than generating a GCC-style code tree in
the beginning. No doubt fiddling with GCC internals is hard though, so
I'll keep the C way in mind.

Best regards
Torgeir


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