Is it possible to compile assembly or x86/x64 code to JavaScript?
Or asm -> llvm-ir -> js?
UPD:
So my final question is:
I have asm listing (excerpt)
push %rbp
mov %rsp,%rbp
sub $0x10,%rsp
mov 0x5e41(%rip),%eax
lea 0x601a(%rip),%rdx
cltq
movzbl (%rdx,%rax,1),%eax
test %al,%al
jne loc_0040121b
movl $0x0,-0x4(%rbp)
jmp loc_00401206
Can I run it in browser without modifications with help of emscriptten or any other tool?
I want to run executable(small program) in browser without access to original source code
So, you actually don't want to compile assembly to js, as you don't have the source. Which is good, as it doesn't make any sense anyway, asm is not like high-level languages having some variables and affecting platform trough some API, in asm basically any instruction can change state of platform a lot, and "variables" is the whole accessible memory.
A way how it makes sense:
You want to execute some machine code already prepared for some target platform (CPU + OS).
"In browser" (directly) it's not possible, browser doesn't process machine code of that CPU, neither does it provide the OS API/ABI/syscall. That executable needs the target OS, so it's instructions have the desired effect.
You can run emulator of that OS written in JS, and run the binary inside the emulator. Search for example for web-online dosbox (running old DOS games in browser, with reasonable speed and not-worst-accuracy, most of them actually being playable and looking as they should).
How to create emulator of your target platform is a bit too broad question and takes somewhat more effort, like decades in some cases. But you may be lucky, that there already exists emulator of your target OS, and has JS port and license allowing you to use it.
There's also second option: if it's really small program, it would be very likely simpler to rewrite it from scratch in JS and in OS/browser agnostic way.
edit: about machine code -> llvm ir:
Let's say simply "no". (although probably like 50% of machine code would be reasonably easy to translate, but the other half would require the translator to fully understand what the code does, which is fully NP problem (or not possible at all)).
Related
I installed nodejs in a usb folder H:\nodejs\node-v16.14.2-win-x86\node
and when I do
H:\nodejs\node-v16.14.2-win-x86\node testing.js
it works. But how can set vscode in a way that it points to my usb folder?
I got it work with python with
"python.defaultInterpreterPath": "H:\python\python.exe",
I dont wanna use enviroment variable and want to point it directly to a specific folder in my usb that has nodejs installed.
Thanks in advance
VS Code looks for "Node" on your path, and why would it do it any other way, its platform specific. If VS Code is running in Linux, Mac, or Windows, it won't run.
Not All is Lost for You Though...
Just because VS Code uses your systems path to exec VS Code, which BTW is an official standard for calling executable, doesn't mean you cannot configure the path, using a symbolic link or something like that, to call your executable from your USB.
2BH, the easiest way to get your USB to 'plug n execute' would be to write a piece of software that configures your OS path to execute node from the USB (this is sort of similar to what drivers are for, when you install other hardware, which is sort of what your USB is right?).
You would probably need to write it in MVSC C++, since your on windows. Linux is a far better OS to do stuff like what your doing. You could easily configure your ~/.bashrc to find the executable.
Those are your options though. Its important that you acknowledge how important standards are, if for no other reason than the sake of manifesting your ideas into something useful. If it were not for contemporary standards, which took a hell of a lot of work, and years to put into place (not to mention legal humps to climb over), computers, and programming languages, wouldn't be nearly as useful, or as technologically advanced as the state that you find them in today.
The path on your system is an extremely fundamental standard and concept. It isn't the only option you have for calling executables, which is what you are using to run node from your USB, but it is by far the most used, and for good reason. I want to explain why but its really far beyond the scope of this question. Its cool what your trying to do, so I wanted to help you if I could.
Try to read about using symbolic links with the path. If your clever enough, you could probably get much closer to what you want using symbolic links combined with the system path.
I recently started some web development, with ASP.NET and some Javascript, and something is confusing me alot.
I always read that JavaScript used to be interpreted until JIT slowly made it so chunks are compiled to machine code (which made browsers alot faster).
This makes no sense to me. How can JavaScript compile to native machine code, if traditional JavaScript apps don't target the machine/CPU to begin with?
I understand if an electron.js app gets compiled to machine code using the NodeJS runtime. That I get. Because it natively compiles to machine code and as far as I understand it, doesn't run in a browser.
If traditional JavaScript apps run in a browser, why must it be compiled to machine code? The browser is responsible for running the code, not the CPU. The CPU runs the browser itself. I actually don't see how the native OS can influence anything that happens in the browser at all or vise versa. Seems like a security issue as well.
Sorry if it's a stupid question, but I can't find any resource that will go beyond saying "Javascript uses JIT"
Thank you!
Lauren
At the end of the day, the CPU has to run the code.
JIT-compiling it down to machine code is one way to make that faster.
How can JavaScript compile to native machine code, if traditional JavaScript apps don't target the machine/CPU to begin with?
It is not "Javascript" that is doing it, it is the browser (or rather, the Javascript execution engine inside the browser), and since it is "JIT" it knowns exactly which CPU to target (this is not done in a generic way, this is done for the specific CPU that the browser is currently running on).
So, yes, there is some mismatch, since Javascript will not use low-level primitive types that the CPU can work with directly, which is why there is a lot of indirection and speculative type inference guess-work. The resulting machine code is much different than you would get from hand-coded assembly, but it can still be a net positive. To help with this, WASM was developed, which is closer to "normal" machine code.
Other intermediate, non-CPU specific formats like JVM bytecode or CLR bytecode or LLVM bitcode are in a similar situation (in that can also be compiled to machine code they do not themselves target directly) -- but they have been "lowered" already from language source code to something close to machine code.
Seems like a security issue as well.
Yes, it can be. The browser has to be careful in what it is doing here, and the OS should sandbox the browser as much as possible.
Executing instructions is easier than running an interpreter, and JIT seeks to take advantage of this for a performance boost. All programs running on your computer become machine code at some point, the only question is which instructions are be executed.
let x=0;
for (let i=0;i<100;++i) {
x+=2;
}
Since it is clear that there are no side effects in a block of code like this, it is faster to compile instructions directly, rather than interpreting each line.
// NIOS 2 assembly, sorry its the only one i know
movi r2,0
movi r3,0
movi r4,100
loop:
addi r2,2
addi r3,1
blt r3,r4,loop
Executing this will be faster than executing the parsing logic for each individual instruction.
TLDR: All programs are always running CPU instructions, so it is faster to minimize the number of instructions by skipping the parsing stage when possible
How to run compiled files directly using Google Native Client (PNaCl)? It tried checking their documentation. It said that -
Native Client is a sandbox for running compiled C and C++ code in the browser efficiently and securely, independent of the user’s operating system.
But in their documentation, they only deal with sources of the application. Is there any way to run compiled code directly? I want to run files with .exe and .deb extensions
I'm not limiting the answer to Native Client. Any mechanism which can do that sort of work will work for me.
You can't run pre-compiled code within NaCl or PNaCl. You have to use the compilers provided by the SDK. There are three main reasons for this:
NaCl is an execution sandbox which relies on crafting machine code (x86-32, x86-64, ARM, MIPS) in a very particular way. This is regular machine code from the CPU's point of view, but allows the sandbox to run a validator and make sure that the code can't do anything malicious. This is called Software Fault Isolation, and is explained in this paper. The other ISA sandboxes are also documented.
PNaCl targets NaCl, but is an architecture-agnostic intermediate representation. This means that you ship what can be thought of as bytecode, and the browser figures out which type of machine code (x86-32, x86-64, ARM, MIPS) to generate based on the user's machine. The developer doesn't generate 4 binaries.
In both above cases, the code can execute as-is on Windows, MacOSX, Linux, ChromeOS, and (while not usually shipping) Android. This means that the NaCl sandbox presents itself as an operating system, and offers the same APIs. These APIs are different from other OSes, though they're pretty close to POSIX especially if you use nacl_io.
The above points require that you use the compilers provided by the SDK.
It is technically possible to run binaries built for other architectures or operating systems since the system is Turing-complete. That's what QEMU does, what Rosetta did, what Transmeta did, and what the Android Runtime for Chome (ARC) enables. This usually requires binary translation and emulation of all operating system calls. This is technically difficult to implement, and often has severe performance cost. I do not recommend exploring this option.
As #JFBastien pointed out, emulation is the only option to execute pre-compiled native code in the browser environment. But it is an option nevertheless. Depending on your demands on performance, it might even be a viable option.
Click here for example to boot up an emulator running Windows (a very old version though) in your browser.
From the menu pick, for example, notepad.exe (using the cursor down key on your keyboard) and hit enter. There you have it: an unmodified, precompiled, native notepad.exe running inside your browser! (and probably even faster than back in the day when this OS was new).
There are a lot of emulators written in Javascript all around the web. Running a small Linux distribution with usable performance and even with networking(!), graphics and sound is actually possible. Check out the OpenRISC emulator. You can even run an ssh daemon and log into it from your local machine!
https://github.com/rogerwang/node-webkit/wiki/How-to-package-and-distribute-your-apps
While packaging my node-webkit app for windows using the steps given in the above link I could not find how to avoid readability of the resulting executable from the merge by archiving software, such as WinZip. EXCERPT(from link above): "The resulting executable from the merge will still be readable by archiving software, such as WinZip."
Is it possible to avoid readability by the archiving apps?
Any help is appreciated!
Fundamentally, running node-webkit is similar to running in a browser, so just as you can't hide your webpage source, you can't truly hide your HTML and CSS in such a way that it can't be read, because it needs to be read by node-webkit at runtime.
The situation is almost the same for Javascript code, with one exception. V8 (the javascript engine in Chrome) provides a "snapshot" capability, which sort of compiles your Javascript into a sort of bytecode that V8 understands. Nwsnapshot is available for node-webkit, which will allow you to avoid shipping your JS code (or at least some of it). However, this option is still experimental, and in fact there is a problem in version 0.8.* of node-webkit (referred to as v8 in the wiki, but not to be confused with the V8 js engine), though it should be working again now in v9. Details can be found here if you're interested:
https://github.com/rogerwang/node-webkit/wiki/Protect-JavaScript-source-code-with-v8-snapshot
Also be aware that it can have performance impacts, if that matters for your application.
You could also make an exe file.
See "Step 2b: Alternative way - Making an executable file out of a .nw file" from the link you provided.
Is it possible to run JavaScript code in parallel in the browser? I'm willing to sacrifice some browser support (IE, Opera, anything else) to gain some edge here.
If you don't have to manipulate the dom, you could use webworkers ... there's a few other restrictions but check it out # http://ejohn.org/blog/web-workers/
Parallel.js of parallel.js.org (see also github source) is a single file JS library that has a nice API for multithreaded processing in JavaScript. It runs both in web browsers and in Node.js.
Perhaps it would be better to recode your JavaScript in something that generally runs faster, rather than trying to speed up the Javascript by going parallel. (I expect you'll find the cost of forking parallel JavaScript activities is pretty high, too, and that may well wipe out any possible parallel gain; this is common problem with parallel programming).
Javascript is interpreted in most browsers IIRC, and it is dynamic on top of it which means it, well, runs slowly.
I'm under the impression you can write Java code and run it under browser plugins. Java is type safe and JIT compiles to machine code. I'd expect that any big computation done in Javascript would run a lot faster in Java. I'm not specifically suggesting Java; any compiled language for which you can get a plug in would do.
As an alternative, Google provides Closure, a JavaScript compiler. It is claimed to be a compiler, but looks like an optimizer to me and I don't know much it "optimizes". But, perhaps you can use that. I'd expect the Closure compiler to be built into Chrome (but I don't know for a fact) and maybe just running Chrome would get your JavaScript compiler "for free".
EDIT: After reading about what about Closure does, as compiler guy I'm not much impressed. It looks like much of the emphasis is on reducing code size which minimizes download time but not necessarily performance. The one good thing they do in function inlining. I doubt that will help as much as switching to a truly compiled langauge.
EDIT2: Apparantly the "Closure" compiler is different than the engine than runs JavaScript in Chrome. I'm told, but don't know this for a fact, that the Chrome engine has a real compiler.
Intel is coming up with an open-source project codenamed River Trail check out http://www.theregister.co.uk/2011/09/17/intel_parallel_javascript/