The CPUID code is x86-specific, and needs to be skipped for ARM.
On Tuesday, May 6, 2014 12:11:04 AM UTC-5, Christopher Fusting wrote: > > I haven't had a chance to look into this. Inline assembly is failing: > > CC src/sys.o > sys.c: In function ‘jl_cpuid’: > sys.c:425:5: error: impossible constraint in ‘asm’ > make[2]: *** [sys.o] Error 1 > make[1]: *** [julia-release] Error 2 > make: *** [release] Error 2 > > _Chris > > On Friday, April 25, 2014 11:20:43 PM UTC-4, Viral Shah wrote: >> >> Please do share logs. >> >> -viral >> On 26-Apr-2014 8:23 am, "Christopher Fusting" <[email protected]> wrote: >> >>> Any progress on this? Trying to build Julia on a beaglebone black. >>> Would be happy to share the logs. >>> >>> _Chris >>> >>> On Friday, November 1, 2013 4:21:03 AM UTC-4, Viral Shah wrote: >>>> >>>> For 0.3, we are going to try migrating to MCJIT. LLVM is likely to have >>>> multi-module support in the 3.4 release - which should make it possible >>>> for >>>> us to use MCJIT, which should pave the way for ARM support. >>>> >>>> Basically, we will get the 0.2 release done, the LLVM 3.4 release >>>> should happen in a few weeks. If everything works out well and >>>> optimistically, we could be experimenting with this quite soon. Keno >>>> probably has some early work on MCJIT migration already. >>>> >>>> Also, openblas is going to have an ARM port in the release after next - >>>> which will be very nice, though not essential. >>>> >>>> -viral >>>> >>>> >>>> >>>> On 31-Oct-2013, at 10:18 pm, Arnaud Amzallag <[email protected]> >>>> wrote: >>>> >>>> > Hello to all the Julia developers; >>>> > >>>> > first thumbs up for this great language. I love the syntax, not >>>> verbose and flexible, and it makes sense. I wrote for years in Matlab and >>>> switched to R a few years ago. I wrote C++ when I needed speed where I >>>> could not vectorize my code. I was very attracted by the potential of >>>> having a fast code and not vectorizing, and I picked up the language >>>> pretty >>>> fast. >>>> > >>>> > Apart from my job, I was a robotic hobbyist at some point, I am >>>> considering playing with the Raspberry pi (Hoppy). It could make a lot of >>>> sense to have julia embedded in a robot. Often, amateur robotics projects >>>> rely on C compiled for Atmel processors (a few years ago at least it was >>>> the case), and it is quite cumbersome to program in C when experimenting. >>>> Julia seems great for experimenting with robots (for instance running on >>>> Debian for Raspberry Pi) because it is a high level language, and at the >>>> same time it seems very efficient. I saw discussions about having Julia >>>> running on a linux for ARM; >>>> > >>>> > I wonder if there was some progress on getting Julia to work on an >>>> ARM processor. >>>> > >>>> > Best regards, >>>> > >>>> > Arnaud >>>> > >>>> > On Thursday, May 16, 2013 11:21:24 PM UTC-4, Viral Shah wrote: >>>> > See: https://github.com/JuliaLang/julia/issues/3134 >>>> > >>>> > -viral >>>> > >>>> > >>>> > >>>> > On 16-May-2013, at 10:20 PM, Stefan Karpinski <[email protected]> >>>> wrote: >>>> > >>>> > > Perhaps we should make an "up for grabs" issue to track/encourage >>>> this port? >>>> > > >>>> > > >>>> > > On Thu, May 16, 2013 at 12:40 PM, Viral Shah <[email protected]> >>>> wrote: >>>> > > The first step would be to get a minimal julia running on ARM. I am >>>> not sure if the debian armhf architecture is supported by LLVM's ARM >>>> support. Here is the build log: >>>> > > >>>> > > https://buildd.debian.org/status/fetch.php?pkg=julia&; >>>> arch=armhf&ver=0.1.2%2Bdfsg-3&stamp=1368675598 >>>> > > >>>> > > The julia system image build fails with: >>>> > > LLVM ERROR: Not supported instr: BMOVPCRX_CALL %R3<kill>, >>>> <regmask>, %LR<imp-def,dead>, %SP<imp-use>, %R0<imp-use,kill>, >>>> %R1<imp-use,kill>, %R2<imp-use,kill>, %SP<imp-def>, %R0<imp-def>; dbg:no >>>> file:0 >>>> > > >>>> > > If the debian ARM build can be made to work, it will at least >>>> become a supported architecture and the rest will follow. >>>> > > >>>> > > -viral >>>> > > >>>> > > >>>> > > >>>> > > On 16-May-2013, at 9:40 PM, Stefan Karpinski <[email protected]> >>>> wrote: >>>> > > >>>> > > > Not necessarily. There are two possible versions. One where the >>>> whole LLVM infrastructure is included in the runtime and the program can >>>> and does JIT new code as needed while running. Then there's a version that >>>> tries to pre-generate all code that might be needed and doesn't include >>>> any >>>> LLVM infrastructure. That would either require being able to prove that >>>> all >>>> possible code has been generated already, which is generally quite hard >>>> and >>>> would require feedback from the compiler, or it would have the possibility >>>> of failing execution. We will almost certainly have the version that >>>> includes LLVM first and then eventually have a compiler option to generate >>>> binaries that don't depend on LLVM at all. >>>> > > > >>>> > > > >>>> > > > On Thu, May 16, 2013 at 12:00 PM, Lewis Girod < >>>> [email protected]> wrote: >>>> > > > Thanks, that is useful information. >>>> > > > Would the forthcoming static compiler remove the dependency on >>>> LLVM? >>>> > > > >>>> > > > >>>> > > > On Thu, May 16, 2013 at 11:39 AM, Stefan Karpinski < >>>> [email protected]> wrote: >>>> > > > h2j.c is an experiment I wrote using libclang to parse C header >>>> files and generate Julia bindings for that code. It should probably be >>>> retired since I'm pretty sure it is fully superseded by things like >>>> Clang.jl and Cpp.jl. The Julia JIT does, however, use LLVM for code gen >>>> (see src/codegen.cpp), so it would certainly be necessary to get LLVM >>>> working on ARM, which is probably quite nontrivial. I have no idea if >>>> bionic vs. libc is an issue, but it certainly could be. >>>> > > > >>>> > > > >>>> > > > On Thu, May 16, 2013 at 11:15 AM, Lewis Girod < >>>> [email protected]> wrote: >>>> > > > Thank you for the info. Re getting it on android, I agree it is >>>> a challenge, I think mainly the issue is getting all of the dependent >>>> libraries cross compiled. Does the julia JIT depend on parts of LLVM (I >>>> noticed that h2j.c links in a bunch of LLVM libraries)? There may also be >>>> issues relating to the fact that android uses 'bionic' in place of libc. >>>> > > > >>>> > > > I will file the issue - having this in the make file would make >>>> is a lot easier to understand what would need to be ported. >>>> > > > >>>> > > > Thanks again! >>>> > > > >>>> > > > >>>> > > > On Thu, May 16, 2013 at 10:22 AM, Viral Shah <[email protected]> >>>> wrote: >>>> > > > Jeff is the best person to say how far we realistically are. Even >>>> when we actually have this, getting it all working on Android will be >>>> another major challenge. Perhaps we can hope that julia becomes popular >>>> enough at Google and someone on the Android team hacks it all up. :-) >>>> > > > >>>> > > > Even if you can get the basic julia distribution working on >>>> Android, it will be a good start. You can use the interface in jlapi.c and >>>> also look at the way the REPL works. We do not yet have a "build the >>>> minimal julia" makefile option. Could you file an issue? This is not >>>> difficult to do, but will require some careful work. >>>> > > > >>>> > > > -viral >>>> > > > >>>> > > > >>>> > > > >>>> > > > On 16-May-2013, at 7:25 PM, Lewis Girod <[email protected]> >>>> wrote: >>>> > > > >>>> > > > > Re. the static julia compiler - it looks like that would >>>> simplify these issues a lot, because that would avoid the need to >>>> x-compile >>>> llvm? >>>> > > > > >>>> > > > > Do you know about how far off this might be ready - just order >>>> of magnitude? >>>> > > > > >>>> > > > > >>>> > > > > >>>> > > > > On Thu, May 16, 2013 at 9:10 AM, Lewis Girod <[email protected]> >>>> wrote: >>>> > > > > Thanks, Viral. >>>> > > > > In googling around I have seen that people have been able to >>>> x-compile the fortran matrix libraries for android, but it required a >>>> little tweaking. >>>> > > > > I'd like to play around with x-compiling the core of julia - >>>> what parts are required to get the most basic functionality - the REPL I >>>> guess? >>>> > > > > >>>> > > > > On Wednesday, May 15, 2013 9:30:41 PM UTC-4, Viral Shah wrote: >>>> > > > > We have not yet had a successful ARM build. I can post the >>>> debian buildd logs. I suspect that you will want the julia static compiler >>>> for this, which Jeff is incrementally working towards. >>>> > > > > >>>> > > > > -viral >>>> > > > > >>>> > > > > On May 16, 2013 1:47 AM, "Lewis Girod" <[email protected]> >>>> wrote: >>>> > > > > I am also interested in experimenting with a stripped-down >>>> installation. >>>> > > > > >>>> > > > > I am writing signal processing algorithms to run on an android >>>> phone and I'm trying to figure out if Julia would be a good solution, as >>>> opposed to writing them in C (using JNI) or Java, both of which are pretty >>>> cumbersome. THe Julia language seems like what I am seeking in terms of >>>> usability, but I wonder what it would take to get it running on an >>>> android. >>>> > > > > >>>> > > > > In particular, I would like to build a minimal Julia engine, >>>> without graphics etc., that would run a single Julia program that receives >>>> the next chunk of data in the stream and produces the next output. >>>> > > > > >>>> > > > > I would need to figure out how to keep only the relevant parts >>>> of the julia system and then cross-compile it for arm. >>>> > > > > Do you have any recommendations on how to go about this? In >>>> particular, what components are needed for a minimal running system? >>>> > > > > >>>> > > > > >>>> > > > > On Tuesday, April 2, 2013 2:34:46 AM UTC-4, Viral Shah wrote: >>>> > > > > Most of the bulk in julia comes from the libraries. Depending >>>> on your computation, you may still need to bundle these. Julia itself is >>>> only a few MB, including sys.ji. >>>> > > > > >>>> > > > > So, what you can do for now is embed julia by using libjulia, >>>> and call it the way it is called from repl-basic.c. However, you do need >>>> to >>>> bundle BLAS, LAPACK, and any other libraries your code ends up using. >>>> > > > > >>>> > > > > Given that this is often asked, I will try to create a >>>> self-contained example, and do a blog post once successful. >>>> > > > > >>>> > > > > -viral >>>> > > > > >>>> > > > > On Saturday, March 30, 2013 2:16:13 AM UTC+5:30, Velky Pivo >>>> wrote: >>>> > > > > The purpose is to distribute the application to the end user on >>>> a flash stick, and call/execute the Scilab program residing on the stick >>>> from Excel or Visual Basic on PC hard drive. >>>> > > > > I do not want to open the Scilab IDE or command line to show, >>>> nor I want to install full 150MB of Scilab, only the necessary support >>>> package to run the scilab program file. >>>> > > > > There are only calculations involved (numerical and signal >>>> processing), no plots or visualization. >>>> > > > > >>>> > > > > On Thursday, March 28, 2013 2:08:12 PM UTC-5, Jameson wrote: >>>> > > > > Yes, it is intended to be self-contained. If you set an >>>> environment variable %HOME%, you can redirect all of the configuration >>>> data >>>> also -- such as packages and git -- instead of using their default >>>> directory %APPDATA%/julia. Note, typically, you will want to launch julia >>>> through the included batch script, julia.bat. It sets up the %PATH% >>>> variable for you, then passes all command line arguments through to julia >>>> (so you can, e.g., pass the name of a julia script to run). >>>> > > > > >>>> > > > > On Mar 28, 2013, at 2:43 PM, Jacob Quinn <[email protected]> >>>> wrote: >>>> > > > > >>>> > > > >> I can confirm the windows self-containment. I currently run >>>> Julia on 2 different machines with one set of julia files sitting in a >>>> dropbox folder. >>>> > > > >> >>>> > > > >> -Jacob >>>> > > > >> >>>> > > > >> On Thursday, March 28, 2013 1:40:57 PM UTC-5, Alessandro >>>> Andrioni wrote: >>>> > > > >> I think the Windows package is already self-contained, you'd >>>> just have >>>> > > > >> to set up a different HOME directory for julia and git. >>>> > > > >> >>>> > > > >> On 28 March 2013 15:26, Velky Pivo <[email protected]> wrote: >>>> > > > >> > So, binaries are no go at present time. >>>> > > > >> > >>>> > > > >> > As other possibility, I would like my Julia program to be >>>> placed on the >>>> > > > >> > flash stick, along with the Julia runtime engine, libraries >>>> and >>>> > > > >> > dependencies. >>>> > > > >> > I would then call the Julia runtime, which would start my >>>> Julia program from >>>> > > > >> > a Windows application like, for example, Excel. >>>> > > > >> > >>>> > > > >> > Something like : ExcelStartProcess ( >>>> FlashDirectory/JuliaRuntime.EXE >>>> > > > >> > --FlashDirectory/myJuliaprogram --FlashDirectory/libraries >>>> etc.) >>>> > > > >> > >>>> > > > >> > Is this possible, and could you please direct me toward what >>>> files need to >>>> > > > >> > be generated and placed on the stick for this to work ? >>>> > > > >> > >>>> > > > >> > Thanks ! >>>> > > > >> > >>>> > > > >> > >>>> > > > >> > >>>> > > > >> > On Wednesday, March 27, 2013 3:45:28 PM UTC-5, Velky Pivo >>>> wrote: >>>> > > > >> >> >>>> > > > >> >> I am considering compilers for scientific computing. >>>> > > > >> >> I need a compiler (most lokely for Windows OS) that will >>>> produce a >>>> > > > >> >> standalone executable for the intel 86 and amd 64 >>>> architecture (no packages, >>>> > > > >> >> runtime distributables etc.). >>>> > > > >> >> C/C++ is out of a question, and anything interpreted is out >>>> for me as >>>> > > > >> >> well. >>>> > > > >> >> At the moment I am only considering Fortran. >>>> > > > >> >> >>>> > > > >> >> Can Julia produce standalone EXEs ? >>>> > > > > >>>> > > > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>> > > >>>> > > >>>> >>>>
