<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>
Thanks Kostis,<div><br></div><div>Calling hipe:c/1 on the beam file was exactly what I wanted. I thought you could only run it on source files.</div><div><br></div><div>Matt<br><br><div><div id="SkyDrivePlaceholder"></div>> Date: Sun, 29 Jan 2012 22:35:23 +0200<br>> From: kostis@cs.ntua.gr<br>> To: erlang-questions@erlang.org<br>> Subject: Re: [erlang-questions] HiPE compiler<br>> <br>> On 01/29/12 19:01, Matthew Evans wrote:<br>> > Hi group,<br>> ><br>> > My understanding is that HiPE takes Erlang byte code beam files as the<br>> > input to produce modified combined HiPE + byte code beam files.<br>> ><br>> > I'm thinking of using HiPE on a project. Unfortunately the build system<br>> > is mixed, and I'd rather not go down the cross-compiler route. My<br>> > question is - is there a way to create "HiPE targets" just from beam<br>> > files on the target platform? The source will, obviously, not be<br>> > available on the target platform.<br>> <br>> I am not sure I understand your question well, but I'll give it a shot <br>> in answering it anyway.<br>> <br>> Unlike BEAM byte code, the native code that the HiPE compiler generates <br>> has a very strong dependence on the specifics of the Erlang runtime <br>> system which is running the code. This means that you cannot native <br>> compile the code using Erlang/OTP R-X and expect it to run on R-Y where <br>> X and Y are different. This holds even for minor revisions of the same <br>> major release (i.e. code compiled for R14B03 cannot run on R14B03.) <br>> Also obviously there is a strong dependency on the target architecture: <br>> i.e. you cannot compile code for an x86 and expect it to run on an ARM.<br>> <br>> But you can compile your code natively and run it on another target if <br>> the machine that you compile in and the target machine are running <br>> exactly the same Erlang/OTP release and have the same underlying <br>> architecture. In this case you can use:<br>> <br>> erlc +native FILE.erl -o FILE.beam<br>> <br>> and transfer these FILE.beam(s) on the target machine. I am pretty sure <br>> this works.<br>> <br>> But what you can also do the following: compile the files to BEAM byte <br>> code and transfer these files to the target machine and then native <br>> compile these files on the fly (as part of the start of your <br>> application) by using something like the following:<br>> <br>> lists:foreach(fun (F) -> hipe:c(F) end, BEAM_FILES)<br>> <br>> This will compile the BEAM files in memory, generate native code for <br>> them and load them in the running system. (Obviously, you can choose to <br>> compile only a subset of your files, perhaps only those that are time <br>> critical.) There is obviously a small start up cost in doing this, but <br>> in most applications this should not be an issue.<br>> <br>> Let me know how it goes. We can continue this perhaps offline.<br>> <br>> Kostis<br>> _______________________________________________<br>> erlang-questions mailing list<br>> erlang-questions@erlang.org<br>> http://erlang.org/mailman/listinfo/erlang-questions<br></div></div> </div></body>
</html>