Hacker News new | past | comments | ask | show | jobs | submit login

AFAIR, JVM used to not have an u64 type, only i64; does JVM now support it? Or how does Virgil handle it? If there's some custom overhead added to simulate u64 semantics on JVM, that should be clearly documented in a language purporting to be fast - yet I didn't see it. Did I miss it?

I'm asking also because if the compiler supports JVM as a target, it shouldn't be hard to add support for a Dalvik target; however, u64 is also a problem in case of this one.

One more question I have is about FFI - I didn't find a mention of it after a quick skim; can I call functions from some thirdparty JARs or JS/WebAPI?




You're right that the "long" type in Java is signed. The JVM uses two's complement representation, so for many operations, unsigned arithmetic is bit-equivalent to signed arithmetic. For the remaining ones, like less-than, divide, shift, etc, Virgil generates more complicated code to do unsigned arithmetic or comparison manually, e.g. by first checking if an input is negative.

> One more question I have is about FFI - I didn't find a mention of it after a quick skim; can I call functions from some thirdparty JARs or JS/WebAPI?

For the Wasm target, Virgil allows you to write an imported component, so the module that gets generated has the imports with the signatures that you want. You can then load the module in JS and supply Web bindings and such. That latter process is quite clunky, but in theory gives you access to any API that can be expressed in terms of wasm (before externref).


The JVM doesn’t have u64, but it does have standard lib functions like unsigned add that do view their i64 arguments as unsigned and will reliably get JIT compiled down to the correct machine code. The resulting code in Java would not be the most readable, but it is absolutely fine as a target.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: