LLJS: Low-Level JavaScript

http://lljs.org/

by wamatt • 14 years ago

210 51 14 years ago

lljs.org

suprememoocow• 14 years ago

Oh dear. The site immediately crashes Chrome (Version 22.0.1229.79 m) on Windows XP.

zapu• 14 years ago

Same here. Also Chrome and Windows XP. But it manages to load after few refreshes.

But I can't run any of the "demos".

terinjokes• 14 years ago

Works fine in Chrome 23 on Mac.

markus2012• 14 years ago

Works on version 24.0.1284.2 on my mac.

overbroad• 14 years ago

Oxymoron.

zx2c4• 14 years ago

Despite my usual cynicism about #javascripthipster projects, this does actually look kinda neat.

The one thing that rubbed me the wrong way is the "let" keyword. Why can't we just declare variables without it, like C does? I suppose because they want to rely on JavaScript's own scoping rules?

What would be cooler would be if they could just totally do away with making actual JavaScript variable declarations or function calls, save for the set of typed arrays, pushing and popping variables on and off the stack for function calls, and then coming up with some horrible hack for implementing jmps in a language with no goto. I'm sure this wouldn't really make things more efficient, but it'd be interesting to read.

I guess though, there's always the source of emscripten for that delight.

dasil003• 14 years ago

This is more of a #javascriptneckbeard project for which I have to give a healthy respect.

mbebenita4• 14 years ago

Relying on JS function calls and variable declarations is actually more efficient in this case since the underlying JS JIT can perform a lot of optimizations (SSA / Register Allocation). We do stack allocation for structs and local variables for which you need to take the addresses of.

The "let" keyword is left in there because we wanted to stay compatible with JS. So any JS program is also an LLJS program. This way it would be easy to integrate into an existing code base. As for the "let" vs. "var" debate, we chose "let" because of its block scoping semantics and because we didn't want to let variable declarations alias each other with different types.

rbanffy• 14 years ago

> The one thing that rubbed me the wrong way is the "let" keyword.

Reminds me of 8-bit BASIC. Without the line numbers.

Ygg2• 14 years ago

Running examples on Chrome with Win 7 crashes the tab. It's not that big deal, but for now other than a neat way for crashing your browser I don't see any application for this framework/library.

sitkack• 14 years ago

Crashes iPad 1 with iOS 5.1

akadien• 14 years ago

Half of the web seems to crash iPad 1 these days.

lucian19002• 14 years ago

This is actually pretty interesting. Some of the performance benefits of C (known types, little and predictable allocation) without its total lack of any safety. Syntax still sucks, but not much can be done about that while still looking like JS.

On the other hand, any runtime that infers structure (like V8 or PyPy) will make most of the performance benefits moot, leaving only predictable allocation (fewer and shorter GC pauses).

tomp• 14 years ago

The syntax doesn't matter; if the browsers implement something like this, it will make javascript a much more compelling target for compilers (even of fast, statically typed languages), so you can make your own syntax above it!

lucian19002• 14 years ago

I meant that the syntax still has plenty of pitfalls. Compilers can already uses the same features lljs is using and just generate JS.

dllthomas• 14 years ago

One way in which it might actually help significantly is if it motivates coding in ways that are better structured, and the sophisticated run-times can take good advantage of this.

davvid• 14 years ago

this keeps crashing my golden oldy iOS device. it must be webkit since others are getting chrome crashes too.

dugmartin2• 14 years ago

Immediate crash for me too on my iPad 1 with iOS 5.1.

mgaudin• 14 years ago

Same here. Crashes for Windows 7 Chrome Version 22.0.1229.92 m

jhrobert• 14 years ago

Cool. This leverages JIT compilers ability to generate fast code (at the expense of language expressiveness, for it obviously works well with static style code only).

I wonder what a "JavaScript JIT optimized C dialect" would be? Ie. what are the C mechanisms that are too expensive with today's JIT engines?

m0skit0• 14 years ago

I don't see what benefits this has C doesn't... maybe someone will see them. Anyway cool idea and runs flawlessly in Firefox 15.0.1@Ubuntu 12.04.

andreasvc3• 14 years ago

Does C run in Firefox? No? Well there you have your benefit.

billwashere• 14 years ago

How about emscripten then? https://github.com/kripken/emscripten

*Not that I would.

agentultra2• 14 years ago

http://www.cs.cornell.edu/home/ulfar/cuba/paper/

Any language could. Javascript's ubiquity is just an accident of history. Nobody planned for it to be this way. It's not even the best way.

Why not a C applet in the browser with access to native hardware? Let the OS handle access to memory and system call interception. Why not CL? Or Python? Or anything else? Why do we have to let JS continue to be the de facto language and tack on all of these monstrosities upon it?

pav3l• 14 years ago

Javascript can run in the browser, distributed computing. http://hackaday.com/2009/03/03/distributed-computing-in-java...

djhworld4• 14 years ago

Nice.

  For now, we allocate one large chunk of memory 32 MB and let  malloc and free manage it.

32mb sounds like a lot

mbebenita4• 14 years ago

The size can be adjusted to whatever size you need. In principle this can be done automatically by malloc by hot-swapping the typed array with a larger one.

pkolaczk• 14 years ago

32 MB of heap is not any problem for modern GCs and modern RAM speeds. With a typical DDR3 memory with bandwidth of 16 GB/s that should fully GC in a few ms. And good GCs usually don't stop the mutator in the marking phase (at least so do some GCs in Java), so the total blocking time could be even lower.

bdittmer• 14 years ago

Build a single page javascript application and don't refresh after using it for a few hours. I've yet to find one that doesn't leak memory like a sieve.

achille• 14 years ago

The render process on very page you're on right now consumes 116mb, see: http://i.imgur.com/gCA1C.png

haldean• 14 years ago

Are you on a Retina display? That screenshot is beautiful (and huge).

p0nce• 14 years ago

Neat but the target language does not seem like regular Javascript.

judofyr• 14 years ago

Ehm, it's valid JavaScript. What is not "regular" about it?

djhworld4• 14 years ago

He probably meant to say "readable"

zumosol• 14 years ago

benchmark: time for the loop with signed integers: lljs = 116 ms, sbcl = 0.026, so lljs is still five times slower than sbcl in my computer (64 bits, ubuntu). Compiled in: 32 ms ----------------------------------------------------- Timer: 116 ms: Empty For loop with signed integers. Timer: 604 ms: Empty For loop with unsigned integers. Timer: 115 ms: Empty For loop with untyped integers. ----------------------------------------------------- Executed in : 835 ms.

(time (loop for i fixnum below 50000000 do (progn nil)))

Evaluation took: 0.026 seconds of real time 0.028001 seconds of total run time (0.024001 user, 0.004000 system) 107.69% CPU 53,460,529 processor cycles 0 bytes consed

NIL

djhworld4• 14 years ago

Can any javascript people explain this piece of code

    const $M = require('memory');

That the compiler outputs as JS? Is the 'require('memory')' something that is native to the JS runtime?

mbebenita4• 14 years ago

"require('memory')" gives you back a JS module that's written in LLJS (http://git.io/vHeH2g). It exports several typed array views and a few functions like malloc() / free(). It's all JavaScript, nothing native.

djhworld4• 14 years ago

So clients will have to download this to their machines (via CDN?)

error54• 14 years ago

Crashes tab on load. Chrome 24.0.1284.2 on WinXP.

yalogin• 14 years ago

I don't work with JS. Can someone explain to me how I can use it as a developer? Should I be writing code in the intermediate representation and then compile it into JS?

LLJS: Low-Level JavaScript

Related Stories