I have a project written in C which I wish to convert to Perl. A friend of mine suggested to use LLVM. I compiled my C code to LLVM assembly using Clang. Now I'm trying to convert this intermediate representation into Perl but I can't seem to find any backend for it. Would someone point me in the right direction?
No, there isn't such a backend. At least not directly. Emscripten converts LLVM IR to Javascript, and maybe you can use something else to convert that to Perl.
It's a pretty bad idea for moving a project from one language to another. The code will be completely unreadable and un-maintainable. Either do a honest rewrite or wrap your C as a library with Perl's foreign-function interface tools and use it from Perl.
Converting to Perl is a no go. It hasn't been done because emulating C in Perl would be insanely slow. They have completely different type systems, for starters. However, it's wholly unnecessary to convert the code to Perl to call it from Perl. You can load compiled C code from Perl.
What you'll have to do is tell Perl how to call those C functions. Perl deals with scalars and so on, but C deals with ints and so on. This is done using XS.
perlxstut contains the documentation on how to do all this.
Related
I have an old piece of Fortran f77 code that I would like to understand and edit for future reuse. For that purpose, I would like this code to be translated to either C or Matlab / Octave language. I have found an instance of f2c exe online, but it wouldn't run because of inappropriate OS ( my OS is Win 7 x64, f2c wanted older x32 ).
My main concern is being able to understand the code. Translation in terms of execution efficiency is not of importance. I am open to any suggestion, apart from learning Fortran 77. I am aware of that option myself, but would do it only as a last resort. Thank you.
Just learn Fortran. The output of machine-translated code may well be functionally correct and suitable for compilation and execution, but it's going to be really hard to understand and maintain. (Just look at what generated code targeting a single language, like the output of a GUI builder wizard, looks like.) In particular, while Matlab is built on Fortran, its idioms at the M-code level are different enough that it would be pretty incomprehensible. If you already know C or any other Algol-like language, picking up Fortran is not that hard. And the idioms and features that are particular to Fortran – that is, the new stuff you'd have to learn – are probably going to be especially weird and incomprehensible when sent through a translator.
The one translator that might actually be useful is a Fortran 77 -> Fortran 90 translator. The modern '90 dialect would be easier to learn and more succinct, and since the translation is within the same language family the output probably wouldn't be too ugly.
Since are using Octave, you can call Fortran code, there is no need to rewrite it. You will need to write a very simple C++ wrapper to it but Octave already provides macros to do all of the hard work. It is all documented on the manual. Actually, Octave itself calls on many fortran subroutines, so this is perfectly normal.
If you want to modify it, you should be learning Fortran then.
I have a C library and I need to access its functions in a Perl program.
I researched this on the internet and find that this wrapper can be implemented using XS, but I saw that XS is not consistent if needed to run the code on different OS.
I also found module FFI::Raw on CPAN which might do the job. Does anyone use FFI::Raw in production? What do you suggest to use, FFI::Raw or XS?
We know this module's function is Dynamically load C libraries into Perl code .
But how's its own c library loaded into Perl in the first place?
I judge it should have its own c library because I don't find the function dl_load_file right inside DynaLoader.pm,so it must be in some c library...
Dynaloader is statically linked to Perl (managed by Configure), so that it is always available. It wouldn't work very well if it had to be available itself to load itself.
The source for Dynloader is at /ext/Dynaloader/ in the Perl distribution, which contains a number of different implementations of dl_load_file for the various architectures on which Perl might run.
So yes, dl_load_file is in a library, but it ends up inside perl when perl gets built.
Has anyone ever written a Haskell extension to Perl? Maybe something simple, like a function that calculates the fib. sequence? I'm interested in using Haskell, and I see some overlap between the Haskell and Perl community. Any pointers to Haskell / Perl projects, or cool things that manage to use both of these? I've seen Language::Haskell -which is only an interpreter- but it seems poorly documented, 6 years old, and lots of fail.
Is it possible to build extentions to Perl using ghci comparable to using XS (something I don't claim to know anything about)? I realize this question is probably all kinds of wrong, and badly worded. I'm attempting two things that I know little about - Haskell and extending Perl (which have both always interested me). Feel free to edit this.
The closest work was Inline::Haskell I think, during the pugs / perl6 time.
You can also embed Perl5 in a Haskell program: http://hackage.haskell.org/package/HsPerl5
The Haskell FFI happily supports calling into Haskell from other languages, but I'm not sure this is sensible in the larger scheme of things. Sounds like you're doing it wrong.
It's perhaps worth noting here that you can write shell scripts in Haskell as well using runhaskell:
#! /usr/bin/env runhaskell
There's HSH for mixing shell expressions into Haskell programs.
And the Simple UNIX Tools Haskell wiki page is full of ideas too.
Nothing to Perl but more about Scripting in Haskell
I have gone through the source code of Data::Dumper. In this package I didn't understand what's going on with DumpXS. What is the use of this DumpXS?
I have searched about this and I read that, it is equal to the Dump function and it is faster than Dump. But I didn't understand it.
The XS language is a glue between normal Perl and C. When people want to squeeze every last bit of performance out of an operation, they try to write it as close to the C code as possible. Python and Ruby have similar mechanisms for the same reason.
Some Perl modules have an XS implementation to improve performance. However, you need a C compiler to install it. Not everyone is in a position to install compiled modules, so the modules also come in a "PurePerl" or "PP" version that does the same thing just a bit slower. If you don't have the XS implementation, a module such as Data::Dumper can automatically use the pure Perl implementation. In this case, Data::Dumper also lets you choose which one you want to use.
A lot of Perl modules have "XS" versions, like JSON::XS. The XS in the name means that it partly uses C in order to increase the speed or other efficiency of the module. I don't know this particular case, but it is probably that.
And if you want a bit more info on XS go to http://perldoc.perl.org/perlxs.html
But I am curious what lead you to this question.