Hi Georgios,<div><br></div><div>Before we developed our own gcc backend, what I was usually doing -to try the compilation step- is to substitute the .o object generated by my own objects (compiled using the other compiler) and then remake, as the resulting object has a greater timestamp it will only link, but using my objects.</div>
<div><br></div><div>The problem that I see is when compiling with a different compiler is all the GNU extensions that are added to struct definitions, functions, etc... that could be probably included (like __attribute__ (...), these are not portable). But if your program is not using many barrelfish structs or functions, you can probably skip these header files.</div>
<div><br></div><div>Good luck!</div><div>zeus.</div><div><br></div><div><br><br><div class="gmail_quote">2011/8/26 Timothy Roscoe <span dir="ltr"><<a href="mailto:troscoe@inf.ethz.ch">troscoe@inf.ethz.ch</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi Georgios,<br>
<br>
Actually, source-to-source translators are much easier, since you can<br>
write rules to do the translation and which implicitly add the generated<br>
files to the list of C files to compile as normal. What's a little more<br>
tricky is a different C -> object file translation step.<br>
<br>
It's good that it's not urgent, and we should probably add custom C<br>
compilers to the wishlist next time we fiddle with Hake a bit more.<br>
<br>
-- Mothy<br>
<div><div></div><div class="h5"><br>
On 08/26/2011 11:22 AM, Georgios Varisteas wrote:<br>
> Hi Mothy,<br>
><br>
> My usage for this feature is twofold. First, I require to have custom<br>
> source-to-source compilers (as front-ends) for the various task-based<br>
> programming models I'm working with (i.e. Cilk, Wool). Moreover, I<br>
> plan to try out Continuation-passing-style (like Cilk does) for my<br>
> own runtime, which requires a custom code-generator to not use the<br>
> stack. The purpose for CPS is to allow task-migration between threads<br>
> of different cores.<br>
><br>
> This feature is not urgent since I'm only now starting the<br>
> implementation, but it's good to know that it's doable. Since almost<br>
> all of my research requires it though, I think I'll select the first<br>
> and proper solution.<br>
><br>
><br>
> -Georgios<br>
><br>
> ________________________________________ From: Timothy Roscoe<br>
> [<a href="mailto:troscoe@inf.ethz.ch">troscoe@inf.ethz.ch</a>] Sent: Friday, August 26, 2011 11:07 To:<br>
> <a href="mailto:barrelfish-users@lists.inf.ethz.ch">barrelfish-users@lists.inf.ethz.ch</a> Subject: Re: [Barrelfish-users] CC<br>
> variable<br>
><br>
> Hi Georgios,<br>
><br>
> We made an early decision to bury the binding of the C compiler<br>
> fairly deep down in Hake's architecture abstractions. If there<br>
> really is a pressing need to specify the C compiler differently for<br>
> different modules in the same build architecture, we would need to<br>
> add the compiler name to the (ever-expanding) Opts record. This is<br>
> doable, but it's a bit of work.<br>
><br>
> One alternative is to explicitly compile the C files by writing<br>
> low-level Hake combinators in your Hakefile. Hake won't compile (or<br>
> calculate dependencies for) any C files which you don't explicitly<br>
> hand it, so you can treat any C file specially if you're prepared to<br>
> forego the convenience of the "build library" or "build application"<br>
> functions. This might be the easiest way forward for a small module<br>
> (how big is it?).<br>
><br>
> This does require a bit more understanding of how Hake works, but<br>
> most of what you need should be in the Technical Note.<br>
><br>
> Hope this helps a bit...<br>
><br>
> -- Mothy<br>
><br>
> On 08/26/2011 10:19 AM, Georgios Varisteas wrote:<br>
>> Hi Simon,<br>
>><br>
>> Thanks for the quick reply. Setting the compiler in ./hake/<br>
>> anywhere would be "too" permanent. What I would prefer is to use a<br>
>> custom compiler just for one module. Ideally there would be a<br>
>> CC-equivalent option in the hakefile. Could I try and add such a<br>
>> feature in hake?<br>
>><br>
>> I can always have the compiler to be a wrapper script that invokes<br>
>> the correct compiler according to arguments (default being gcc).<br>
>> But this is a hassle for portability since I wont be able to have a<br>
>> variable for default_compiler to be passed to the wrapper script.<br>
>><br>
>><br>
>> -Georgios<br>
>><br>
>><br>
>> ________________________________________ From: Simon Peter<br>
>> [<a href="mailto:speter@inf.ethz.ch">speter@inf.ethz.ch</a>] Sent: Friday, August 26, 2011 10:03 To:<br>
>> Georgios Varisteas Cc: <a href="mailto:barrelfish-users@lists.inf.ethz.ch">barrelfish-users@lists.inf.ethz.ch</a> Subject:<br>
>> Re: [Barrelfish-users] CC variable<br>
>><br>
>> Hi Georgios,<br>
>><br>
>> We don't really do this, but it's probably to set the compiler<br>
>> variable in hake/X86_64.hs (for example) to something else.<br>
>><br>
>> Hope this helps, Simon<br>
>><br>
>> On 26.08.2011 09:58, Georgios Varisteas wrote:<br>
>>> Hi,<br>
>>><br>
>>> What's the best way to setup hake to use a different compiler for<br>
>>> a specific module?<br>
>>><br>
>>><br>
>>> Best regards, Georgios Varisteas<br>
>>> _______________________________________________ Barrelfish-users<br>
>>> mailing list <a href="mailto:Barrelfish-users@lists.inf.ethz.ch">Barrelfish-users@lists.inf.ethz.ch</a><br>
>>> <a href="https://lists.inf.ethz.ch/mailman/listinfo/barrelfish-users" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/barrelfish-users</a><br>
>><br>
>><br>
>> _______________________________________________ Barrelfish-users<br>
>> mailing list <a href="mailto:Barrelfish-users@lists.inf.ethz.ch">Barrelfish-users@lists.inf.ethz.ch</a><br>
>> <a href="https://lists.inf.ethz.ch/mailman/listinfo/barrelfish-users" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/barrelfish-users</a><br>
><br>
> _______________________________________________ Barrelfish-users<br>
> mailing list <a href="mailto:Barrelfish-users@lists.inf.ethz.ch">Barrelfish-users@lists.inf.ethz.ch</a><br>
> <a href="https://lists.inf.ethz.ch/mailman/listinfo/barrelfish-users" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/barrelfish-users</a><br>
><br>
> _______________________________________________ Barrelfish-users<br>
> mailing list <a href="mailto:Barrelfish-users@lists.inf.ethz.ch">Barrelfish-users@lists.inf.ethz.ch</a><br>
> <a href="https://lists.inf.ethz.ch/mailman/listinfo/barrelfish-users" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/barrelfish-users</a><br>
<br>
_______________________________________________<br>
Barrelfish-users mailing list<br>
<a href="mailto:Barrelfish-users@lists.inf.ethz.ch">Barrelfish-users@lists.inf.ethz.ch</a><br>
<a href="https://lists.inf.ethz.ch/mailman/listinfo/barrelfish-users" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/barrelfish-users</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Zeus Gómez Marmolejo<br>Barcelona Supercomputing Center<br>PhD student<br><a href="http://www.bsc.es" target="_blank">http://www.bsc.es</a><br><br>
<br>
</div>