lljvm | Low Level Java Virtual Machine | Compiler library
kandi X-RAY | lljvm Summary
kandi X-RAY | lljvm Summary
LLJVM provides a set of tools and libraries for running comparatively low level languages (such as C) on the JVM. The C to JVM bytecode compilation provided by LLJVM involves several steps. Source code is first compiled to LLVM intermediate representation (IR) by a frontend such as llvm-gcc or clang. LLVM IR is then translated to Jasmin assembly code, linked against other Java classes, and then assembled to JVM bytecode. The use of LLVM IR as the intermediate representation allows more information about the source program to be preserved, compared to other methods which use MIPS binary as the intermediate representation (such as NestedVM and Cibyl). For example, functions are mapped to individual JVM methods, and all function calls are made with native JVM invocation instructions. This allows compiled code to be linked against arbitrary Java classes, and Java programs to natively call individual functions in the compiled code. It also allows programs to be split across multiple classes (comparable to dynamic linking), rather than statically linking everything into a single class. Also note that while C is currently the only supported input language, any language with a compiler targeting LLVM IR could potentially be supported.
Support
Quality
Security
License
Reuse
Top functions reviewed by kandi - BETA
- Returns the function pointer for the specified method
- Returns a string representation of the specified type
- Register the class with the given binary name
- Returns the type signature of the given method
- Pack a string at a given address
- Pack a char array at the given address
- Create a new stack frame
- Store an array of strings into a stack
- Opens a file or directory
- Add the given FileHandle to the table
- Change the working directory
- Jump to a new jmp
- Divides two numbers
- Store a string in the data segment
- Splits a number into a fraction and an exponent
- Returns the remainder of two operations
- Classify a floating point number
- Sets a new jump target
- Increments the heap
- Seek to the specified offset
- Split a number into a fraction and an exponent
lljvm Key Features
lljvm Examples and Code Snippets
Community Discussions
Trending Discussions on lljvm
QUESTION
I'm trying to do the following:
Run a specific docker container, lljvm_work
.
Have it mount a local directory (../services/c
with its docker mirror in c_files
).
Run a command there (lljvm_cc
) to process some files.
What I try to do is:
...ANSWER
Answered 2018-May-25 at 07:02It appears giving the complete path to the executable does work, though this is not necessary from within the container itself.
Regardless, the following works:
QUESTION
I am creating a virtual machine (VM) for an embedded device that runs both C and Java code by compiling both to bytecode. Now I am trying to automate compiling and flashing C applications (Java already works).
A big manual part is taking a .c file and getting it to a format the VM understands. Currently, it works as follows:
Boot up a Docker Container while pointing it towards where the .c file is and giving myself bash
~$ docker run -i -v /home/git/bytecode_manipulation:/c_files -t lljvm_work /bin/bash
Use the configured lljvm-cc tool of the container to convert the .c file while producing a jasmin file (an intermediate for converting to bytecode)
docker_container$ lljvm-cc test_c_srv.c -o test_c_srv -g3
Exit the docker container and run a python script which converts the .j jasmin file to a .uj jasmin file, converts the .uj file to a .class file and puts it in a good folder
~$ ./script_j_to_uj.py test_c_srv.j test_srv.uj
I'd like to automate this in a Makefile. Currently, I have a recipe in my makefile that generates .class files for the Java apps, then scoops up all .class files (from either C or Java apps). processes them somewhat further into .raw_ujc files and generates a list of then. Ideally, this would now also generate .class files for the C apps. The recipe:
...ANSWER
Answered 2018-May-25 at 06:17After tinkering around, I've this does what I want:
QUESTION
I'm writing a python script that takes a text file and should produce another text file with certain lines minimally changed.
I keep getting stuck and would appreciate some assistance.
The intention is that from the commandline I can run:
...ANSWER
Answered 2018-May-11 at 11:58I assume you intended to write something similar to:
QUESTION
I am developing an OS for embedded devices that runs bytecode. Basically, a micro JVM. In the process of doing so, I am able to compile and run Java applications to bytecode(ish) and flash that on, for instance, an Atmega1284P.
Now I've added support for C applications: I compile and process it using several tools and with some manual editing I eventually get bytecode that runs on my OS. The process is very cumbersome and heavy and I would like to automate it.
Currently, I am using makefiles for automatic compilation and flashing of the Java applications & OS to devices.
All steps, roughly, for a C application are as follows and consist of consecutive manual steps:
(1) Use Docker to run a Linux container with lljvm that compiles a .c file to a .class file (see also https://github.com/davidar/lljvm/tree/master)
(2) convert this c.class file to a jasmin file (https://github.com/davidar/jasmin) using the ClassFileAnalyzer tool (http://classfileanalyzer.javaseiten.de/)
(3) manually edit this jasmin file in a text editor by replacing/adjusting some strings
(4) convert the modified jasmin file to a .class file again using jasmin
(5) put this .class file in a folder where the rest of my makefiles (the ones that already make and deploy the OS and class files from Java apps) can take over.
Current options seem to be just keep using makefiles but this is a bit unwieldly (I already have 5 different makefiles and this would further extend that chain). I've also read a bit about scons. In essence, I'm wondering which are some recommended tools or a good approach for complicated builds.
...ANSWER
Answered 2018-Mar-25 at 09:20Hopefully this may help a bit, but the question as such could probably be a subject for a heated discussion without much helpful results.
As pointed out in the comments by others, you really need to automate the steps starting with your .c
file to the point you can integrated it with the rest of your system.
There is generally nothing wrong with make and you would not win too much by switching to SCons. You'd get more ways to express what you want to do. Among other things meaning that if you wanted to write that automation directly inside the build system and its rules, you could also use Python and not only shell (should that be of a concern though, you could just as well call that Python code from make). But the essence of target, prerequisite, recipe is still there. And with that need for writing necessary automation for those .c
to integration steps.
If you really wanted to look into alternative options. bazel might be of interest to you. The downside being the initial effort to write the necessary rules to fit your needs could be costly. And depending on size of your project, might just be too much. On the other hand once done with that, it'd be very easy to use (apply those rules on growing code base) and you could also ditch the container and rely on its more lightweight sand-boxing and external rules to get the tools and bits you need for your build... all with a single system for build description.
QUESTION
I have two example class files, one from an example Java app and one from an example C app (compiled to bytecode using LLJVM).
Looking at their outputs, I can see through javap -c -p that for initializing the (static) fields, the Java app shows the following block:
...ANSWER
Answered 2018-Mar-14 at 09:52This seems to be a nonstandard declaration that javap
did not consider. Normally, static
initializers are compiled to bytecode methods named having a
static
modifier. Apparently, javap
decodes them by just printing the human readable form of the modifier and omitting the name.
Here, it encountered a method named and having the
public
modifier (no static
modifier) and just did the same as usual, printing the modifier and omitting the name.
The code generated by LLJVM seems to rely on an old oddity:
In a
class
file whose version number is 51.0 or above, the method must additionally have itsACC_STATIC
flag (§4.6) set in order to be the class or interface initialization method.This requirement was introduced in Java SE 7. In a class file whose version number is 50.0 or below, a method named
that is void and takes no arguments is considered the class or interface initialization method regardless of the setting of its
ACC_STATIC
flag.
To me, it was truly surprising to read that in previous versions, the ACC_STATIC
modifier was not mandated and I don’t see any reason to ever exploit that oddity. It seems very natural that a class initializer (that is declared static {}
in Java) should have the ACC_STATIC
flag and I can’t even imagine the supposed semantics of an omitted ACC_STATIC
flag. It means that one of two odd things should happen, a) it is invoked without an instance despite not have the ACC_STATIC
flag (being invoked as-if having it) or b) it is invoked with an instance that must have been created “magically”.
The specification says the following about any non-standard method:
Other methods named
in a
class
file are of no consequence. They are not class or interface initialization methods. They cannot be invoked by any Java Virtual Machine instruction and are never invoked by the Java Virtual Machine itself.
QUESTION
I'm trying to compile under MinGW-64 lljvm, a not-so-big program. But I am stuck on an error that is driving me nuts.
The code is as follows:
backend.h
...ANSWER
Answered 2017-Jun-05 at 16:06Replace FunctionPass(&id)
with FunctionPass(id)
.
Community Discussions, Code Snippets contain sources that include Stack Exchange Network
Vulnerabilities
No vulnerabilities reported
Install lljvm
HN comments
2009-2015 David A Roberts
LLVM 2.7 must be installed to compile and run LLJVM. Jasmin is needed for assembling JVM bytecode. To compile LLJVM, simply call make in the project root directory, and call make check to run the testsuite. To generate the the documentation for the java packages and the backend, call make doc, which will generate HTML documentation in doc/java/ and doc/backend/ respectively. PDF documentation for the backend can be obtained by calling make doc-pdf (requires PDFLaTeX), which will generate doc/backend.pdf. A zip archive containing all of the documentation can be created by calling make doc-zip.
Support
Reuse Trending Solutions
Find, review, and download reusable Libraries, Code Snippets, Cloud APIs from over 650 million Knowledge Items
Find more librariesStay Updated
Subscribe to our newsletter for trending solutions and developer bootcamps
Share this Page